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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <s7r@sky-ip.org>) id 1Yit3a-000352-Ak
for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 23:18:50 +0000
Received: from outbound.mailhostbox.com ([162.222.225.18])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Yit2z-00072w-H8 for bitcoin-development@lists.sourceforge.net;
Thu, 16 Apr 2015 23:18:50 +0000
Received: from [0.0.0.0] (tor-exit3-readme.dfri.se [171.25.193.235])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: s7r@sky-ip.org)
by outbound.mailhostbox.com (Postfix) with ESMTPSA id D1B43780BDB;
Thu, 16 Apr 2015 23:17:55 +0000 (GMT)
Message-ID: <55304321.3030300@sky-ip.org>
Date: Fri, 17 Apr 2015 02:17:53 +0300
From: s7r <s7r@sky-ip.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64;
rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Mark Friedenbach <mark@friedenbach.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>
In-Reply-To: <CAOG=w-vMjysbF5H8wWN2y45U3djFwpKMtXq3vCvB=-eFr7GqFg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
X-CTCH-RefID: str=0001.0A020202.55304326.0045, ss=1, re=0.000, recu=0.000,
reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: s7r@sky-ip.org
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
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.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [162.222.225.18 listed in list.dnswl.org]
0.0 TIME_LIMIT_EXCEEDED Exceeded time limit / deadline
X-Headers-End: 1Yit2z-00072w-H8
Cc: 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
Reply-To: s7r@sky-ip.org
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 23:18:50 -0000
On 4/16/2015 8:34 PM, Mark Friedenbach wrote:
> At this moment anyone can alter the txid. Assume transactions are 100%
> malleable.
>=20
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.
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)?
> On Apr 16, 2015 9:13 AM, "s7r" <s7r@sky-ip.org <mailto:s7r@sky-ip.org>>
> wrote:
>=20
> Hi Pieter,
>=20
> Thanks for your reply. I agree. Allen has a good point in the previ=
ous
> email too, so the suggestion might not fix anything and complicate
> things.
>=20
> The problem I am trying to solve is making all transactions
> non-malleable by default. I guess there is a very good reason why B=
IP62
> will not touch v1 anyway.
>=20
> I am trying to build a bitcoin contract which will relay on 3 thing=
s:
> - coinjoin / txes with inputs from multiple users which are signed =
by
> all users after they are merged together (every user is sure his co=
ins
> 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 sign=
ed
> before the inputs being spent are broadcasted/confirmed, using the =
txid
> provided by the user before broadcasting it. Malleability hurts her=
e.
> - P2SH
>=20
> In simple terms, how malleable transactions really are in the netwo=
rk 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 l=
ittle
> bit unclear to me.
>=20
> Another thing I would like to confirm, the 3 pieces of the bitcoin
> protocol mentioned above will be supported in _any_ future transact=
ion
> version or block version, regardless what changes are made or featu=
res
> added to bitcoin core? The contract needs to be built and left unch=
anged
> for a very very long period of time...
>=20
>=20
> 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> <mailto:s7r@sky-ip.org <mailto:s7r@sky-ip.o=
rg>>>
> > 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 t=
his
> > subjects him to extra rules in the creation.
> >
> > Forcing v3 transactions would require every piece of wallet
> software to
> > be changed.
> >
> > --
> > Pieter
> >
>=20
> -------------------------------------------------------------------=
-----------
> 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=3DSourceforge_BPM_Camp_5_6_15&utm_medium=3Demail&utm_campaig=
n=3DVA_SF
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20
|
