From: Tom <tomz@freedommail.ch>
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"
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list

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