From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ysh9d-0006sh-0H for bitcoin-development@lists.sourceforge.net; Thu, 14 May 2015 00:37:37 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.178 as permitted sender) client-ip=209.85.214.178; envelope-from=pieter.wuille@gmail.com; helo=mail-ob0-f178.google.com; Received: from mail-ob0-f178.google.com ([209.85.214.178]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ysh9c-0004vb-3J for bitcoin-development@lists.sourceforge.net; Thu, 14 May 2015 00:37:36 +0000 Received: by obblk2 with SMTP id lk2so42609100obb.0 for ; Wed, 13 May 2015 17:37:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.23.70 with SMTP id k6mr1315942oef.20.1431563850718; Wed, 13 May 2015 17:37:30 -0700 (PDT) Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 17:37:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 17:37:30 -0700 Message-ID: From: Pieter Wuille To: Tier Nolan Content-Type: multipart/alternative; boundary=047d7b33d4f6cba38c0515ffeeaa X-Spam-Score: -0.6 (/) 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 (pieter.wuille[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 X-Headers-End: 1Ysh9c-0004vb-3J Cc: Bitcoin Dev 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: Thu, 14 May 2015 00:37:37 -0000 --047d7b33d4f6cba38c0515ffeeaa Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 13, 2015 at 1:32 PM, Tier Nolan wrote: > > On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille > wrote: > >> >> This was what I was suggesting all along, sorry if I wasn't clear. >> >> That's great. So, basically the multi-level refund problem is solved by > this? > Yes. So to be clear, I think there are 2 desirable end-goal proposals (ignoring difficulty of changing things for a minute): * Transactions and blocks keep referring to other transactions by full txid, but signature hashes are computed off normalized txids (which are recursively defined to use normalized txids all the way back to coinbases). Is this what you are suggesting now as well? * Blocks commit to full transaction data, but transactions and signature hashes use normalized txids. The benefit of the latter solution is that it doesn't need "fixing up" transactions whose inputs have been malleated, but comes at the cost of doing a very invasive hard fork. -- Pieter --047d7b33d4f6cba38c0515ffeeaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <tier.nola= n@gmail.com> wrote:

On Wed, Ma= y 13, 2015 at 9:31 PM, Pieter Wuille <pieter.wuille@gmail.com>= ; wrote:

This was what I was suggesting all along, sorry if I wasn't clear= .

That's great.=A0 So, basically the multi-lev= el refund problem is solved by this?

Yes. So to be clear, I think there are 2 desirable en= d-goal proposals (ignoring difficulty of changing things for a minute):
=
* Transactions and blocks keep referring to other transactio= ns by full txid, but signature hashes are computed off normalized txids (wh= ich are recursively defined to use normalized txids all the way back to coi= nbases). Is this what you are suggesting now as well?

* B= locks commit to full transaction data, but transactions and signature hashe= s use normalized txids.

The benefit of the latter solutio= n is that it doesn't need "fixing up" transactions whose inpu= ts have been malleated, but comes at the cost of doing a very invasive hard= fork.

--
Pieter

--047d7b33d4f6cba38c0515ffeeaa--