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
157
158
159
160
161
162
163
164
165
166
167
168
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jeremy@taplink.co>) id 1WGCcP-0005pO-FE
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 19:15:41 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-4.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1WGCcO-0003AJ-AO for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 19:15:41 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co
; Wed, 19 Feb 2014 11:15:45 -0800
Content-Type: multipart/alternative; boundary=----------F30ly8iv54fevWQyOqsWmx
To: "Alan Reiner" <etotheipi@gmail.com>, "Allen Piscitello"
<allen.piscitello@gmail.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
<20140210030048.GB31925@savin>
<CAH2=CKzNGN7mpe1NLtsLRNSszSD2ZNwjoAsaH40EvGtA5ezDeQ@mail.gmail.com>
<CALf2ePyDTZ_43uBfS9-5znhTyBR-5H10SpZ=N-z1DBacM_rDgA@mail.gmail.com>
<CAJfRnm5pVA+gd3t=bXO188S4uwtUvx5F8V_bO_YV+74Ev4Q9jg@mail.gmail.com>
Date: Wed, 19 Feb 2014 11:15:39 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xbjmgdcfyldrnw@laptop-air>
In-Reply-To: <CAJfRnm5pVA+gd3t=bXO188S4uwtUvx5F8V_bO_YV+74Ev4Q9jg@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
X-Spam-Score: -1.2 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WGCcO-0003AJ-AO
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
malleability
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 19 Feb 2014 19:15:41 -0000
------------F30ly8iv54fevWQyOqsWmx
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
> Longer term it would be more ideal have a canonical identifier for the
> transaction before it even gets to the chain to support these use cases,
> even if >wallets are able to properly identify the status of it's
> transactions.
> -Allen
>
>
One possible work-around to get back trusted transaction chaining for
payment channels and locked refunds from multi-sig would be to make the
initial transaction include zero fee, and depend on child-pays-for-parent
in order to get the first and follow-on transactions into a block. This of
course only works for protocols where the parties don't need the initial
funding transaction to actually hit the blockchain right away.
But this relies on two assumptions; 1) that miners won't include a
zero-fee transaction in the blockchain, and 2) that miners actually
implement child-pays-for-parent. It's definitely not the same security
as-if you had immutable txid, but it's something to consider.
1) Mutants may cause wallet spam and difficulty calculating balance (and
wallets will evolve to deal with it)
2) Mutants cause DoS because they can interfere with your own transaction
chains, which for example makes batch off-line processing much more
difficult
3) Mutants introduce a 3rd party attacker into any two-party protocol that
relies on chains
There's a lot to digest in the 'v3' transaction/block proposal. It sounds
like there may be some uncertainty over whether we can *prove* that v3
transactions in v3 blocks would actually be guaranteed immutable with
these changes?
If we cannot fully prove a Tx is immutable, then is it actually worth
taking steps to make it seem immutable, or is that just a false sense of
security in the cases where chained transactions were actually expected to
be reliable? Under that thinking, maybe it's best to accept mutants as a
fact of life, and only consider protocols and techniques that cannot be
broken by mutants.
In what cases does reducing the sources of malleability, but not
necessarily eliminating from a security proof perspective, actually help?
Basically, if we don't know that we will succeed, isn't there really no
point in trying?
------------F30ly8iv54fevWQyOqsWmx
Content-Type: multipart/related; boundary=----------F30ly8iv54fevWYBgCGUP7
------------F30ly8iv54fevWYBgCGUP7
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1392837339210.57e1ce665d6b4ecc@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body><div>
<div><br></div><blockquote style=3D"margin: 0 0 0.80ex; border-left: #00=
00FF 2px solid; padding-left: 1ex"><div dir=3D"ltr"><div>Longer term it =
would be more ideal have a canonical identifier for the transaction befo=
re it even gets to the chain to support these use cases, even if wallets=
are able to properly identify the status of it's transactions. </=
div>
<div><br></div><div>-Allen</div></div><div class=3D"gmail_extra"><br><br=
></div></blockquote></div><div>
<div>One possible work-around to get back trusted transaction chaining f=
or payment channels and locked refunds from multi-sig would be to make t=
he initial transaction include zero fee, and depend on child-pays-for-pa=
rent in order to get the first and follow-on transactions into a block. =
This of course only works for protocols where the parties don't need the=
initial funding transaction to actually hit the blockchain right away.<=
/div><div><br></div><div>But this relies on two assumptions; 1) that min=
ers won't include a zero-fee transaction in the blockchain, and 2) that =
miners actually implement child-pays-for-parent. It's definitely not the=
same security as-if you had immutable txid, but it's something to consi=
der.</div></div><div><br></div><div>
<div>1) Mutants may cause wallet spam and difficulty calculating balance=
(and wallets will evolve to deal with it)</div><div>2) Mutants cause Do=
S because they can interfere with your own transaction chains, which for=
example makes batch off-line processing much more difficult</div><div>3=
) Mutants introduce a 3rd party attacker into any two-party protocol tha=
t relies on chains</div></div><div><br></div><div>There's a lot to diges=
t in the 'v3' transaction/block proposal. It sounds like there may be so=
me uncertainty over whether we can *prove* that v3 transactions in v3 bl=
ocks would actually be guaranteed immutable with these changes?</div><di=
v><br></div><div>If we cannot fully prove a Tx is immutable, then is it =
actually worth taking steps to make it seem immutable, or is that just a=
false sense of security in the cases where chained transactions were ac=
tually expected to be reliable? Under that thinking, maybe it's best to =
accept mutants as a fact of life, and only consider protocols and techni=
ques that cannot be broken by mutants.</div><div><br></div><div>In what =
cases does reducing the sources of malleability, but not necessarily eli=
minating from a security proof perspective, actually help? Basically, if=
we don't know that we will succeed, isn't there really no point in tryi=
ng?</div></body></html>
------------F30ly8iv54fevWYBgCGUP7--
------------F30ly8iv54fevWQyOqsWmx--
|
