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
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@friedenbach.org>) id 1YioAf-0008Rj-6A
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 18:05:49 +0000
X-ACL-Warn:
Received: from mail-ie0-f175.google.com ([209.85.223.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YioAW-0008BP-E8
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 18:05:49 +0000
Received: by iebrs15 with SMTP id rs15so57751512ieb.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 16 Apr 2015 11:05:35 -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;
bh=EVS/pVGNJrIYfy8xFDJ/LQLMn15E8BFHDgveYLXVG7g=;
b=Ok8U9PJgrLYoKAbQ1+zuoJPWBUz3ArsbGn1xAk7PNn14lMyvJkOnrQ2EHfQxh7kjAb
yyk651ELvYhGGLQMOTegowvUFY1XyganUKTS1M4GMa6j8d8lyi7ILA5OARbo28BWJ+5n
t5zdyFXxCssOM2hz8D7LauXXQspV06QyJ290pdO7bzOa1VmLkcb0V5VznHXbfBtBkMcG
bjjAa7ZNtphyz3hGm2Y9QLyJEzhZxfdxHI+1SM00D7V1+mthyM/ZRPVlW47Adx+g5L64
FSo4+fMoBzqt6TPYp9LWsHhk779Bt2DPxBFbIlYoL0fYUU79DE2hbIdaC50sKxpeD7k5
qQBw==
X-Gm-Message-State: ALoCoQmSfB3DFLUm/ciYMtUoJ+wXkY+DvimYDdh81W0gk0jwt+oJaBqRuRxdQPx1HqzThDPPBwyk
MIME-Version: 1.0
X-Received: by 10.107.135.144 with SMTP id r16mr45472600ioi.13.1429205671809;
Thu, 16 Apr 2015 10:34:31 -0700 (PDT)
Received: by 10.107.25.203 with HTTP; Thu, 16 Apr 2015 10:34:31 -0700 (PDT)
X-Originating-IP: [208.54.4.178]
Received: by 10.107.25.203 with HTTP; Thu, 16 Apr 2015 10:34:31 -0700 (PDT)
In-Reply-To: <552FDF73.6010104@sky-ip.org>
References: <552EF785.7000207@sky-ip.org>
<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
<552FDF73.6010104@sky-ip.org>
Date: Thu, 16 Apr 2015 10:34:31 -0700
Message-ID: <CAOG=w-vMjysbF5H8wWN2y45U3djFwpKMtXq3vCvB=-eFr7GqFg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: s7r@sky-ip.org
Content-Type: multipart/alternative; boundary=001a113ec81a612e250513dae03f
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1YioAW-0008BP-E8
Cc: Bitcoin Development <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: Thu, 16 Apr 2015 18:05:49 -0000
--001a113ec81a612e250513dae03f
Content-Type: text/plain; charset=UTF-8
At this moment anyone can alter the txid. Assume transactions are 100%
malleable.
On Apr 16, 2015 9:13 AM, "s7r" <s7r@sky-ip.org> wrote:
> Hi Pieter,
>
> Thanks for your reply. I agree. Allen has a good point in the previous
> email too, so the suggestion might not fix anything and complicate things.
>
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why BIP62
> will not touch v1 anyway.
>
> 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
>
> In simple terms, how malleable transactions really are in the network at
> this moment? Who can alter a txid without invalidating the tx? Just the
> parties who sign it? The miners? Anyone in the network? This is a little
> bit unclear to me.
>
> 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...
>
>
> On 4/16/2015 8:22 AM, Pieter Wuille wrote:
> >
> > On Apr 16, 2015 1:46 AM, "s7r" <s7r@sky-ip.org <mailto:s7r@sky-ip.org>>
> > wrote:
> >> but for transaction versions? In simple terms, if > 75% from all the
> >> transactions in the latest 1000 blocks are version 'n', mark all
> >> previous transaction versions as non-standard and if > 95% from all the
> >> transactions in the latest 1000 blocks are version 'n' mark all previous
> >> transaction versions as invalid.
> >
> > What problem are you trying to solve?
> >
> > The reason why BIP62 (as specified, it is just a draft) does not make v1
> > transactions invalid is because it is opt-in. The creator of a
> > transaction needs to agree to protect it from malleability, and this
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet software to
> > be changed.
> >
> > --
> > 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
> exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
> event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a113ec81a612e250513dae03f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">At this moment anyone can alter the txid. Assume transaction=
s are 100% malleable.</p>
<div class=3D"gmail_quote">On Apr 16, 2015 9:13 AM, "s7r" <<a =
href=3D"mailto:s7r@sky-ip.org">s7r@sky-ip.org</a>> wrote:<br type=3D"att=
ribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">Hi Pieter,<br>
<br>
Thanks for your reply. I agree. Allen has a good point in the previous<br>
email too, so the suggestion might not fix anything and complicate things.<=
br>
<br>
The problem I am trying to solve is making all transactions<br>
non-malleable by default. I guess there is a very good reason why BIP62<br>
will not touch v1 anyway.<br>
<br>
I am trying to build a bitcoin contract which will relay on 3 things:<br>
- coinjoin / txes with inputs from multiple users which are signed by<br>
all users after they are merged together (every user is sure his coins<br>
will not be spent without the other users to spend anything, as per<br>
agreed contract);<br>
- pre-signed txes with nLockTime 'n' weeks. These txes will be sign=
ed<br>
before the inputs being spent are broadcasted/confirmed, using the txid<br>
provided by the user before broadcasting it. Malleability hurts here.<br>
- P2SH<br>
<br>
In simple terms, how malleable transactions really are in the network at<br=
>
this moment? Who can alter a txid without invalidating the tx? Just the<br>
parties who sign it? The miners? Anyone in the network? This is a little<br=
>
bit unclear to me.<br>
<br>
Another thing I would like to confirm, the 3 pieces of the bitcoin<br>
protocol mentioned above will be supported in _any_ future transaction<br>
version or block version, regardless what changes are made or features<br>
added to bitcoin core? The contract needs to be built and left unchanged<br=
>
for a very very long period of time...<br>
<br>
<br>
On 4/16/2015 8:22 AM, Pieter Wuille wrote:<br>
><br>
> On Apr 16, 2015 1:46 AM, "s7r" <<a href=3D"mailto:s7r@sky=
-ip.org">s7r@sky-ip.org</a> <mailto:<a href=3D"mailto:s7r@sky-ip.org">s7=
r@sky-ip.org</a>>><br>
> wrote:<br>
>> but for transaction versions? In simple terms, if > 75% from al=
l the<br>
>> transactions in the latest 1000 blocks are version 'n', ma=
rk all<br>
>> previous transaction versions as non-standard and if > 95% from=
all the<br>
>> transactions in the latest 1000 blocks are version 'n' mar=
k all previous<br>
>> transaction versions as invalid.<br>
><br>
> What problem are you trying to solve?<br>
><br>
> The reason why BIP62 (as specified, it is just a draft) does not make =
v1<br>
> transactions invalid is because it is opt-in. The creator of a<br>
> transaction needs to agree to protect it from malleability, and this<b=
r>
> subjects him to extra rules in the creation.<br>
><br>
> Forcing v3 transactions would require every piece of wallet software t=
o<br>
> be changed.<br>
><br>
> --<br>
> Pieter<br>
><br>
<br>
---------------------------------------------------------------------------=
---<br>
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT<br>
Develop your own process in accordance with the BPMN 2 standard<br>
Learn Process modeling best practices with Bonita BPM through live exercise=
s<br>
<a href=3D"http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-=
" target=3D"_blank">http://www.bonitasoft.com/be-part-of-it/events/bpm-camp=
-virtual-</a> event?utm_<br>
source=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaig=
n=3DVA_SF<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div>
--001a113ec81a612e250513dae03f--
|
