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
ocol version number from 70001 to
>> 70002? It's not like we'll run out of integers. The field has now gone from
>> optional to required now anyway - that's a behaviour change. It'd be good
>> to enforce that. I see this as a bug.
>>
>> -
om 70001 to
> 70002? It's not like we'll run out of integers. The field has now gone from
> optional to required now anyway - that's a behaviour change. It'd be good
> to enforce that. I see this as a bug.
>
> --
> *From:* Mike Hearn
> *To:* Pieter Wuille
iour change. It'd be good
> to enforce that. I see this as a bug.
>
> --
> *From:* Mike Hearn
> *To:* Pieter Wuille
> *Cc:* Bitcoin Dev ; Tamas
> Blummer
> *Sent:* Thursday, June 20, 2013 11:17 AM
> *Subject:* Re: [Bitcoin-development] Missi
lle
Cc: Bitcoin Dev ; Tamas Blummer
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
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
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
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
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
p other implementations to have an unclear behaviour
> that depends on some magic from one implementation.
>
> --
> *From:* Mike Hearn
> *To:* Turkey Breast
> *Cc:* "bitcoin-development@lists.sourceforge.net" <
> bitcoin-development@list
> bitcoin-development@lists.sourceforge.net" <
> 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
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 time to inclu
ent@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
s solving some actual
>> problem?
>>
>>
>> On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast
>> wrote:
>>
>> That's me. I never said to make all messages fixed length. I said to make
>> a fixed number of fields per protocol. So given a protoco
@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.
key Breast
Cc: "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? There'
a 1 byte flag
> needs to be optional anyway.
>
> --
> *From:* Mike Hearn
> *To:* Turkey Breast
> *Cc:* Bitcoin Dev
> *Sent:* Tuesday, June 18, 2013 9:48 PM
> *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version message
>
byte flag needs to be
optional anyway.
From: Mike Hearn
To: Turkey Breast
Cc: Bitcoin Dev
Sent: Tuesday, June 18, 2013 9:48 PM
Subject: Re: [Bitcoin-development] Missing fRelayTxes in version message
It's not a bug (although there was recently a
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, indeed
22 matches
Mail list logo
