Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsdFR-0006FD-9V for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 20:27:21 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.171 as permitted sender) client-ip=209.85.220.171; envelope-from=tier.nolan@gmail.com; helo=mail-qk0-f171.google.com; Received: from mail-qk0-f171.google.com ([209.85.220.171]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsdFQ-0003Wb-AF for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 20:27:21 +0000 Received: by qkgy4 with SMTP id y4so36646655qkg.2 for ; Wed, 13 May 2015 13:27:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.217.17 with SMTP id n17mr998385qhb.69.1431548834931; Wed, 13 May 2015 13:27:14 -0700 (PDT) Received: by 10.140.85.241 with HTTP; Wed, 13 May 2015 13:27:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 21:27:14 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a1139b816c8e8d80515fc6f82 X-Spam-Score: 2.3 (++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (tier.nolan[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 1.9 MALFORMED_FREEMAIL Bad headers on message from free email service -0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YsdFQ-0003Wb-AF Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 20:27:21 -0000 --001a1139b816c8e8d80515fc6f82 Content-Type: text/plain; charset=UTF-8 After more thought, I think I came up with a clearer description of the recursive version. The simple definition is that the hash for the new signature opcode should simply assume that the normalized txid system was used since the beginning. All txids in the entire blockchain should be replaced with the "correct" values. This requires a full re-index of the blockchain. You can't work out what the TXID-N of a transaction is without knowning the TXID-N of its parents, in order to do the replacement. The non-recursive version can only handle refunds one level deep. A: from: IN sigA: based on hash(...) B: from A sig: based on hash(from: TXID-N(A) | "") // sig removed C: from B sig: based on hash(from: TXID-N(B) | "") // sig removed If A is mutated before being added into the chain, then B can be modified to a valid transaction (B-new). A-mutated: from: IN sig_mutated: based on hash(...) with some mutation B has to be modified to B-new to make it valid. B-new: from A-mutated sig: based on hash(from: TXID-N(A-mutated), "") Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is still valid. Howver, C-new cannot be created. C-new: from B-new sig: based on hash(from: TXID-N(B-new), "") TXID-N(B-new) is not the same as TXID-N(B). Since the from field is not removed by the TXID-N operation, differences in that field mean that the TXIDs are difference. This means that the signature for C is not valid for C-new. The recursive version repairs this problem. Rather than simply delete the scriptSig from the transaction. All txids must also be replaced with their TXID-N versions. Again, A is mutated before being added into the chain and B-new is produced. A-mutated: from: IN sig_mutated: based on hash(...) with some mutation TXID-N: TXID-N(A) B has to be modified to B-new to make it valid. B-new: from A-mutated sig: based on hash(from: TXID-N(A-mutated), "") TXID-N: TXID-N(B) Since TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is still valid. Likewise the TXID-N(B-new) is equal to TXID-N(B). The from field is replaced by the TXID-N from A-mutated which is equal to TXID-N(A) and the sig is the same. C-new: from B-new sig: based on hash(from: TXID-N(B-new), "") The signature is still valid, since TXID-N(B-new) is the same as TXID-N(B). This means that multi-level refunds are possible. --001a1139b816c8e8d80515fc6f82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After more thought, I think I came up with a clearer = description of the recursive version.

The simple definition is that = the hash for the new signature opcode should simply assume that the normali= zed txid system was used since the beginning.=C2=A0 All txids in the entire= blockchain should be replaced with the "correct" values.

= This requires a full re-index of the blockchain.=C2=A0 You can't work o= ut=20 what the TXID-N of a transaction is without knowning the TXID-N of its=20 parents, in order to do the replacement.

The non-recursive version c= an only handle refunds one level deep.

A:
from: IN
sigA: based= on hash(...)

B:
from A
sig: based on hash(from: TXID-N(A) | &= quot;")=C2=A0 // sig removed

C:
from B
sig: based on hash= (from: TXID-N(B) | "")=C2=A0 // sig removed

If A is mutate= d before being added into the chain, then B can be modified to a valid tran= saction (B-new).

A-mutated:
from: IN
sig_mutated: based on has= h(...) with some mutation

B has to be modified to B-new to make it v= alid.

B-new:
from A-mutated
sig: based on hash(from: TXID-N(A-= mutated), "")

Since TXID-N(A-mutated) is equal to TXID-N(A= ), the signature from B is still valid.

Howver, C-new cannot be crea= ted.

C-new:
from B-new
sig: based on hash(from: TXID-N(B-new),= "")

TXID-N(B-new) is not the same as TXID-N(B).=C2=A0 Sin= ce the from field is not removed by the TXID-N operation, differences in th= at field mean that the TXIDs are difference.

This means that the sig= nature for C is not valid for C-new.

The recursive version repairs t= his problem.=C2=A0

Rather than simply delete the scriptSig from the= transaction.=C2=A0 All txids must also be replaced with their TXID-N versi= ons.

Again, A is mutated before being added into the chain and B-new= is produced.

A-mutated:
from: IN
sig_mutated: based on hash(.= ..) with some mutation
TXID-N: TXID-N(A)

B has to be modified to = B-new to make it valid.

B-new:
from A-mutated
sig: based on ha= sh(from: TXID-N(A-mutated), "")
TXID-N: TXID-N(B)

Since= TXID-N(A-mutated) is equal to TXID-N(A), the signature from B is still val= id.

Likewise the TXID-N(B-new) is equal to TXID-N(B).

The fro= m field is replaced by the TXID-N from A-mutated which is equal to TXID-N(A= ) and the sig is the same.

C-new:
from B-new
sig: based on has= h(from: TXID-N(B-new), "")

The signature is still valid, s= ince TXID-N(B-new) is the same as TXID-N(B).

This means that m= ulti-level refunds are possible.
--001a1139b816c8e8d80515fc6f82--