From: Peter Todd <pete@petertodd•org>
To: Tom <tomz@freedommail•ch>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Date: Thu, 22 Sep 2016 14:26:18 -0400 [thread overview]
Message-ID: <20160922182618.GA19147@fedora-21-dvm> (raw)
In-Reply-To: <5590176.JJpBoGr4Tc@garp>
[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-09-22 18:26 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 17:15 Tom
2016-09-20 21:31 ` Luke Dashjr
2016-09-21 9:32 ` Tom
2016-09-20 21:56 ` Peter Todd
2016-09-21 9:32 ` Tom
2016-09-22 18:26 ` Peter Todd [this message]
2016-09-22 18:47 ` Tom
2016-09-21 12:00 ` Andreas Schildbach
2016-09-21 12:58 ` Tom
[not found] ` <CAAS2fgSpnshZhS7N5R3Qsw_8=NN8sjYGwrnUpdwGzu2TG0-Qgw@mail.gmail.com>
2016-09-21 18:01 ` Gregory Maxwell
2016-09-22 8:56 ` Tom
2016-09-22 11:10 ` Christian Decker
2016-09-22 12:09 ` Tom
2016-09-23 11:42 ` Christian Decker
2016-09-23 13:17 ` Tom
2016-09-21 22:45 adiabat
2016-09-22 8:47 ` Tom
2016-09-22 18:27 ` Peter Todd
2016-09-22 18:37 ` Tom
2016-09-22 19:59 ` Jonas Schnelli
2016-09-22 20:07 ` Tom
2016-09-23 11:55 ` Christian Decker
2016-09-23 13:13 ` Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160922182618.GA19147@fedora-21-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tomz@freedommail$(echo .)ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox