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
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jtimon@jtimon.cc>) id 1YlZRJ-0006pK-24
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Apr 2015 08:58:25 +0000
Received: from mail-wi0-f175.google.com ([209.85.212.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YlZRC-0006NG-7O
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Apr 2015 08:58:25 +0000
Received: by wiax7 with SMTP id x7so30172422wia.0
for <bitcoin-development@lists.sourceforge.net>;
Fri, 24 Apr 2015 01:58:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=5WjJKVujI2sErrjH2lB4OvXeW0thZ0+CiwVShnpotSA=;
b=hUCni+tNR02FLstV9gfN1cGO7G4he+Pvtta7h4T0bapE+7ih9Tyc/hyfI+BtNkL3C8
IigseWOoT1S8O+oT06/v5z0FKSxFyko5I3w2yrZl4xtnnVfPXWeZ6YkAh2S0lEYkK5Ir
TQTcPsAo5xdWQFXM9GtJFyeBhiv7vuxpIpVRpqHinEr69RMvB6ze+rjRoIGgmtaoJRyg
NH8hfij9CH/ZH1wIyw5YDxQmFTLbmcGM6Wg8Fgq6LsHbPFvxsiMAvN4JwZKazcxyAkYb
xXswQv01VdqM3qqPNZKr1sPy/T2hXrTr81+4SDzjI+Ol6ttd7eI1aObScGyv5Z364AN+
GKXw==
X-Gm-Message-State: ALoCoQkObqeZWHmX7unYVUwsCPjdEfiNxswN7HdojT6ls0qGQoeeQujO2W13W0zVdPUqItGCSqua
MIME-Version: 1.0
X-Received: by 10.180.105.193 with SMTP id go1mr1834089wib.92.1429865892005;
Fri, 24 Apr 2015 01:58:12 -0700 (PDT)
Received: by 10.194.124.2 with HTTP; Fri, 24 Apr 2015 01:58:11 -0700 (PDT)
In-Reply-To: <CABm2gDoBci9qjGt-FpgzuYvpDrG8iqfzBTnUqFTyYWP5SpLxLA@mail.gmail.com>
References: <552EF785.7000207@sky-ip.org>
<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
<552FDF73.6010104@sky-ip.org>
<CAOG=w-vMjysbF5H8wWN2y45U3djFwpKMtXq3vCvB=-eFr7GqFg@mail.gmail.com>
<55304321.3030300@sky-ip.org>
<CAPg+sBi3QgJK7-PuV-1vbur0AMUeXddUdv_-Mcjwgbefqj3rFg@mail.gmail.com>
<55326F11.1010605@sky-ip.org>
<CABm2gDoBci9qjGt-FpgzuYvpDrG8iqfzBTnUqFTyYWP5SpLxLA@mail.gmail.com>
Date: Fri, 24 Apr 2015 10:58:11 +0200
Message-ID: <CABm2gDr9t5G6DsyT8ZT_4UbqjhBXkA5cJRZhtZTv+Djz7mpSMg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: s7r@sky-ip.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1YlZRC-0006NG-7O
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
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: Fri, 24 Apr 2015 08:58:25 -0000
Oh, no, sorry, it also covers bip62.
On Fri, Apr 24, 2015 at 10:55 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote=
:
> s7r you may be interested in this video explaining several aspects of
> malleability: https://www.youtube.com/watch?v=3DjyDE-aFqJTs
> It is pre BIP62, but I believe it is very relevant and will hopefully
> clear some of your doubts.
> The signer of TX1 will always be able to change the signature and thus
> the tx ID.
>
> On Sat, Apr 18, 2015 at 4:49 PM, s7r <s7r@sky-ip.org> wrote:
>> Understood. That is unfortunate, but not the end of the world. If you
>> could please give feedback also to these last comments / questions:
>>
>> How far are we at this moment from BIP62? Can an user send a
>> non-malleable tx now, if enforces some additional rules?
>>
>> As for the security of the system, it does not fully rely on txids being
>> non malleable, but see this quote from my previous email:
>>
>> [QUOTE]
>> I am trying to build a bitcoin contract which will relay on 3 things:
>> - coinjoin / txes with inputs from multiple users which are signed by
>> all users after they are merged together (every user is sure his coins
>> will not be spent without the other users to spend anything, as per
>> agreed contract);
>> - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
>> before the inputs being spent are broadcasted/confirmed, using the txid
>> provided by the user before broadcasting it. Malleability hurts here.
>> - P2SH
>>
>> Another thing I would like to confirm, the 3 pieces of the bitcoin
>> protocol mentioned above will be supported in _any_ future transaction
>> version or block version, regardless what changes are made or features
>> added to bitcoin core? The contract needs to be built and left unchanged
>> for a very very long period of time...
>> [/END QUOTE]
>>
>> Can you comment on the quote please?
>>
>> So, basically transaction malleability could affect the system in the
>> way that a pre-signed tx which offers the insurance and which is sent to
>> the user before the user sends the coins (spending user's coins back to
>> him after a certain period of time) could be invalidated. The insurance
>> tx signature will still be good, but invalid overall since the input
>> (txid) being spent does not exist (was altered / modified). The coins
>> won't be stolen or lost, but a new tx needs to be signed with the
>> altered (new) txid, for the system to work.
>>
>> So, an user creates a transaction TX1 sending the coins to the server
>> but does not broadcast it. Instead, he provides the txid of TX1 to the
>> server. Server generates another transaction TX2 which spends TX1 back
>> to the user, with an nLockTime. User checks and if everything ok
>> broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2
>> will become invalid (since it will be spending an inexistent input), and
>> the server will need to re-create and sign TX2 with the new
>> (altered/modified) txid of TX1, as per agreed contract. Should the
>> server disappear after user broadcasts TX1 and before the
>> altered/modified txid of TX1 gets confirmed, user's coins are forever
>> locked. It is true that no third party can benefit from this type of
>> attack, only the user will result with coins locked, but it is something
>> which could be used by competition to make a service useless / annoying
>> / too complicated or less safe to use.
>>
>> How could I mitigate this?
>>
>> Thanks you for your time and help.
>>
>> On 4/17/2015 12:02 PM, Pieter Wuille wrote:
>>>> Anyone can alter the txid - more details needed. The number of altered
>>>> txids in practice is not so high in order to make us believe anyone ca=
n
>>>> do it easily. It is obvious that all current bitcoin transactions are
>>>> malleable, but not by anyone and not that easy. At least I like to
>>> think so.
>>>
>>> Don't assume that because it does not (frequently) happen, that it
>>> cannot happen. Large amounts of malleated transactions have happened in
>>> the past. Especially if you build a system depends on non-malleability
>>> for its security, you may at some point have an attacker who has
>>> financial gain from malleation.
>>>
>>>> >From your answer I understand that right now if I create a transactio=
n
>>>> (tx1) and broadcast it, you can alter its txid at your will, without a=
ny
>>>> mining power and/or access to my private keys so I would end up not
>>>> recognizing my own transaction and probably my change too (if my syste=
ms
>>>> rely hardly on txid)?
>>>
>>> In theory, yes, anyone can alter the txid without invalidating it,
>>> without mining power and without access to the sender's private keys.
>>>
>>> All it requires is seeing a transaction on the network, doing a trivial
>>> modification to it, and rebroadcasting it quickly. If the modifies
>>> version gets mined, you're out of luck. Having mining power helps of co=
urse.
>>>
>>> After BIP62, you will, as a sender, optionally be able to protect other=
s
>>> from malleating. You're always able to re-sign yourself.
>>>
>>> --
>>> Pieter
>>>
>>
>> ------------------------------------------------------------------------=
------
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exerc=
ises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?u=
tm_
>> source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaign=3DV=
A_SF
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
