path: root/b2/2392d69ff0b55e9af51c6e65067c1299ba6ce1

Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 6251A407
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  3 Nov 2015 21:44:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1BD4E140
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  3 Nov 2015 21:44:14 +0000 (UTC)
Received: by wmec75 with SMTP id c75so97990469wme.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 03 Nov 2015 13:44:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to
	:cc:content-type;
	bh=Bfr9ljjVaykKZdpn3Ra0GRhT3Ru651iWWhG1yE5omP0=;
	b=V8WcNiKs22xpw8Bm6hi2PGuRRoCZo2HHvbYNPLhbo7uM0Z8b1S+mwpW9Yx9Tv9YYHQ
	Kpb29wHjywEyfGzGuUqLaWPHIvl1zC8t8i6yyavuK6lgFFvMuxHo3lCvdu34Zs8fGkth
	hiD9p3R4mDbIqQjaVye581znK1BVN4RdoXTW85wE3B3eUigNgnA+P7tIYxcuFe2l4WuX
	sA4H4ITEoyYAFAhDBIdxgUA061AjYHyIqBxt18a/9dBrZ16Xp4g4Yd43pTpKIr5sorvd
	KA1oB3FV1QQgczacOBuZPdcC9a9+5OLrnYk+n3s5IgM6vUtoge5WKXL94ivk8HrHEvcz
	GcsA==
X-Received: by 10.28.23.211 with SMTP id 202mr21017232wmx.81.1446587052615;
	Tue, 03 Nov 2015 13:44:12 -0800 (PST)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510220905.27124.luke@dashjr.org>
	<CALxbBHV4JU7TG8QutkX7m9V4n_ANgKAgWO8ZA2KxQk8jP=kF0g@mail.gmail.com>
	<201511032048.18680.luke@dashjr.org>
In-Reply-To: <201511032048.18680.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Tue, 03 Nov 2015 21:44:02 +0000
Message-ID: <CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1147181a686ca70523a9cbec
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 21:44:15 -0000

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

On Tue, Nov 3, 2015 at 9:49 PM Luke Dashjr <luke@dashjr.org> wrote:

> On Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:
> > I am still very much intrigued by Luke's idea of having empty scriptsigs
> > and ship the signatures in external scripts, however the proposal uses
> the
> > on-the-fly normalization because we have no good way of relaying the
> > external scripts. Since we are still in the drafting phase I am open to
> > suggestions and if there is a good/working solution I can amend/withdraw
> > the proposal.
>
> Changing the network protocol is trivial in comparison to making a
> permanent
> increase in UTXO set costs.
>

Ok, so assuming we can get a connected component of upgraded nodes that
relay both the transaction and the associated external scripts then we
could just piggyback the external scripts on top of the normal messages.
Non-upgraded nodes will read the entire two-part message but only parse the
classical transaction, dropping the external script. Validation rules for
upgraded nodes are the same as before: if the attached signatures are
invalid the entire TX is dropped. We have to commit to the external scripts
used during the creation of a block. I think the easiest way to add this
commitment is the coinbase input I guess, and following the transaction
list a new list of signature lists is shipped with the rest of the block.
Non-upgraded will ignore it as before.

Would that work? It all hinges on having upgraded miners in a connected
component otherwise non-upgraded nodes will drop the external scripts on
the way (since they parse and then reconstruct the messages along the
path). But if it works this could be a much nicer solution.


>
> > As for open venues for malleability, I'm not sure we can fix them at all,
> > after all the ability of a single signer to doublespend by
> > appending/replacing inputs/outputs in an arbitrary fashion is not fixable
> > IMHO and will cause any future transaction building on its outputs to be
> > orphaned. What would the perfect properties for such a fix be?
>
> The problem isn't changing inputs/outputs, but that such changes invalidate
> later spends. In particular, note that wallets *should ideally* be actively
> trying to make transfers using multiple malleated versions of the same
> payment.
>

So this is indeed a form of desired malleability we will likely not be able
to fix. I'd argue that this goes more into the direction of double-spending
than a form of malleability, and is mostly out of scope for this BIP. As
the abstract mentions this BIP attempts to eliminate damage incurred by
malleability in the third party modification scenario and in the multisig
scenario, with the added benefit of enabling transaction templating. If we
can get the segregated witnesses approach working all the better, we don't
even have the penalty of increased UTXO size. The problem of singlesig
users doublespending their outputs to update transactions remains a problem
even then.


>
> So the way to make an anti-malleable wallet, would be to strictly enforce
> the
> no-address-reuse rule on payments received (note this has no effect on
> other/current wallets) and rely only on the hash of that scriptPubKey+value
> for the input in subsequent transactions. This way, no matter what inputs
> or
> other outputs the transaction paying the address/invoice uses, the
> subsequent
> transaction ignores them and remains valid. (I am not suggesting this as a
> mandatory change that all wallets must adopt to receive the current semi-
> malleability protection you propose - only that it be *possible* for
> wallets
> to upgrade to or offer in the future.)
>

