MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201510210846.43988.luke@dashjr.org>
	<CAJN5wHXSbZPuXN7PQRyOgOMuk2Ogooiww3hW93uNipQJnfkeOg@mail.gmail.com>
	<201510212320.31052.luke@dashjr.org>
In-Reply-To: <201510212320.31052.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Thu, 22 Oct 2015 08:26:58 +0000
Message-ID: <CALxbBHUK_na0qKEBrkCzV2oAUc90wpL4z=7h6Zuu4XzaKEazrA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>, Danny Thorpe <danny.thorpe@gmail.com>
Content-Type: multipart/alternative; boundary=089e0141a3d6c4fd900522ad4294
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

--089e0141a3d6c4fd900522ad4294
Content-Type: text/plain; charset=UTF-8

I think the scenario of the single signer re-ordering the outputs and
inputs and then re-signing the transaction is in the same category of
simple double-spends. The signer could just as well sign a completely
different transaction spending the same coins to somewhere else, so I don't
think there is a lot we can do about it even if we instate a canonical
ordering. Even if we order the inputs and outputs the signer can just add a
new input and output and we would have a different transaction.

Normalized transaction IDs do help in the case that the single signer wants
to immediately follow up its transaction with another transaction spending
the first one's change output, and it prevents any modification in the
multi-signer scenario.

On Thu, Oct 22, 2015 at 1:21 AM Luke Dashjr <luke@dashjr.org> wrote:

> On Wednesday, October 21, 2015 6:22:25 PM Danny Thorpe wrote:
> > Let's keep canonical ordering separate from the normalized transaction ID
> > proposal. Baby steps. Normalized transaction IDs provide an immediate
> > benefit against the hazard of third party manipulation of transactions in
> > the mempool, even without canonical ordering.
>
> My point is that third-party manipulation is not much more of a problem
> than
> signing-party manipulation. Solving the former (at a high cost), without
> solving the latter, seems not worth it IMO.
>
> Luke
>

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

<div dir=3D"ltr">I think the scenario of the single signer re-ordering the =
outputs and inputs and then re-signing the transaction is in the same categ=
ory of simple double-spends. The signer could just as well sign a completel=
y different transaction spending the same coins to somewhere else, so I don=
&#39;t think there is a lot we can do about it even if we instate a canonic=
al ordering. Even if we order the inputs and outputs the signer can just ad=
d a new input and output and we would have a different transaction.<div><br=
></div><div>Normalized transaction IDs do help in the case that the single =
signer wants to immediately follow up its transaction with another transact=
ion spending the first one&#39;s change output, and it prevents any modific=
ation in the multi-signer scenario.</div></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr">On Thu, Oct 22, 2015 at 1:21 AM Luke Dashjr &lt;<a href=
=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">On Wednesday, October 21, 2015 6:22:25 PM Danny Tho=
rpe wrote:<br>
&gt; Let&#39;s keep canonical ordering separate from the normalized transac=
tion ID<br>
&gt; proposal. Baby steps. Normalized transaction IDs provide an immediate<=
br>
&gt; benefit against the hazard of third party manipulation of transactions=
 in<br>
&gt; the mempool, even without canonical ordering.<br>
<br>
My point is that third-party manipulation is not much more of a problem tha=
n<br>
signing-party manipulation. Solving the former (at a high cost), without<br=
>
solving the latter, seems not worth it IMO.<br>
<br>
Luke<br>
</blockquote></div>

--089e0141a3d6c4fd900522ad4294--