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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <hozer@grid.coop>) id 1WCtUs-0001I7-OH
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Feb 2014 16:14:14 +0000
X-ACL-Warn:
Received: from nl.grid.coop ([50.7.166.116])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WCtUo-0008Bl-4Y for bitcoin-development@lists.sourceforge.net;
Mon, 10 Feb 2014 16:14:14 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
by nl.grid.coop with local; Mon, 10 Feb 2014 10:14:02 -0600
id 000000000006A32E.0000000052F8FACA.00007029
Date: Mon, 10 Feb 2014 10:14:02 -0600
From: Troy Benjegerdes <hozer@hozed.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20140210161402.GI3180@nl.grid.coop>
References: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <CAPg+sBi-phaw3hDgguk-LYrPsKX4M5snTJBv_NsQML1M=XgZEw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WCtUo-0008Bl-4Y
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Malleability and MtGox's announcement
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: Mon, 10 Feb 2014 16:14:14 -0000
Okay, why the everloving FUCK is there not someone on this list with a
@mtgox.com address talking about this?
I started using bitcoin because I could audit the code, and when the
developer cabal does stuff 'off-list' what you do is hand over market
manipulation power to the selected cabal of company insiders who are
discussing things 'off-list'.
The people having a 'private' discussion about how to solve this are
TAKING MONEY from everyone else, by having access to insider information.
I don't think any of the developers actually have a clue this is the
result, because a good chunk of them are employed by for-profit companies
funded by venture capital, and VC lawyers are very good at writing
employment contracts that provide plausible deniability of insider
trading.
The press MAKES MONEY (okay, takes money) by manipulating markets,
and venture capitalists pay lots of money to ensure the market is
manipulated in ways they can profit from.
Private market manipulation is one of the costs of anonymity and privacy,
and I don't really like paying for some off-list discussion of what appears
to be a serious scalability and usability problem.
Bitcoin is such a powerful tool because it broadcasts transactions to
the network for everyone to see.
Can we please broadcast some more technical details to this mailing list,
including exactly what MtGox is doing, and how they wish to resolve it?
If you gave me the entire code stack that MtGox runs on under an AGPLv3
license, I'm pretty sure I, along with everyone else here could come up
with a workable solution. I think a code release would be a huge win
for MtGox as well, and would cement their position as market leader in
transparent cryptocurrency trading.
Otherwise we are just a bunch of dinghys getting capsized one by one
in a sea of market-manipulating white whales. Isn't the closed door
market manipulation of the big banks one of the reasons we all started
using Bitcoin in the first place?
Why do revolutions always put the same old bullshit back in power?
What we need is some transparent code evolution.
On Mon, Feb 10, 2014 at 01:28:42PM +0100, Pieter Wuille wrote:
> Hi all,
>
> I was a bit surprised to see MtGox's announcement. The malleability of
> transactions was known for years already (see for example the wiki
> article on it, https://en.bitcoin.it/wiki/Transaction_Malleability it,
> or mails on this list from 2012 and 2013). I don't consider it a very
> big problem, but it does make it harder for infrastructure to interact
> with Bitcoin. If we'd design Bitcoin today, I'm sure we would try to
> avoid it altogether to make life easier for everyone.
>
> But we can't just change all infrastructure that exists today. We're
> slowly working towards making malleability harder (and hopefully
> impossible someday), but this will take a long time. For example, 0.8
> not supporting non-DER encoded signatures was a step in that direction
> (and ironically, the trigger that caused MtGox's initial problems
> here). In any case, this will take years, and nobody should wait for
> this.
>
> There seem to be two more direct problems here.
> * Wallets which deal badly with modified txids.
> * Services that use the transaction id to detect unconfirming transactions.
>
> The first is something that needs to be done correctly in software -
> it just needs to be aware of malleability.
>
> The second is something I was unaware of and would have advised
> against. If you plan on reissuing a transaction because on old version
> doesn't confirm, make sure to make it a double spend of the first one
> - so that not both can confirm.
>
> I certainly don't like press making this sound like a problem in the
> Bitcoin protocol or clients. I think this is an issue that needs to be
> solved at the layer above - the infrastructure building on the Bitcoin
> system. Despite that, I do think that we (as a community, not just
> developers) can benefit from defining a standard way to identify
> transactions unambiguously. This is something Mark Karpeles suggested
> a few days ago, and my proposal is this:
>
> We define the normalized transaction id as SHA256^2(normalized_tx +
> 0x01000000), where normalized_tx is the transaction with all input
> scripts replaced by empty scripts. This is exactly what would be
> signed inside transaction signatures using SIGHASH_ALL (except not
> substituting the previous scriptPubKey to be signed, and not dealing
> with the input being signed specially). An implementation is here:
> https://github.com/sipa/bitcoin/commits/normtxid.
>
> Note that this is not a solution for all problems related to
> malleability, but maybe it can make people more aware of it, in
> tangible way.
>
> --
> Pieter
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
