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; 
MIME-Version: 1.0
In-Reply-To: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
Date: Wed, 13 May 2015 10:14:07 -0700
Message-ID: <CAPg+sBggj382me1ATDx4SS9KHVfvX5KH7ZhLHN6B+2_a+Emw1Q@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary=001a113cd2ac19c8b00515f9bdb7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Precedence: list

--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" <decker.christian@gmail.com>
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

<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">Unsure to what extent this has been presented on the mailing=
list, but the softfork idea is this:<br>
* Transactions get 2 txids, one used to reference them (computed as before)=
, and one used in an (extended) sighash.<br>
* The txins keep using the normal txid, so not structural changes to Bitcoi=
n.<br>
* 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.<br>
* 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.</p=
>
<p dir=3D"ltr">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.</p>
<div class=3D"gmail_quote">On May 13, 2015 5:50 AM, &quot;Christian Decker&=
quot; &lt;<a href=3D"mailto:decker.christian@gmail.com">decker.christian@gm=
ail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Hi All,</div><div><br></div>I&#39;d like to propos=
e a BIP to normalize transaction IDs in order to address transaction mallea=
bility and facilitate higher level protocols.<div><br></div><div>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.</div><div><br></div><div>The detailed writeup can be foun=
d here:=A0<a href=3D"https://github.com/cdecker/bips/blob/normalized-txid/b=
ip-00nn.mediawiki" target=3D"_blank">https://github.com/cdecker/bips/blob/n=
ormalized-txid/bip-00nn.mediawiki</a>.</div><div><br></div><div>@gmaxwell: =
I&#39;d like to request a BIP number, unless there is something really wron=
g with the proposal.</div><div><br></div><div>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.</div><div><br></d=
iv><div>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.</div><di=
v>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.</div><div><br></div><div>I&#39;m sure it&#39;=
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><=
div><br></div><div>Please let me know what you think, the proposal is defin=
itely not set in stone at this point and I&#39;m sure we can improve it fur=
ther.</div><div><br></div><div>Regards,</div><div>Christian</div></div>
<br>-----------------------------------------------------------------------=
-------<br>
One dashboard for servers and applications across Physical-Virtual-Cloud<br=
>
Widest out-of-the-box monitoring support with 50+ applications<br>
Performance metrics, stats and reports that give you Actionable Insights<br=
>
Deep dive visibility with transaction tracing using APM Insight.<br>
<a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" target=
=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a><br>=
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div>

--001a113cd2ac19c8b00515f9bdb7--