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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1Wd39B-00016m-7W
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 19:47:57 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.172 as permitted sender)
client-ip=209.85.217.172; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f172.google.com;
Received: from mail-lb0-f172.google.com ([209.85.217.172])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd397-0001DR-DH
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 19:47:57 +0000
Received: by mail-lb0-f172.google.com with SMTP id c11so1203710lbj.17
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 12:47:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.201.1 with SMTP id jw1mr2712974lbc.47.1398282466653;
Wed, 23 Apr 2014 12:47:46 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Wed, 23 Apr 2014 12:47:46 -0700 (PDT)
In-Reply-To: <CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
Date: Wed, 23 Apr 2014 12:47:46 -0700
Message-ID: <CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@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: 1Wd397-0001DR-DH
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 19:47:57 -0000
On Wed, Apr 23, 2014 at 12:19 PM, Mike Hearn <mike@plan99.net> wrote:
> That's the definition of a Finney attack, right?
A finney attack is where you attempt to mine a block with a
transaction paying you, and as soon as you are successful you quickly
make a transaction spending that coin to someone else, then release
the block after they've taken an irreversible action. If everything is
automated it should have something like a 99% success rate, though it
has a cost of some small increase in the number of orphan blocks you
experience.
> I mean, I hope that's the definition of a Finney attack, given that I coi=
ned
> the term :)
You might have coined the term, but I don't think the attack you're
describing is the attack Hal described:
https://bitcointalk.org/index.php?topic=3D3441.msg48384#msg48384
What you're talking about is just disagreement about the content of
the memory pool, but we have no consensus mechanism there (the
blockchain _is_ the consensus mechanism). Mempools are sometimes
inconsistent all on their own, without any attacker being involved.
> These sorts of proposals are all just ways of saying block chains kind of
> suck and we should go back to using trusted third parties.
I think thats an unsophisticated view.
Consider this protocol.
I take some of my funds and assign them to a 2 of 2 multisig with
myself and Oscar. I do not announce this transaction until I get Oscar
to sign a timelocked anyonecanpay refund to send the coin back to me
(say in 3 months). Oscar gives me my refund and I announce the
transaction.
Later I can make instant payments with oscar signing up until the
refund time comes clue to anyone who trusts Oscar to never double
spend. For the receiver this is purely additive with regular
blockchain security: in that even with Oscar's help I cannot double
spend except where I would have been successful absent Oscar. On the
sender side, Oscar cannot up and steal my funds and he can't try to
extort me (except by creating a delay up to the refund time).
Oscar himself can be implemented as a majority M parties to further
increase confidence, though if you're talking about using this for low
value retail transactions=E2=80=94 the fact that any cheating by oscar is
cryptographically provable (just show them the double signatures)
maybe be strong enough alone. (Though there is a multitude of other
proposals to provide more evidence of Oscar's honesty). There are also
ways to blind Oscar so he can't reliably identify which transactions
are ones he signed for.
I don't think this is at all a "return to trusted third parties"=E2=80=94 t=
hat
it's a shrug and an admission of defeat. Its a very narrowly scoped
trust, filling in precisely where large scale decentralized consensus
is fundamentally weak... the result is something which combines
advantages from both classes and is stronger than either trust or
blockchains alone. (I'm also not trying to say that an implementation
of this is _simple_ by any means, working out all the details is
hard.)
By contrast, I think proposals which overly depend on colluding miners
to behave in very specific ways are themselves just a way of saying
block chains suck unless we turn the miners themselves into a trusted
third party. I'm much more in favor of adding a little bit of
mastercard to transactions where mastercard is really what people
want, than turning mining=E2=80=94 and thus bitcoin itself=E2=80=94 into ma=
stercard,
especially since miners=E2=80=94 self selecting as they are=E2=80=94 are a =
pretty poor
set of parties to act as trusted agents. :)
>> Doubly so because a 'nasty' party with non-trivial hash-power can
>> doublespend their own transactions
> If a miner is vertically integrated and defrauding merchants themselves,
> with no service component, pretty quickly people would talk to each other=
,
> notice this pattern and stop trading with them, making their coins rather
> useless. Also if their real identity is ever revealed they could be liabl=
e
> and there'd be a lot of people wanting to sue them.
We have an existence proof that it isn't so=E2=80=94 you can say that it
wasn't consistent enough, but what is? There wasn't any major doubt
that they were actually doing it. They're the largest identifiable
pool as we speak.
I think, instead, that strong zero-conf security isn't a part of what
many people think of when they think of Bitcoin's characteristics.
Zero conf is risky, and I think for a lot of people thats okay. If it
isn't there are ways to improve it that don't involve asking miners to
participate in a majority vote to take away funds from people.
|
