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 Blummer
Founder, CEO
http://bitsofproof.com
On 20.06.2013, at 10:31, Mike Hearn <m...@plan99.net> wrote:
> 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
> complexity in the rest of the system, this is such a trivial and minor
> detail. It's hardly even worth thinking about. I mean, we have a scripting
> language full of opcodes nobody ever figured out how to use and the protocol
> uses a mixture of byte orders, so an optional field in the version message is
> really not such a big deal :)
>
>
> On Thu, Jun 20, 2013 at 10:17 AM, Tamas Blummer <ta...@bitsofproof.com> wrote:
> 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 eliminating complexity (that has no benefit) strengthens the
> system.
>
> Tamás Blummer
> http://bitsofproof.com
>
> On 20.06.2013, at 09:36, Mike Hearn <m...@plan99.net> 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 to add.
>>
>> Anyway I still don't see why anyone cares about this issue. The Bitcoin
>> protocol does not and never has required that all messages have a fixed
>> number of fields per version. Any parser written on the assumption it did
>> was just buggy. Look at how tx messages are relayed for the most obvious
>> example of that pattern in action - it's actually the raw byte stream that's
>> stored and relayed to ensure that fields added in new versions aren't
>> dropped during round-tripping. Old versions are supposed to preserve fields
>> from the future.
>>
>>
>>
>> On Thu, Jun 20, 2013 at 9:30 AM, Tamas Blummer <ta...@bitsofproof.com> wrote:
>> 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 backward compatible and cleaner
>> going forward.
>>
>> Tamas Blummer
>> http://bitsofproof.com
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Windows:
>>
>> Build for Windows Store.
>>
>> http://p.sf.net/sfu/windows-dev2dev
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
