bitcoin-development@lists.sourceforge.net
Sent: Wednesday, June 19, 2013 3:20 PM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
If you want to criticise the Bitcoin protocol for sloppyness, the variable
length of some messages isn't where I'd start.
Note that ping
bitcoin-development@lists.sourceforge.net
*Sent:* Wednesday, June 19, 2013 3:20 PM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
If you want to criticise the Bitcoin protocol for sloppyness, the variable
length of some messages isn't where I'd start.
Note that ping has
:* Wednesday, June 19, 2013 3:20 PM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
If you want to criticise the Bitcoin protocol for sloppyness, the variable
length of some messages isn't where I'd start.
Note that ping has the same issue, its length has changed over
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
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
-development@lists.sourceforge.net; Tamas Blummer
ta...@bitsofproof.com
Sent: Thursday, June 20, 2013 11:17 AM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version
There's no problem, but there's no benefit either. It also locks us in to a
potentially problematic guarantee - what
ta...@bitsofproof.com
*Sent:* Thursday, June 20, 2013 11:17 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version
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
m...@plan99.net
*To:* Pieter Wuille pieter.wui...@gmail.com
*Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net; Tamas
Blummer ta...@bitsofproof.com
*Sent:* Thursday, June 20, 2013 11:17 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version
There's no problem
:* Thursday, June 20, 2013 11:17 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version
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
turkeybre...@yahoo.com
Cc: bitcoin-development@lists.sourceforge.net
bitcoin-development@lists.sourceforge.net
Sent: Wednesday, June 19, 2013 11:39 AM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It has to be optional because old clients don't send it, obviously.
Why
@lists.sourceforge.net
*Sent:* Wednesday, June 19, 2013 11:39 AM
*Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
It has to be optional because old clients don't send it, obviously.
Why is this even an issue? There's no problem with variable length
messages in any codebase that I'm
: [Bitcoin-development] Missing fRelayTxes in version
message
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have
always been variable length. There's nothing inherent
-development@lists.sourceforge.net
bitcoin-development@lists.sourceforge.net
Sent: Wednesday, June 19, 2013 11:39 AM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It has to be optional because old clients don't send it, obviously.
Why is this even an issue
See this BIP. I'm not sure if this is a bug or what, but it would be good if
messages always had a fixed number of fields per protocol version.
https://en.bitcoin.it/wiki/BIP_0060#Code_Updates
This BIP details everything that needs to be done and proposes a protocol
upgrade.
It's not a bug (although there was recently a change to make bitcoind/qt
always send this field anyway).
I don't know where Amir is going with BIP 60. Version messages have always
been variable length. There's nothing inherent in the Bitcoin protocol that
says all messages are fixed length,
needs to be
optional anyway.
From: Mike Hearn m...@plan99.net
To: Turkey Breast turkeybre...@yahoo.com
Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net
Sent: Tuesday, June 18, 2013 9:48 PM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version
21 matches
Mail list logo