Sounds very interesting. That would then be a new signature checking opcode
I guess that would allow the transaction hash in the input be replaced by
the hash of the serialized output it is spending? That way the transaction
would not be detached from the coins unless the amount or the scriptpubkey
(containing the address) is modified. So a user may add new outputs and
inputs to an existing transaction like you mentioned. This does not help
someone receiving funds from a sender to build new transactions on top
since the sender may simply doublespend its output before it is confirmed.
I think this is probably best addressed in a separate proposal.


>
> Luke
>

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue=
, Nov 3, 2015 at 9:49 PM Luke Dashjr &lt;<a href=3D"mailto:luke@dashjr.org"=
>luke@dashjr.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 =
Tuesday, November 03, 2015 8:37:44 PM Christian Decker wrote:<br>
&gt; I am still very much intrigued by Luke&#39;s idea of having empty scri=
ptsigs<br>
&gt; and ship the signatures in external scripts, however the proposal uses=
 the<br>
&gt; on-the-fly normalization because we have no good way of relaying the<b=
r>
&gt; external scripts. Since we are still in the drafting phase I am open t=
o<br>
&gt; suggestions and if there is a good/working solution I can amend/withdr=
aw<br>
&gt; the proposal.<br>
<br>
Changing the network protocol is trivial in comparison to making a permanen=
t<br>
increase in UTXO set costs.<br></blockquote><div><br></div><div>Ok, so assu=
ming we can get a connected component of upgraded nodes that relay both the=
 transaction and the associated external scripts then we could just piggyba=
ck the external scripts on top of the normal messages. Non-upgraded nodes w=
ill read the entire two-part message but only parse the classical transacti=
on, dropping the external script. Validation rules for upgraded nodes are t=
he same as before: if the attached signatures are invalid the entire TX is =
dropped. We have to commit to the external scripts used during the creation=
 of a block. I think the easiest way to add this commitment is the coinbase=
 input I guess, and following the transaction list a new list of signature =
lists is shipped with the rest of the block. Non-upgraded will ignore it as=
 before.</div><div><br></div><div>Would that work? It all hinges on having =
upgraded miners in a connected component otherwise non-upgraded nodes will =
drop the external scripts on the way (since they parse and then reconstruct=
 the messages along the path). But if it works this could be a much nicer s=
olution.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt; As for open venues for malleability, I&#39;m not sure we can fix them =
at all,<br>
&gt; after all the ability of a single signer to doublespend by<br>
&gt; appending/replacing inputs/outputs in an arbitrary fashion is not fixa=
ble<br>
&gt; IMHO and will cause any future transaction building on its outputs to =
be<br>
&gt; orphaned. What would the perfect properties for such a fix be?<br>
<br>
The problem isn&#39;t changing inputs/outputs, but that such changes invali=
date<br>
later spends. In particular, note that wallets *should ideally* be actively=
<br>
trying to make transfers using multiple malleated versions of the same<br>
payment.<br></blockquote><div><br></div><div>So this is indeed a form of de=
sired malleability we will likely not be able to fix. I&#39;d argue that th=
is goes more into the direction of double-spending than a form of malleabil=
ity, and is mostly out of scope for this BIP. As the abstract mentions this=
 BIP attempts to eliminate damage incurred by malleability in the third par=
ty modification scenario and in the multisig scenario, with the added benef=
it of enabling transaction templating. If we can get the segregated witness=
es approach working all the better, we don&#39;t even have the penalty of i=
ncreased UTXO size. The problem of singlesig users doublespending their out=
puts to update transactions remains a problem even then.</div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<br>
So the way to make an anti-malleable wallet, would be to strictly enforce t=
he<br>
no-address-reuse rule on payments received (note this has no effect on<br>
other/current wallets) and rely only on the hash of that scriptPubKey+value=
<br>
for the input in subsequent transactions. This way, no matter what inputs o=
r<br>
other outputs the transaction paying the address/invoice uses, the subseque=
nt<br>
transaction ignores them and remains valid. (I am not suggesting this as a<=
br>
mandatory change that all wallets must adopt to receive the current semi-<b=
r>
malleability protection you propose - only that it be *possible* for wallet=
s<br>
to upgrade to or offer in the future.)<br></blockquote><div><br></div><div>=
Sounds very interesting. That would then be a new signature checking opcode=
 I guess that would allow the transaction hash in the input be replaced by =
the hash of the serialized output it is spending? That way the transaction =
would not be detached from the coins unless the amount or the scriptpubkey =
(containing the address) is modified. So a user may add new outputs and inp=
uts to an existing transaction like you mentioned. This does not help someo=
ne receiving funds from a sender to build new transactions on top since the=
 sender may simply doublespend its output before it is confirmed. I think t=
his is probably best addressed in a separate proposal.</div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>
Luke<br>
</blockquote></div></div>

--001a1147181a686ca70523a9cbec--