Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 00C93AF4 for ; Thu, 22 Sep 2016 18:47:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out03.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3261B2B8 for ; Thu, 22 Sep 2016 18:47:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at kolabnow.com X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from mx04.mykolab.com (mx04.mykolab.com [10.20.7.102]) by mx-out03.mykolab.com (Postfix) with ESMTPS id ECB34240D9 for ; Thu, 22 Sep 2016 20:47:51 +0200 (CEST) From: Tom To: Bitcoin Protocol Discussion Date: Thu, 22 Sep 2016 20:47:50 +0200 Message-ID: <2619297.H12PQLatFI@kiwi> In-Reply-To: <20160922182618.GA19147@fedora-21-dvm> References: <7844645.RLYLWYmWtM@garp> <5590176.JJpBoGr4Tc@garp> <20160922182618.GA19147@fedora-21-dvm> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Sep 2016 18:53:22 +0000 Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Sep 2016 18:47:55 -0000 On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote: > > =ABThe 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=BB >=20 > That argument is not applicable to required fields:=20 The argument that optional fields can be omitted is not applicable to=20 required fields, you are correct. That should be rather obvious because=20 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=20 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. > >=20 > > Please argue your case. >=20 > 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= =20 reference like that, if you want to convince me you could you at least=20 provide a URL? You want me to see the value of your idea, I think you should at least=20 provide the argument. Isn't that fair? Thanks for your email Peter, would love you to put a bit more time into=20 understanding flexible transactions and we can have a proper discussion=20 about it.