1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
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 E05EE258
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 08:27:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com
[209.85.212.179])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 11D0C79
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 08:27:10 +0000 (UTC)
Received: by wicfx6 with SMTP id fx6so124582272wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 22 Oct 2015 01:27:08 -0700 (PDT)
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=f5nqT754LPjNna2mxjEQP5sIGqg9aQJB9Xg+m95TU+k=;
b=wYkvOeC1hmJpGr2IUhRwV9LofFQYNMWIgEKfCVsfGHvDBwkd197WNk9aKM0pfuA0CV
6D/GHAYfjnOWIzIiv9BQbYIk7B+bol2E1CqmRKBH5kGOK1b6Vqa2+jOKTQaljP0VmNDD
aBPqPflxsFxFJTmMmVSGoMaB6eL33vjpIo2UKGIQ38Vtl/NqXKxsaIpIxHJM+uuo7meD
BROStozkaXQBnTYZxy9plzhuWOLbw8CV9/3YP51dFY+1IvrH+/EJkxJMOajJSnI9UGn1
La3IpdDGV0oXIqEtv62EN7ldAiirIiZE4P5jWqBeTfBhIpE2RVj0XTTqao3CeFCwfftT
SXCg==
X-Received: by 10.194.239.230 with SMTP id vv6mr15918593wjc.21.1445502428444;
Thu, 22 Oct 2015 01:27:08 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 22 Oct 2015 08:43:51 +0000
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: Thu, 22 Oct 2015 08:27:11 -0000
--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=
'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'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 <<a href=
=3D"mailto:luke@dashjr.org">luke@dashjr.org</a>> 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>
> Let's keep canonical ordering separate from the normalized transac=
tion ID<br>
> proposal. Baby steps. Normalized transaction IDs provide an immediate<=
br>
> benefit against the hazard of third party manipulation of transactions=
in<br>
> 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--
|
