MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510210618.56159.luke@dashjr.org>
In-Reply-To: <201510210618.56159.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Oct 2015 07:39:45 +0000
Message-ID: <CALxbBHVdXrdh6fdSyLdkPP_D4MSbofOr01kc9L9QuQTWZ33N1w@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c3877e0eaf7b0522987c03
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

--001a11c3877e0eaf7b0522987c03
Content-Type: text/plain; charset=UTF-8

On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke@dashjr.org> wrote:

> On Monday, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev
> wrote:
> > The proposal is implemented (see below), by computing the normalized
> > transaction ID when adding them to the UTXO and storing them along with
> the
> > coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and
> > OP_CHECKMULTISIG, but I'm hoping somebody can give me some pointers into
> > how to best refactor the common functionality into reusable blocks. And
> the
> > annotating incoming transactions with their normalized inputs is a bit
> > cumbersome, maye somebody has some pointers here as well?


> This doesn't completely close malleability (which should be documented in
> the
> BIP), so I'm not sure it's worth the cost, especially if closing
> malleability
> later on would need more. How about specifying flags upfront in the UTXO-
> creating transaction specifying which parts the signature will cover? This
> would allow implementation of fully malleability-proof wallets.
>

As far as I see it the only remaining venues for malleability are the use
of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. Any use
of non-sighash_all flags is already an explicit permission to modify the
transactions, by adding and removing inputs and outputs, so I don't see how
these can be made non-malleable. Am I missing something?


>
> Additionally, you have a flag to control whether the opcode behaves as
> VERIFY
> or not. Non-VERIFY is not possible as a softfork (without doing a
> second/new
> P2SH) since it can be negated.
>

Yes, this is my mistake and has been pointed out in the PR, I will amend
the PR to make the verify flag mandatory, which also guarantees that the
top of the stack contains a non-null element, thus resulting in a
successful evaluation on non-updated clients.


>
> Luke
>

--001a11c3877e0eaf7b0522987c03
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Wed, Oct 21=
, 2015 at 8:19 AM Luke Dashjr &lt;<a href=3D"mailto:luke@dashjr.org">luke@d=
ashjr.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monda=
y, October 19, 2015 2:01:04 PM Christian Decker via bitcoin-dev wrote:<br>
&gt; The proposal is implemented (see below), by computing the normalized<b=
r>
&gt; transaction ID when adding them to the UTXO and storing them along wit=
h the<br>
&gt; coin state. OP_CHECKSIGEX mostly duplicates OP_CHECKSIG and<br>
&gt; OP_CHECKMULTISIG, but I&#39;m hoping somebody can give me some pointer=
s into<br>
&gt; how to best refactor the common functionality into reusable blocks. An=
d the<br>
&gt; annotating incoming transactions with their normalized inputs is a bit=
<br>
&gt; cumbersome, maye somebody has some pointers here as well?</blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
This doesn&#39;t completely close malleability (which should be documented =
in the<br>
BIP), so I&#39;m not sure it&#39;s worth the cost, especially if closing ma=
lleability<br>
later on would need more. How about specifying flags upfront in the UTXO-<b=
r>
creating transaction specifying which parts the signature will cover? This<=
br>
would allow implementation of fully malleability-proof wallets.<br></blockq=
uote><div><br></div><div>As far as I see it the only remaining venues for m=
alleability are the use of sighash flags that are not SIGHASH_ALL, as menti=
oned in the BIP. Any use of non-sighash_all flags is already an explicit pe=
rmission to modify the transactions, by adding and removing inputs and outp=
uts, so I don&#39;t see how these can be made non-malleable. Am I missing s=
omething?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally, you have a flag to control whether the opcode behaves as VERI=
FY<br>
or not. Non-VERIFY is not possible as a softfork (without doing a second/ne=
w<br>
P2SH) since it can be negated.<br></blockquote><div><br></div><div>Yes, thi=
s is my mistake and has been pointed out in the PR, I will amend the PR to =
make the verify flag mandatory, which also guarantees that the top of the s=
tack contains a non-null element, thus resulting in a successful evaluation=
 on non-updated clients.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<br>
Luke<br>
</blockquote></div></div>

--001a11c3877e0eaf7b0522987c03--