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
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
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 444A792
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 08:31:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6ACB6A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 08:31:53 +0000 (UTC)
Received: by wicll6 with SMTP id ll6so63005309wic.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Oct 2015 01:31:52 -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=feCJX4prG922ErLZPqgPiAYDpKX+xWgK9scA5SWSjpI=;
b=W43x2kXjFo85pSQii4BSik8p6/34J9tHONasJANLQlk20l7VbViZWPPkM3pe5bq95v
CmPiTbH0hu4t69KHwwsJjAKuwCj6f230xJcgfkZ7S6/OSEXqgwOMvKi2n4Mjrzyds6tA
mjPU7Z02YOOG4ZZH2tMFzZENx/bImz/yWyOySyzIEbXouVDsjPRsiNhf2eQDT/Roz2/j
zPkX2mbL2hnY5LTkC7/YUddbbB36JMMsFuF3WeUwUdARh6vKMuxx8lp9hedvHKomb18e
ckGBKAo/wwmPJ2OFgU0ebpb+bqbDCFpB5F3301xwxImIm2HNO72PptHcCYMgsWdBkOVs
gEgA==
X-Received: by 10.194.11.71 with SMTP id o7mr9205208wjb.75.1445416312087; Wed,
21 Oct 2015 01:31:52 -0700 (PDT)
MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
<201510210618.56159.luke@dashjr.org>
<CALxbBHVdXrdh6fdSyLdkPP_D4MSbofOr01kc9L9QuQTWZ33N1w@mail.gmail.com>
<201510210752.17527.luke@dashjr.org>
In-Reply-To: <201510210752.17527.luke@dashjr.org>
From: Christian Decker <decker.christian@gmail.com>
Date: Wed, 21 Oct 2015 08:31:42 +0000
Message-ID: <CALxbBHVnb-bLx47RcST0ZP2pg2YPzC5TvCDjL1qXqEQLN2qSGA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=047d7b4508ded5aca00522993528
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
Cc: 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: Wed, 21 Oct 2015 08:31:54 -0000
--047d7b4508ded5aca00522993528
Content-Type: text/plain; charset=UTF-8
On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr <luke@dashjr.org> wrote:
> On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote:
> > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <luke@dashjr.org> wrote:
> > > 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?
>
> Signer malleability is still a notable concern needing consideration.
> Ideally,
> wallets should be trying to actively CoinJoin, bump fees on, etc any
> pending
> transactions in the background. These forms of malleability affect nearly
> as
> many real use cases as third-party malleability.
>
> Luke
>
How is signer malleability still a problem if we remove the signatures from
the transaction ID of the transaction and all preceding transactions? The
signer can re-sign a transaction but it won't change the transaction ID.
It is still possible to double-spend transactions that do not have enough
fees, so just starting a new round of CoinJoin is sufficient to bump fees
for all parties that participate, and that would also result in the
double-spent low fee transaction to be discarded, resolving the state of
all coins in the first CoinJoin tx.
--047d7b4508ded5aca00522993528
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 9:52 AM Luke Dashjr <<a href=3D"mailto:luke@dashjr.org">luke@d=
ashjr.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wedne=
sday, October 21, 2015 7:39:45 AM Christian Decker wrote:<br>
> On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr <<a href=3D"mailto:luke=
@dashjr.org" target=3D"_blank">luke@dashjr.org</a>> wrote:<br>
> > This doesn't completely close malleability (which should be d=
ocumented in<br>
> > the BIP), so I'm not sure it's worth the cost, especially=
if closing<br>
> > malleability later on would need more. How about specifying flags=
upfront<br>
> > in the UTXO-creating transaction specifying which parts the signa=
ture<br>
> > will cover? This would allow implementation of fully malleability=
-proof<br>
> > wallets.<br>
><br>
> As far as I see it the only remaining venues for malleability are the =
use<br>
> of sighash flags that are not SIGHASH_ALL, as mentioned in the BIP. An=
y use<br>
> of non-sighash_all flags is already an explicit permission to modify t=
he<br>
> transactions, by adding and removing inputs and outputs, so I don'=
t see how<br>
> these can be made non-malleable. Am I missing something?<br>
<br>
Signer malleability is still a notable concern needing consideration. Ideal=
ly,<br>
wallets should be trying to actively CoinJoin, bump fees on, etc any pendin=
g<br>
transactions in the background. These forms of malleability affect nearly a=
s<br>
many real use cases as third-party malleability.<br>
<br>
Luke<br></blockquote><div><br></div><div>How is signer malleability still a=
problem if we remove the signatures from the transaction ID of the transac=
tion and all preceding transactions? The signer can re-sign a transaction b=
ut it won't change the transaction ID.</div><div><br></div><div>It is s=
till possible to double-spend transactions that do not have enough fees, so=
just starting a new round of CoinJoin is sufficient to bump fees for all p=
arties that participate, and that would also result in the double-spent low=
fee transaction to be discarded, resolving the state of all coins in the f=
irst CoinJoin tx.</div></div></div>
--047d7b4508ded5aca00522993528--
|
