From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Ysqty-0001X6-Os for bitcoin-development@lists.sourceforge.net; Thu, 14 May 2015 11:02:06 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.48 as permitted sender) client-ip=209.85.215.48; envelope-from=decker.christian@gmail.com; helo=mail-la0-f48.google.com; Received: from mail-la0-f48.google.com ([209.85.215.48]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Ysqtw-0000zf-2I for bitcoin-development@lists.sourceforge.net; Thu, 14 May 2015 11:02:06 +0000 Received: by labbd9 with SMTP id bd9so62062932lab.2 for ; Thu, 14 May 2015 04:01:57 -0700 (PDT) X-Received: by 10.112.131.104 with SMTP id ol8mr2818207lbb.58.1431601317726; Thu, 14 May 2015 04:01:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Christian Decker Date: Thu, 14 May 2015 11:01:56 +0000 Message-ID: To: Pieter Wuille , Tier Nolan Content-Type: multipart/alternative; boundary=047d7b3a86d600d2d2051608a857 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 (decker.christian[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: 1Ysqtw-0000zf-2I 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 11:02:06 -0000 --047d7b3a86d600d2d2051608a857 Content-Type: text/plain; charset=UTF-8 Ok, I think I got the OP_CHECKAWESOMESIG proposal, transactions keep referencing using hashes of complete transactions (including signatures), while the OP_CHECKAWESOMESIG looks up the previous transaction (which we already need to do anyway in order to insert the prevOut pubkeyScript), normalizes the prevout and calculates its normalized transaction ID. It then inserts the normalized transaction IDs in the OutPoint before calculating its own hash which is then signed. Is that correct so far? Let me try to summarize the discussion so far: I think we have consensus that transaction malleability needs to be addressed, and normalized transaction IDs seem to be the way to go forward. The discussion now is how to use normalized transaction IDs and we have two approaches to implement them: - OP_CHECKAWESOMESIG which continues to use the current hashes to reference a specific signed instance of a class of semantically identical transactions. Internally only the semantic class is enforced. Transactions can be fixed to reference the correct signed instance if the transaction has been changed along the way.is a softfork using the "if I don't know this opcode the TX is automatically valid" trick On Thu, May 14, 2015 at 2:40 AM Pieter Wuille wrote: > 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 > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --047d7b3a86d600d2d2051608a857 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, I think I got the OP_CHECKAWESOMESIG proposal, transac= tions keep referencing using hashes of complete transactions (including sig= natures), while the OP_CHECKAWESOMESIG looks up the previous transaction (w= hich we already need to do anyway in order to insert the prevOut pubkeyScri= pt), normalizes the prevout and calculates its normalized transaction ID. I= t then inserts the normalized transaction IDs in the OutPoint before calcul= ating its own hash which is then signed. Is that correct so far?

Let me try to summarize the discussion so far:

I think we have consensus that transaction malleability needs to be a= ddressed, and normalized transaction IDs seem to be the way to go forward.<= /div>

The discussion now is how to use normalized transa= ction IDs and we have two approaches to implement them:
  • O= P_CHECKAWESOMESIG which continues to use the current hashes to reference a = specific signed instance of a class of semantically identical transactions.= Internally only the semantic class is enforced. Transactions can be fixed = to reference the correct signed instance if the transaction has been change= d along the way.is a softfork using the "= ;if I don't know this opcode the TX is automatically valid" trick<= /li>

On Thu, May 14, 2015 at = 2:40 AM Pieter Wuille <pieter= .wuille@gmail.com> wrote:
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan <= tier.nolan@gmail.= com> wrote:

On Wed,= May 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 cl= ear.

<= /div>
That's great.=C2=A0 So, basically the mul= ti-level refund problem is solved by this?

Yes. So to be clear, I think ther= e are 2 desirable end-goal proposals (ignoring difficulty of changing thing= s 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 o= f the latter solution is that it doesn't need "fixing up" tra= nsactions whose inputs have been malleated, but comes at the cost of doing = a very invasive hard fork.

--
Pieter<= br>
---------------------------------------------------------------------------= ---
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/= clk/290420510;117567292;y______________________________________________= _
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--047d7b3a86d600d2d2051608a857--