It's well answered by this stack exchange question.
http://bitcoin.stackexchange.com/questions/2025/what-is-txins-sequence
On 06/20/2013 05:54 PM, Marko Otbalkana wrote:
> Could anyone tell me what CTxIn::nSequence is meant for?
>
> Best Regards,
> -Marko
>
>
> ---
Could anyone tell me what CTxIn::nSequence is meant for?
Best Regards,
-Marko
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
On 06/20/2013 05:10 AM, Jeremy Spilman wrote:
>> which could involve proving something to a third party that has not seen
>> the communication between payer and payee.
> OK - I think I follow now. So a third-party who does not see any of the
> communication between the payer and payee only know
On Thu, Jun 20, 2013 at 3:13 AM, Addy Yeow wrote:
> I personally don't treat the relay field as optional, i.e. it is there as
> 0x01 if it is set. Otherwise, it is simply a trailing zero byte. Hence, the
> right way of reading the packet as with any network packet is to first
> retrieve the header
As I said, there's no benefit. Even if we do that on the C++ side, you
still have to handle connections from bitcoinj clients which will send the
field with the old version number. You can't assume they'll all be updated
simultaneously, even though both the Android app and MultiBit do have
update n
Let's just increase the version number and be done with this discussion.
It's a small benefit, but it simplifies things and it's trivial to do.
I don't understand how a policy of requiring version increases could limit
future extensions: after the version/verack exchange, the protocol version
is n
Sure, the issue isn't running out of integers, it's that you have to handle
the case of truncated messages whether you like it or not so it doesn't add
any simplicity. Even if Bitcoin-Qt starts only sending the new field with a
new version number, there are tens of thousands of bitcoinj based walle
I don't get why this is such a contentious change?
Before I was able to use asserts to check the expected length of length of
messages per protocol version, I could pass in dumb iterators that just parse
the byte stream and I could serialize and deserialize a message to check the
parser is corr
There's no problem, but there's no benefit either. It also locks us in to a
potentially problematic guarantee - what if in future we want to have, say,
two optional new pieces of data in two different messages. We don't want to
require that if version > X then you have to implement all features up
> which could involve proving something to a third party that has not seen
> the communication between payer and payee.
OK - I think I follow now. So a third-party who does not see any of the
communication between the payer and payee only knows the HASH160. Let's say
the payee denies receipt
On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote:
> Sure but why not do that when there's an actual new field to add? Does
> anyone have a proposal for a feature that needs a new version field at the
> moment? There's no point changing the protocol now unless there's actually
> a new fiel
Yes it is trivial. I do not think greater complexity in the system should keep
us from addressing low complexity issues.
You can't blame me or others not trying to simplify scripts, if there is such a
headwind simplifying a version message.
You are right there is too much fuss about this.
Tamás
You can't eliminate the complexity (yet), otherwise you wouldn't be able to
talk to old nodes. You'll have to wait until versions prior to a particular
version are hard-forked off and can be safely dropped at connect time.
That said the reason I'm being so grumpy about this is that compared to the
I agree that this can be deferred until there is an actual new field without
any harm. But then remember to update the BIP37 too saying that it is optional
only if flag added in BIPXX is not present.
Your argument is that this complexity is already there so why not preserve it.
I think eliminat
On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
> I think Timo's point is that while you cant do discrete log, you can do y-th
> root. So if P = xG is a parent public key (x private key, G base point),
> then your proposed multiplier address is hash of Q=yP. However its easy to
> find
Sure but why not do that when there's an actual new field to add? Does
anyone have a proposal for a feature that needs a new version field at the
moment? There's no point changing the protocol now unless there's actually
a new field to add.
Anyway I still don't see why anyone cares about this issu
Agree with Jeremy and once the payment protocol work is further along I'd
like to see us define an extension that lets you send payment requests
containing public keys+chain codes, so further payments can be made
push-style with no recipient interaction (e.g. for repeated billing). How
apps choose
Hi Mike,
The issue with the current parser is that those fields are conditionally
optional on that there will be no subsequent fields added.
If there will be further fields they will become manadory.
Why not bump the version and parse the fields as mandatory from then on? This
would be backwa
I personally don't treat the relay field as optional, i.e. it is there as
0x01 if it is set. Otherwise, it is simply a trailing zero byte. Hence, the
right way of reading the packet as with any network packet is to first
retrieve the header information, get the actual payload length, then parse
the
The protocol version was bumped when Bloom filtering was added so there's
not much point bumping it again - you have to handle the old clients no
matter what. Nobody brought this up as an issue when the BIP or code was
first written and as you can see from main.cpp, it was done this way to be
consi
20 matches
Mail list logo
