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
|
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 <gmaxwell@gmail.com>) id 1Wd3iL-0003Y3-54
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 20:24:17 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.178 as permitted sender)
client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f178.google.com;
Received: from mail-lb0-f178.google.com ([209.85.217.178])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd3iK-0004VN-5X
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 20:24:17 +0000
Received: by mail-lb0-f178.google.com with SMTP id s7so1229384lbd.37
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 13:24:09 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.7.8 with SMTP id f8mr3201055laa.39.1398284649575; Wed,
23 Apr 2014 13:24:09 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 13:24:09 -0700 (PDT)
In-Reply-To: <CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
<CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@mail.gmail.com>
<CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
Date: Wed, 23 Apr 2014 13:24:09 -0700
Message-ID: <CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1Wd3iK-0004VN-5X
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Coinbase reallocation to discourage
Finney attacks
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: Wed, 23 Apr 2014 20:24:17 -0000
On Wed, Apr 23, 2014 at 12:59 PM, Mike Hearn <mike@plan99.net> wrote:
>> What you're talking about is just disagreement about the content of
>> the memory pool
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> the block you broadcast it to override everyone elses mempool. So yours a=
nd
> theirs were inconsistent.
The difference is when you transact. In the attack Hal described you
transact with your victim only after finding a block but before
announcing it.
> don't know if they inform you when they found a block (probably not), so =
you
> have to do the purchase and then hope BitUndo finds the next block.
Right, this works in the Bitcoin network today absent any collusion by
the miners. You give one miner a transaction and you give every other
node you can reach another transaction. You then hope your selected
miner finds the next block and 'undoes' the transaction you gave the
rest of the network.
> This just brings us back to square one. Who are these parties and what if=
I
> pay them to be corrupt? What if they offer to be corrupt as a service?
>
> Let's say I succeed in finding some parties who are incorruptible no matt=
er
> how large of a percentage I offer them. At this point, why bother with
> miners at all? Why pay for double spend protection twice, once to a group=
of
> Oscar's who are trustworthy and once to a group of miners who are not?
>
> The point of the broadcast network and mining is so there can be lots of
> Oscar's and I don't have to know who they are or sign up with them or put
> any effort into evaluating their reputation.
But it isn't at all the same thing. Miners select themselves based on
controlling hash-power. You can distrust a miner all you like but all
your distrust does not prevent him from participating in the
consensus, potentially to your detriment. Moreover, the set of miners
has to be the same for everyone or otherwise the network doesn't
converge. There are miners I _know_ to be scoundrels, but there is
nothing I can do about it.
Someone you ask to not double spend is an entirely separate matter.
They aren't self-selecting: you select who you trust to not make
double spends and there is no need for this trust to be globally
consistent. If they behave in an untrustworthy way you can instantly
stop honoring them because the bad action is provable beyond any doubt
and never trust them again (unlike mempool consistency)... and you can
do this even if everyone else is too foolish to do so for some reason.
The trustworthness of oscars needs only be limited and is different in
kind from the kind of 'trust' we need over the history=E2=80=94 they
arbitrating over the ordering of some subset of transactions right at
the tip of the chain, and only those transaction of people who have
specifically chosen to use them, of lower value transactions where you
need instant settlement. Why pay twice? Because you're actually
getting a different part of your security from each, and the result is
additive.
There is no such thing as an uncorruptable party, invoking that is a
useless strawman. Instead we can consider how difficult the corruption
is and what can happen if they're corrupted and hope to balance the
risks and the controls for those risks. Any self-selectingness as
anonymity (in the not-previously-enumerated sense) of mining is
important for censorship security but it's terrible for other things
like getting reliable mempool behavior.
> But as you point out, cheating my GHash.io did not result in any obvious
> negative consequence to them, despite that preventing double spending is
> their sole task. Why would Oscar be different to GHash.io?
Because you can choose to stop trusting an oscar while you=E2=80=94
individually=E2=80=94 can't choose anything about ghash.io. To stop GHash.=
io
we would have to take away their hardware or change the Bitcoin
protocol to make their hardware useless, and in the latter case we'd
_all_ have to agree to do this not just some (perhaps quite large)
subset of us who doesn't want to trust them, and even though it is
quite apparent what they did there is still some room to claim doubt.
> Trying to solve the problem of dishonest miners is effectively trying to
> solve the "automatically find trusted third parties" problem at scale.
Mining is universal=E2=80=94 everyone must use the same miners, trust seldo=
m
is seldom universal and shouldn't be. The trust we have in mining is
exceptionally limited, I think any effort to increase it is doomed to
fail=E2=80=94 both because trust heavy systems stink, because mining is a b=
ad
fit for trust, and because increasing the requirements create other
exposures and vulnerabilities.
|
