summaryrefslogtreecommitdiff
path: root/cd/e783b0e6645f182c73429f5b7fa30a13c73b27
blob: 644f9af60af86f0129b47558c8c73dd82e6ba4b1 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pieter.wuille@gmail.com>) id 1Yj2AM-0002gR-Vd
	for bitcoin-development@lists.sourceforge.net;
	Fri, 17 Apr 2015 09:02:26 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.43 as permitted sender)
	client-ip=209.85.215.43; envelope-from=pieter.wuille@gmail.com;
	helo=mail-la0-f43.google.com; 
Received: from mail-la0-f43.google.com ([209.85.215.43])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Yj2AL-0001MU-UA
	for bitcoin-development@lists.sourceforge.net;
	Fri, 17 Apr 2015 09:02:26 +0000
Received: by laat2 with SMTP id t2so75257103laa.1
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 17 Apr 2015 02:02:19 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.203.162 with SMTP id kr2mr1701770lac.68.1429261339591;
	Fri, 17 Apr 2015 02:02:19 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Fri, 17 Apr 2015 02:02:19 -0700 (PDT)
Received: by 10.112.19.7 with HTTP; Fri, 17 Apr 2015 02:02:19 -0700 (PDT)
In-Reply-To: <55304321.3030300@sky-ip.org>
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>
Date: Fri, 17 Apr 2015 02:02:19 -0700
Message-ID: <CAPg+sBi3QgJK7-PuV-1vbur0AMUeXddUdv_-Mcjwgbefqj3rFg@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=001a113463267007ea0513e7d6eb
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(pieter.wuille[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	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: 1Yj2AL-0001MU-UA
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, 17 Apr 2015 09:02:27 -0000

--001a113463267007ea0513e7d6eb
Content-Type: text/plain; charset=ISO-8859-1

> 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 can
> 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 transaction
> (tx1) and broadcast it, you can alter its txid at your will, without any
> 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 systems
> 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 course.

After BIP62, you will, as a sender, optionally be able to protect others
from malleating. You're always able to re-sign yourself.

-- 
Pieter

--001a113463267007ea0513e7d6eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">&gt; Anyone can alter the txid - more details needed. The nu=
mber of altered<br>
&gt; txids in practice is not so high in order to make us believe anyone ca=
n<br>
&gt; do it easily. It is obvious that all current bitcoin transactions are<=
br>
&gt; malleable, but not by anyone and not that easy. At least I like to thi=
nk so.</p>
<p dir=3D"ltr">Don&#39;t assume that because it does not (frequently) happe=
n, that it cannot happen. Large amounts of malleated transactions have happ=
ened in the past. Especially if you build a system depends on non-malleabil=
ity for its security, you may at some point have an attacker who has financ=
ial gain from malleation.<br></p>
<p dir=3D"ltr">&gt; &gt;From your answer I understand that right now if I c=
reate a transaction<br>
&gt; (tx1) and broadcast it, you can alter its txid at your will, without a=
ny<br>
&gt; mining power and/or access to my private keys so I would end up not<br=
>
&gt; recognizing my own transaction and probably my change too (if my syste=
ms<br>
&gt; rely hardly on txid)?</p>
<p dir=3D"ltr">In theory, yes, anyone can alter the txid without invalidati=
ng it, without mining power and without access to the sender&#39;s private =
keys.</p>
<p dir=3D"ltr">All it requires is seeing a transaction on the network, doin=
g a trivial modification to it, and rebroadcasting it quickly. If the modif=
ies version gets mined, you&#39;re out of luck. Having mining power helps o=
f course.</p>
<p dir=3D"ltr">After BIP62, you will, as a sender, optionally be able to pr=
otect others from malleating. You&#39;re always able to re-sign yourself.</=
p>
<p dir=3D"ltr">-- <br>
Pieter<br>
</p>

--001a113463267007ea0513e7d6eb--