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
|
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 <mh.in.england@gmail.com>) id 1Wd3KD-0001sc-14
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 19:59:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd3KC-0003PD-0t
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 19:59:20 +0000
Received: by mail-ob0-f179.google.com with SMTP id vb8so1581169obc.24
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 12:59:14 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.55.65 with SMTP id q1mr3060626obp.70.1398283154582; Wed,
23 Apr 2014 12:59:14 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 12:59:14 -0700 (PDT)
In-Reply-To: <CAAS2fgTJpFQKeVTQsAeqe0UK-2XhrLZG4oocEHM11_spWLtrEA@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>
Date: Wed, 23 Apr 2014 21:59:14 +0200
X-Google-Sender-Auth: 7XPWFSaq8KnNuFWsza1fmVb00Yo
Message-ID: <CANEZrP0fUhiFeH4A1Y9sLCORpggJs3dxHz+exgpKaLQe9rgFeA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=089e01538848b973bb04f7bb2aeb
X-Spam-Score: -0.5 (/)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1Wd3KC-0003PD-0t
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:59:21 -0000
--089e01538848b973bb04f7bb2aeb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>
> 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 and
theirs were inconsistent.
The only slight way BitUndo differs is, they provide it as a service, and I
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.
Otherwise the purchase clears. But they could certainly add a
pre-notification before they broadcast to get back to the exact scheme
originally described, they have everything else in place.
> Oscar himself can be implemented as a majority M parties to further
> increase confidence
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 matter
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.
> 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.
>
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?
Trying to solve the problem of dishonest miners is effectively trying to
solve the "automatically find trusted third parties" problem at scale.
--089e01538848b973bb04f7bb2aeb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">What you're talking about is=
just disagreement about the content of<br>
</div>
the memory pool<br></blockquote><div><br></div><div>That's the same thi=
ng. 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 and theirs w=
ere inconsistent.</div>
<div><br></div><div>The only slight way BitUndo differs is, they provide it=
as a service, and I don't know if they inform you when they found a bl=
ock (probably not), so you have to do the purchase and then hope BitUndo fi=
nds the next block. Otherwise the purchase clears. But they could certainly=
add a pre-notification before they broadcast to get back to the exact sche=
me originally described, they have everything else in place.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">Oscar himself can be implemented as a majority M parties to=
further<br></div>
increase confidence</blockquote><div><br></div><div>This just brings us bac=
k 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?</div><div><br></div><div>
Let's say I succeed in finding some parties who are incorruptible no ma=
tter 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 no=
t?</div>
<div><br></div><div>The point of the broadcast network and mining is so the=
re 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.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">value retail transactions=
=E2=80=94 the fact that any cheating by oscar is<br>
cryptographically provable (just show them the double signatures)<br>
maybe be strong enough alone.<br></blockquote><div><br></div><div>But as yo=
u point out, cheating my GHash.io did not result in any obvious negative co=
nsequence to them, despite that preventing double spending is their sole ta=
sk. Why would Oscar be different to GHash.io?</div>
<div><br></div><div>Trying to solve the problem of dishonest miners is effe=
ctively trying to solve the "automatically find trusted third parties&=
quot; problem at scale.</div></div></div></div>
--089e01538848b973bb04f7bb2aeb--
|
