Tom [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-22 📝 Original message:On Thursday, 22 September ...
📅 Original date posted:2016-09-22
📝 Original message:On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote:
> > «The way towards that flexibility is to use a generic concept made
> > popular various decades ago with the XML format. The idea is that we
> > give each field a name and this means that new fields can be added or
> > optional fields can be omitted from individual transactions»
>
> That argument is not applicable to required fields:
The argument that optional fields can be omitted is not applicable to
required fields, you are correct. That should be rather obvious because
required fields are not optional fields.
> the code to get the
> fields from the extensible format is every bit as complex as the very
> simple code required to deserialize/serialize objects in the current
> system.
Probably a tiny bit more complex as the current format assumes a lot more.
You may have misread my email because there was no argument made towards
complexity. The argument was towards flexibility.
> In any case your BIP needs to give some explicit examples of hypothetical
> upgrades in the future, how they'd take advantage of this, and what the
> code to do so would look like.
Why?
> > > Also, if you're going to break compatibility with all existing
> > > software, it makes sense to use a format that extends the merkle
> > > tree down into the transaction inputs and outputs.
> >
> > Please argue your case.
>
> See my arguments re: segwit a few months ago, e.g. the hardware wallet
> txin proof use-case.
Please consider that I'm not going to search for something based on a vague
reference like that, if you want to convince me you could you at least
provide a URL?
You want me to see the value of your idea, I think you should at least
provide the argument. Isn't that fair?
Thanks for your email Peter, would love you to put a bit more time into
understanding flexible transactions and we can have a proper discussion
about it.
📝 Original message:On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote:
> > «The way towards that flexibility is to use a generic concept made
> > popular various decades ago with the XML format. The idea is that we
> > give each field a name and this means that new fields can be added or
> > optional fields can be omitted from individual transactions»
>
> That argument is not applicable to required fields:
The argument that optional fields can be omitted is not applicable to
required fields, you are correct. That should be rather obvious because
required fields are not optional fields.
> the code to get the
> fields from the extensible format is every bit as complex as the very
> simple code required to deserialize/serialize objects in the current
> system.
Probably a tiny bit more complex as the current format assumes a lot more.
You may have misread my email because there was no argument made towards
complexity. The argument was towards flexibility.
> In any case your BIP needs to give some explicit examples of hypothetical
> upgrades in the future, how they'd take advantage of this, and what the
> code to do so would look like.
Why?
> > > Also, if you're going to break compatibility with all existing
> > > software, it makes sense to use a format that extends the merkle
> > > tree down into the transaction inputs and outputs.
> >
> > Please argue your case.
>
> See my arguments re: segwit a few months ago, e.g. the hardware wallet
> txin proof use-case.
Please consider that I'm not going to search for something based on a vague
reference like that, if you want to convince me you could you at least
provide a URL?
You want me to see the value of your idea, I think you should at least
provide the argument. Isn't that fair?
Thanks for your email Peter, would love you to put a bit more time into
understanding flexible transactions and we can have a proper discussion
about it.