Date: Fri, 23 Sep 2016 13:42:36 +0200
From: Christian Decker <decker.christian@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20160923114236.GA17871@nex>
Mail-Followup-To: Christian Decker <decker.christian@gmail.com>,
	bitcoin-dev@lists.linuxfoundation.org
References: <7844645.RLYLWYmWtM@garp> <1988067.b5KirJFSKj@garp>
	<20160922111049.GA592@nex> <6286144.BZfBM3Z3un@garp>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <6286144.BZfBM3Z3un@garp>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [bitcoin-dev] Requesting BIP assignment; Flexible Transactions.
Precedence: list

On Thu, Sep 22, 2016 at 02:09:38PM +0200, Tom via bitcoin-dev wrote:
> On Thursday 22 Sep 2016 13:10:49 Christian Decker via bitcoin-dev wrote:
> > 
> > I think BIPs should be self-contained, or rely on previous BIPs,
> > whenever possible. Referencing an external formatting document should
> > be avoided 
> 
> If luke-jr thinks I should submit CMF as a BIP, I can certainly do that.
> Luke, what do you think?
> 
> I don't have a preference either way.
> 
> > 
> > So the presence is signaled by encountering the tag, which contains
> > both token type and name-reference. The encoder and decoder operations
> > could be described better.
> 
> I'm sorry, I'm not following you here. Is there a question?

Nope, just clarifying how presence or absence is indicated :-)

> > 
> > Minor nit: that table is not well-formed.
> 
> I am not very well versed in mediawiki tables, and I found github has some 
> incompatibilities too.
> The markdown one looks better;
> https://github.com/bitcoinclassic/documentation/blob/master/spec/transactionv4.md

It's just some rows have 3 columns, others have 2. It's a minor nit
really.

> > As was pointed out in the
> > normalized transaction ID BIP, your proposal only addresses
> > third-party malleability, since signers can simply change the
> > transaction and re-sign it.
> 
> 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. Always referring to "third-party malleability" avoids
this ambiguity.

> > This is evident from the fact that inputs
> > and outputs do not have a canonical order and it would appear that
> > tokens can be re-ordered in segments. 
> 
> Sorry, what is evident? You seem to imply that it is uncommon that you can 
> create two transactions of similar intent but using different bytes.
> You would be wrong with this implication as this is very common. You can just 
> alter the order of the inputs, for instance.
> 
> I am unable to see what the point is you are trying to make. Is there a 
> question or a suggestion for improvement here?
> 
> > Dependencies of tokens inside a
> > segment are also rather alarming (TxInPrevHash <-> TxInPrevIndex,
> > TxOutScript <-> TxOutValue).
> 
> Maybe you missed this line; 
>   ŤTxInPrevHash and TxInPrevIndex
>    Index can be skipped, but in any input the PrevHash always has
>    to come firstť

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 you still see something alarming, let me know.
> You can look at the code in Bitcoin Classic and notice that it really isn't 
> anything complicated or worrying.
> 
> 
> > Finally, allowing miners to reject transactions with unknown fields
> > makes the OP_NOPs unusable 
> 
> Hmm, it looks like you are mixing terminology and abstraction-levels.  OP_NOP 
> is a field from script and there is no discussion about any rejection based on 
> script in this BIP at all.
> 
> Rejection of transactions is done on there being unrecognised tokens in the 
> transaction formatting itself.

Ah, thanks for clearing that up. However, the problem persists, 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.

> Thank you for your email to my BIP, I hope you got the answers you were 
> looking for :)

Cheers,
Christian