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-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YsaEX-0005RZ-Vl for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 17:14:13 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.218.48 as permitted sender) client-ip=209.85.218.48; envelope-from=pieter.wuille@gmail.com; helo=mail-oi0-f48.google.com; Received: from mail-oi0-f48.google.com ([209.85.218.48]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsaEW-0001gH-JH for bitcoin-development@lists.sourceforge.net; Wed, 13 May 2015 17:14:13 +0000 Received: by oift201 with SMTP id t201so36541926oif.3 for ; Wed, 13 May 2015 10:14:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.177.86 with SMTP id a83mr16015476oif.14.1431537247174; Wed, 13 May 2015 10:14:07 -0700 (PDT) Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 10:14:07 -0700 (PDT) Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 10:14:07 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 May 2015 10:14:07 -0700 Message-ID: From: Pieter Wuille To: Christian Decker Content-Type: multipart/alternative; boundary=001a113cd2ac19c8b00515f9bdb7 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: 1YsaEW-0001gH-JH 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: Wed, 13 May 2015 17:14:14 -0000 --001a113cd2ac19c8b00515f9bdb7 Content-Type: text/plain; charset=ISO-8859-1 Normalized transaction ids are only effectively non-malleable when all inputs they refer to are also non-malleable (or you can have malleability in 2nd level dependencies), so I do not believe it makes sense to allow mixed usage of the txids at all. They do not provide the actual benefit of guaranteed non-malleability before it becomes disallowed to use the old mechanism. That, together with the +- resource doubling needed for the UTXO set (as earlier mentioned) and the fact that an alternative which is only a softfork are available, makes this a bad idea IMHO. Unsure to what extent this has been presented on the mailinglist, but the softfork idea is this: * Transactions get 2 txids, one used to reference them (computed as before), and one used in an (extended) sighash. * The txins keep using the normal txid, so not structural changes to Bitcoin. * The ntxid is computed by replacing the scriptSigs in inputs by the empty string, and by replacing the txids in txins by their corresponding ntxids. * A new checksig operator is softforked in, which uses the ntxids in its sighashes rather than the full txid. * To support efficiently computing ntxids, every tx in the utxo set (currently around 6M) stores the ntxid, but only supports lookup bu txid still. This does result in a system where a changed dependency indeed invalidates the spending transaction, but the fix is trivial and can be done without access to the private key. On May 13, 2015 5:50 AM, "Christian Decker" wrote: > Hi All, > > I'd like to propose a BIP to normalize transaction IDs in order to address > transaction malleability and facilitate higher level protocols. > > The normalized transaction ID is an alias used in parallel to the current > (legacy) transaction IDs to address outputs in transactions. It is > calculated by removing (zeroing) the scriptSig before computing the hash, > which ensures that only data whose integrity is also guaranteed by the > signatures influences the hash. Thus if anything causes the normalized ID > to change it automatically invalidates the signature. When validating a > client supporting this BIP would use both the normalized tx ID as well as > the legacy tx ID when validating transactions. > > The detailed writeup can be found here: > https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki. > > @gmaxwell: I'd like to request a BIP number, unless there is something > really wrong with the proposal. > > In addition to being a simple alternative that solves transaction > malleability it also hugely simplifies higher level protocols. We can now > use template transactions upon which sequences of transactions can be built > before signing them. > > I hesitated quite a while to propose it since it does require a hardfork > (old clients would not find the prevTx identified by the normalized > transaction ID and deem the spending transaction invalid), but it seems > that hardforks are no longer the dreaded boogeyman nobody talks about. > I left out the details of how the hardfork is to be done, as it does not > really matter and we may have a good mechanism to apply a bunch of > hardforks concurrently in the future. > > I'm sure it'll take time to implement and upgrade, but I think it would be > a nice addition to the functionality and would solve a long standing > problem :-) > > Please let me know what you think, the proposal is definitely not set in > stone at this point and I'm sure we can improve it further. > > Regards, > Christian > > > ------------------------------------------------------------------------------ > 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 > > --001a113cd2ac19c8b00515f9bdb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Normalized transaction ids are only effectively non-malleabl= e when all inputs they refer to are also non-malleable (or you can have mal= leability in 2nd level dependencies), so I do not believe it makes sense to= allow mixed usage of the txids at all. They do not provide the actual bene= fit of guaranteed non-malleability before it becomes disallowed to use the = old mechanism. That, together with the +- resource doubling needed for the = UTXO set (as earlier mentioned) and the fact that an alternative which is o= nly a softfork are available, makes this a bad idea IMHO.

Unsure to what extent this has been presented on the mailing= list, but the softfork idea is this:
* Transactions get 2 txids, one used to reference them (computed as before)= , and one used in an (extended) sighash.
* The txins keep using the normal txid, so not structural changes to Bitcoi= n.
* The ntxid is computed by replacing the scriptSigs in inputs by the empty = string, and by replacing the txids in txins by their corresponding ntxids.<= br> * A new checksig operator is softforked in, which uses the ntxids in its si= ghashes rather than the full txid.
* To support efficiently computing ntxids, every tx in the utxo set (curren= tly around 6M) stores the ntxid, but only supports lookup bu txid still.

This does result in a system where a changed dependency inde= ed invalidates the spending transaction, but the fix is trivial and can be = done without access to the private key.

On May 13, 2015 5:50 AM, "Christian Decker&= quot; <decker.christian@gm= ail.com> wrote:
Hi All,

I'd like to propos= e a BIP to normalize transaction IDs in order to address transaction mallea= bility and facilitate higher level protocols.

The normal= ized transaction ID is an alias used in parallel to the current (legacy) tr= ansaction IDs to address outputs in transactions. It is calculated by remov= ing (zeroing) the scriptSig before computing the hash, which ensures that o= nly data whose integrity is also guaranteed by the signatures influences th= e hash. Thus if anything causes the normalized ID to change it automaticall= y invalidates the signature. When validating a client supporting this BIP w= ould use both the normalized tx ID as well as the legacy tx ID when validat= ing transactions.


@gmaxwell: = I'd like to request a BIP number, unless there is something really wron= g with the proposal.

In addition to being a simple= alternative that solves transaction malleability it also hugely simplifies= higher level protocols. We can now use template transactions upon which se= quences of transactions can be built before signing them.

I hesitated quite a while to propose it since it does require a har= dfork (old clients would not find the prevTx identified by the normalized t= ransaction ID and deem the spending transaction invalid), but it seems that= hardforks are no longer the dreaded boogeyman nobody talks about.
I left out the details of how the hardfork is to be done, as it does not = really matter and we may have a good mechanism to apply a bunch of hardfork= s concurrently in the future.

I'm sure it'= ll take time to implement and upgrade, but I think it would be a nice addit= ion to the functionality and would solve a long standing problem :-)
<= div>
Please let me know what you think, the proposal is defin= itely not set in stone at this point and I'm sure we can improve it fur= ther.

Regards,
Christian

-----------------------------------------------------------------------= -------
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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a113cd2ac19c8b00515f9bdb7--