From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 93F82C20 for ; Fri, 23 Sep 2016 13:17:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mx-out01.mykolab.com (mx.kolabnow.com [95.128.36.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 05A60124 for ; Fri, 23 Sep 2016 13:17:55 +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-out01.mykolab.com (Postfix) with ESMTPS id 6E0EC627FB for ; Fri, 23 Sep 2016 15:17:53 +0200 (CEST) From: Tom To: bitcoin-dev@lists.linuxfoundation.org Date: Fri, 23 Sep 2016 15:17:52 +0200 Message-ID: <34304783.iUnM6JERa9@kiwi> In-Reply-To: <20160923114236.GA17871@nex> References: <7844645.RLYLWYmWtM@garp> <6286144.BZfBM3Z3un@garp> <20160923114236.GA17871@nex> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 23 Sep 2016 13:21:05 +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: Fri, 23 Sep 2016 13:17:56 -0000 On Friday, 23 September 2016 13:42:36 CEST Christian Decker via bitcoin-dev wrote: > > I have to disagree. That is not malleability. Creating a new document > > and re- signing it is not changing anything. Its re-creating. > > Something that the owner of the coin has every right to do. > Same thing I was arguing back then, however Luke pointed out that > malleability just refers to the possibility of modifying a transaction > after the fact. I am not a fan of redefining dictionary words. I'll stick to the universally excepted one, thanks. > Nope, that is exactly the kind of dependency I was talking > about. Instead of nesting a construct like the current transactions > do, you rely on the order of tokens to imply that they belong > together. > if we > add new fields that a non-upgraded node doesn't know about and it > rejects transactions containing it, we'll have a hard-fork. It should > probably not reject transactions with unknown fields if the > transaction is included in a block. This is addressed here; https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki#future-extensibility