path: root/08/5cd5a5e420a7340f4f4468b2c6c9b5d120b0e2

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 <pieter.wuille@gmail.com>) id 1YsbaC-0000s6-V2
	for bitcoin-development@lists.sourceforge.net;
	Wed, 13 May 2015 18:40:40 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.43 as permitted sender)
	client-ip=209.85.218.43; envelope-from=pieter.wuille@gmail.com;
	helo=mail-oi0-f43.google.com; 
Received: from mail-oi0-f43.google.com ([209.85.218.43])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YsbaB-0000TY-Nb
	for bitcoin-development@lists.sourceforge.net;
	Wed, 13 May 2015 18:40:40 +0000
Received: by oift201 with SMTP id t201so38460862oif.3
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 13 May 2015 11:40:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.187.138 with SMTP id l132mr209699oif.31.1431542434308;
	Wed, 13 May 2015 11:40:34 -0700 (PDT)
Received: by 10.60.94.36 with HTTP; Wed, 13 May 2015 11:40:34 -0700 (PDT)
In-Reply-To: <CALxbBHU-0huAs_y3cZCfmKKAAq3LHut8DwdSGm+1Rym3pb9j2A@mail.gmail.com>
References: <CALxbBHUnt7ToVK9reH6W6uT4HV=7NbxGHyNWWa-OEHg+Z1+qOg@mail.gmail.com>
	<CAPg+sBggj382me1ATDx4SS9KHVfvX5KH7ZhLHN6B+2_a+Emw1Q@mail.gmail.com>
	<CALxbBHU-0huAs_y3cZCfmKKAAq3LHut8DwdSGm+1Rym3pb9j2A@mail.gmail.com>
Date: Wed, 13 May 2015 11:40:34 -0700
Message-ID: <CAPg+sBjX=u4Osbzr+25w-5QzzhWGKryzW2K-0Xu3gS0eJXUUDw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Christian Decker <decker.christian@gmail.com>
Content-Type: multipart/alternative; boundary=001a113ccf4a4728c80515faf24b
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: 1YsbaB-0000TY-Nb
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 13 May 2015 18:40:41 -0000

--001a113ccf4a4728c80515faf24b
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 13, 2015 at 11:04 AM, Christian Decker <
decker.christian@gmail.com> wrote:

> If the inputs to my transaction have been long confirmed I can be
> reasonably safe in assuming that the transaction hash does not change
> anymore. It's true that I have to be careful not to build on top of
> transactions that use legacy references to transactions that are
> unconfirmed or have few confirmations, however that does not invalidate the
> utility of the normalized transaction IDs.
>

Sufficient confirmations help of course, but make systems like this less
useful for more complex interactions where you have multiple unconfirmed
transactions waiting on each other. I think being able to rely on this
problem being solved unconditionally is what makes the proposal attractive.
For the simple cases, see BIP62.

I remember reading about the SIGHASH proposal somewhere. It feels really
> hackish to me: It is a substantial change to the way signatures are
> verified, I cannot really see how this is a softfork if clients that did
> not update are unable to verify transactions using that SIGHASH Flag and it
> is adding more data (the normalized hash) to the script, which has to be
> stored as part of the transaction. It may be true that a node observing
> changes in the input transactions of a transaction using this flag could
> fix the problem, however it requires the node's intervention.
>

I think you misunderstand the idea. This is related, but orthogonal to the
ideas about extended the sighash flags that have been discussed here before.

All it's doing is adding a new CHECKSIG operator to script, which, in its
internally used signature hash, 1) removes the scriptSigs from transactions
before hashing 2) replaces the txids in txins by their ntxid. It does not
add any data to transactions, and it is a softfork, because it only impacts
scripts which actually use the new CHECKSIG operator. Wallets that don't
support signing with this new operator would not give out addresses that
use it.

>
> Compare that to the simple and clean solution in the proposal, which does
> not add extra data to be stored, keeps the OP_*SIG* semantics as they are
> and where once you sign a transaction it does not have to be monitored or
> changed in order to be valid.
>

OP_*SIG* semantics don't change here either, we're just adding a superior
opcode (which in most ways behaves the same as the existing operators). I
agree with the advantage of not needing to monitor transactions afterwards
for malleated inputs, but I think you underestimate the deployment costs.
If you want to upgrade the world (eventually, after the old index is
dropped, which is IMHO the only point where this proposal becomes superior
to the alternatives) to this, you're changing *every single piece of
Bitcoin software on the planet*. This is not just changing some validation
rules that are opt-in to use, you're fundamentally changing how
transactions refer to each other.

