Tom [ARCHIVE] on Nostr: 📅 Original date posted:2016-09-21 📝 Original message:Thanks for your email ...
📅 Original date posted:2016-09-21
📝 Original message: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»
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160921/613bee38/attachment-0001.sig>;
📝 Original message: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»
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160921/613bee38/attachment-0001.sig>;