I never said that Bitcoin message field lengths should always be the same. But
before this change they certainly were constant per protocol version. All I'm
saying is that optional lengths shouldn't be used (a field exists or not) and
for every field change, the protocol version should be
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
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
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
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
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
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
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
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 field
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
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
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
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
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
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
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
16 matches
Mail list logo
