Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id F3FCEBFF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 23 Sep 2016 11:42:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1442C1CA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 23 Sep 2016 11:42:39 +0000 (UTC)
Received: by mail-wm0-f47.google.com with SMTP id l132so25048718wmf.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 23 Sep 2016 04:42:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:mail-followup-to:references
	:mime-version:content-disposition:content-transfer-encoding
	:in-reply-to:user-agent;
	bh=+jUvItm/gsacXHuCCBzr0qn12v1ZkrHQMgw/BYlGfqM=;
	b=Bb661zjcwxDR9Li0VEdtPXseBc9I/MOSVaxZFZhGHttGRiheZhjxZTAhb/ZrcPIA2V
	vcM+bNozKKJHiEa4vBY4X1J3CGPMEQD4H/xk+4QeeX/fw3Jk/pZ/ohmGZg6gREI0KERx
	kMnxHGbzWU6rTnlruCe/5Ij9LSjQpZcP+6U8XByEWvpQCSwVSyg6wQOyerW6lrR17sjq
	DL/0evBX7iYOkmkO9knnz9kQJ3Xeov9oxK4KgyBS524aH8iWe9tyIeaUMM+twJBQHmGo
	zMMiIzD/VDVo8fTL6zFbR1PdDIlWjscbeNQwdKLbbcQLk15cK23TfgRicnEG3mIy8myG
	rbpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to
	:references:mime-version:content-disposition
	:content-transfer-encoding:in-reply-to:user-agent;
	bh=+jUvItm/gsacXHuCCBzr0qn12v1ZkrHQMgw/BYlGfqM=;
	b=MXwNvL0NBojvOc6XHq96U3n6ovU1l2rTsqhRQrM2Q50L++Fv1kdWw0gkimAzGqx/qd
	mdMSWAYAyDbUWlHd/OeAhKPjeEtiDY6MkE1BclpmoV6fZFywds69kJNWiRWjZnzEGsdU
	7dyec/3MNg7SkIOiMqikwZekrVv7CKiS7yietnmueqzxpJv4scklC7ubbnWVjYng8sEt
	ysnKqZbiTES6ubXgCaSrOkcm97NOX5Y62TXMXOaTeOAKbLgL6bGxp1LlZF3WDtTcg11p
	BSTKr6VdC8MLtBIpy6+vZBc4M3TTxJUQO47paIbP97sYokkc7i1kvgawtNRcr+3YaFEc
	/E8A==
X-Gm-Message-State: AA6/9RmMwrkcz3LEyCXfJYZzgG+vVsuFDhV9GHX588LK5+j6pN6KyYKIk9zBywBlYGwEmw==
X-Received: by 10.28.14.20 with SMTP id 20mr2666989wmo.6.1474630957527;
	Fri, 23 Sep 2016 04:42:37 -0700 (PDT)
Received: from nex ([2a02:aa16:1105:4a80:eca1:a51:7a7c:5e35])
	by smtp.gmail.com with ESMTPSA id g7sm6798663wjc.43.2016.09.23.04.42.36
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_2 cipher=AES128-SHA bits=128/128);
	Fri, 23 Sep 2016 04:42:36 -0700 (PDT)
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)
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Sep 2016 11:42:40 -0000

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