Date: Thu, 22 Sep 2016 14:26:18 -0400
From: Peter Todd <pete@petertodd.org>
To: Tom <tomz@freedommail.ch>
Message-ID: <20160922182618.GA19147@fedora-21-dvm>
References: <7844645.RLYLWYmWtM@garp> <20160920215644.GA12030@fedora-21-dvm>
	<5590176.JJpBoGr4Tc@garp>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62"
Content-Disposition: inline
In-Reply-To: <5590176.JJpBoGr4Tc@garp>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list


--+QahgC5+KEYLbs62
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Sep 21, 2016 at 11:32:33AM +0200, Tom wrote:
> Thanks for your email Peter!
>=20
> 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:
> > > =3D=3D=3D Serialization order=3D=3D=3D
> > >=20
> > > 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.
> >=20
> > If the order of the tokens is fixed, the tokens themselves are redundant
> > information when tokens are required; when tokens may be omitted, a sim=
ple
> > "Some/None" flag to mark whether or not the optional data has been omit=
ted
> > is appropriate.
>=20
> This is addressed in the spec;=20
> https://github.com/bitcoinclassic/documentation/blob/master/spec/transact=
ionv4.md
>=20
> =ABThe way towards that flexibility is to use a generic concept made popu=
lar
> 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 fiel=
ds
> can be omitted from individual transactions=BB

That argument is not applicable to required fields: the code to get the fie=
lds
=66rom 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 cod=
e 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.
>=20
> Please argue your case.

See my arguments re: segwit a few months ago, e.g. the hardware wallet txin
proof use-case.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--+QahgC5+KEYLbs62
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJX5CJHAAoJEGOZARBE6K+yfxcH/1a0I8VlQfPST386Kw6n8jgw
1MQlfL7N8X/P7X9nss/B/TNveaTuwi9/5M3fMxPF/zoBbFOOBszkNmqYaD2ONdak
rGlouZnQ3CJpQzQrScLwHQ5tNHVL9E6VXBrg4XIkbu2PEMZHDVyWTjHGT6R9+Zvc
oLJvq5XDZwp/rACv+FCAcGNjXrEXq7kKHgz/SuRWw+ejTDhrXmJDRb9NNgrAX5eX
CFQZtWWy1pAboJRkEP+dpn/aA0gDo5rJpWKnzdmSWK1UyWlUlKh3agvhuMqZwLOZ
ghs+QgcnwTIAM3XDtXKU6Xc72RAxJX2NR07+N+2ggr9TIBBxSmpmwf2BXGRrpx4=
=Vl/E
-----END PGP SIGNATURE-----

--+QahgC5+KEYLbs62--