Also, what do blocks commit to? Do you keep using the old transaction ids
for this? Because if you don't, any relayer on the network can invalidate a
block (and have the receiver mark it as invalid) by changing the txids. You
need to somehow commit to the scriptSig data in blocks still so the POW of
a block is invalidated by changing a scriptSig.

There certainly are merits using the SIGHASH approach in the short term (it
> does not require a hard fork), however I think the normalized transaction
> ID is a cleaner and simpler long-term solution, even though it requires a
> hard-fork.
>

It requires a hard fork, but more importantly, it requires the whole world
to change their software (not just validation code) to effectively use it.
That, plus large up-front deployment costs (doubling the cache size for
every full node for the same propagation speed is not a small thing) which
may not end up being effective.

-- 
Pieter

--001a113ccf4a4728c80515faf24b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wed, May 13, 2015 at 11:04 AM, Christian Decker <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:decker.christian@gmail.com" target=3D"_bla=
nk">decker.christian@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">If the inputs to my transaction have been long confirmed I can be =
reasonably safe in assuming that the transaction hash does not change anymo=
re. It&#39;s true that I have to be careful not to build on top of transact=
ions that use legacy references to transactions that are unconfirmed or hav=
e few confirmations, however that does not invalidate the utility of the no=
rmalized transaction IDs.=A0</div></blockquote><div><br></div><div>Sufficie=
nt confirmations help of course, but make systems like this less useful for=
 more complex interactions where you have multiple unconfirmed transactions=
 waiting on each other. I think being able to rely on this problem being so=
lved unconditionally is what makes the proposal attractive. For the simple =
cases, see BIP62.<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div>I remember reading about the SIGHASH proposal somewhere. It feels =
really hackish to me: It is a substantial change to the way signatures are =
verified, I cannot really see how this is a softfork if clients that did no=
t update are unable to verify transactions using that SIGHASH Flag and it i=
s adding more data (the normalized hash) to the script, which has to be sto=
red as part of the transaction. It may be true that a node observing change=
s in the input transactions of a transaction using this flag could fix the =
problem, however it requires the node&#39;s intervention.</div></div></bloc=
kquote><div><br></div><div>I think you misunderstand the idea. This is rela=
ted, but orthogonal to the ideas about extended the sighash flags that have=
 been discussed here before.<br><br></div><div>All it&#39;s doing is adding=
 a new CHECKSIG operator to script, which, in its internally used signature=
 hash, 1) removes the scriptSigs from transactions before hashing 2) replac=
es the txids in txins by their ntxid. It does not add any data to transacti=
ons, and it is a softfork, because it only impacts scripts which actually u=
se the new CHECKSIG operator. Wallets that don&#39;t support signing with t=
his new operator would not give out addresses that use it.<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>Compare that t=
o the simple and clean solution in the proposal, which does not add extra d=
ata to be stored, keeps the OP_*SIG* semantics as they are and where once y=
ou sign a transaction it does not have to be monitored or changed in order =
to be valid.</div></div></blockquote><div><br></div><div>OP_*SIG* semantics=
 don&#39;t change here either, we&#39;re just adding a superior opcode (whi=
ch in most ways behaves the same as the existing operators). I agree with t=
he advantage of not needing to monitor transactions afterwards for malleate=
d inputs, but I think you underestimate the deployment costs. If you want t=
o upgrade the world (eventually, after the old index is dropped, which is I=
MHO the only point where this proposal becomes superior to the alternatives=
) to this, you&#39;re changing *every single piece of Bitcoin software on t=
he planet*. This is not just changing some validation rules that are opt-in=
 to use, you&#39;re fundamentally changing how transactions refer to each o=
ther.<br><br></div><div>Also, what do blocks commit to? Do you keep using t=
he old transaction ids for this? Because if you don&#39;t, any relayer on t=
he network can invalidate a block (and have the receiver mark it as invalid=
) by changing the txids. You need to somehow commit to the scriptSig data i=
n blocks still so the POW of a block is invalidated by changing a scriptSig=
.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>There c=
ertainly are merits using the SIGHASH approach in the short term (it does n=
ot require a hard fork), however I think the normalized transaction ID is a=
 cleaner and simpler long-term solution, even though it requires a hard-for=
k.<br></div></div></blockquote><div><br></div><div>It requires a hard fork,=
 but more importantly, it requires the whole world to change their software=
 (not just validation code) to effectively use it. That, plus large up-fron=
t deployment costs (doubling the cache size for every full node for the sam=
e propagation speed is not a small thing) which may not end up being effect=
ive.<br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>

--001a113ccf4a4728c80515faf24b--