Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-22 📝 Original message:On Wed, Sep 21, 2016 at ...
📅 Original date posted:2016-09-22
📝 Original message:On Wed, Sep 21, 2016 at 11:32:33AM +0200, Tom wrote:
> Thanks for your email Peter!
>
> On Tuesday 20 Sep 2016 17:56:44 Peter Todd wrote:
> > On Tue, Sep 20, 2016 at 07:15:45PM +0200, Tom via bitcoin-dev wrote:
> > > === Serialization order===
> > >
> > > The tokens defined above have to be serialized in a certain order for the
> > > transaction to be well-formatted. Not serializing transactions in the
> > > order specified would allow multiple interpretations of the data which
> > > can't be allowed.
> >
> > If the order of the tokens is fixed, the tokens themselves are redundant
> > information when tokens are required; when tokens may be omitted, a simple
> > "Some/None" flag to mark whether or not the optional data has been omitted
> > is appropriate.
>
> This is addressed in the spec;
> https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md
>
> «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 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.
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.
> > 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160922/00bc0bdd/attachment.sig>;
📝 Original message:On Wed, Sep 21, 2016 at 11:32:33AM +0200, Tom wrote:
> Thanks for your email Peter!
>
> On Tuesday 20 Sep 2016 17:56:44 Peter Todd wrote:
> > On Tue, Sep 20, 2016 at 07:15:45PM +0200, Tom via bitcoin-dev wrote:
> > > === Serialization order===
> > >
> > > The tokens defined above have to be serialized in a certain order for the
> > > transaction to be well-formatted. Not serializing transactions in the
> > > order specified would allow multiple interpretations of the data which
> > > can't be allowed.
> >
> > If the order of the tokens is fixed, the tokens themselves are redundant
> > information when tokens are required; when tokens may be omitted, a simple
> > "Some/None" flag to mark whether or not the optional data has been omitted
> > is appropriate.
>
> This is addressed in the spec;
> https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md
>
> «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 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.
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.
> > 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160922/00bc0bdd/attachment.sig>;