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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Wd3v4-0008Dh-TZ
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 20:37:26 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.53 as permitted sender)
client-ip=209.85.219.53; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f53.google.com;
Received: from mail-oa0-f53.google.com ([209.85.219.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Wd3v3-0002wH-VL
for bitcoin-development@lists.sourceforge.net;
Wed, 23 Apr 2014 20:37:26 +0000
Received: by mail-oa0-f53.google.com with SMTP id j17so1615780oag.40
for <bitcoin-development@lists.sourceforge.net>;
Wed, 23 Apr 2014 13:37:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr2366237oeb.81.1398285440691;
Wed, 23 Apr 2014 13:37:20 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Wed, 23 Apr 2014 13:37:20 -0700 (PDT)
In-Reply-To: <CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@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>
<CAAS2fgR1dRFVqhTNn55dZ6FS5zDM0aHs4ROPSD37hWwzLUKfCg@mail.gmail.com>
Date: Wed, 23 Apr 2014 22:37:20 +0200
X-Google-Sender-Auth: eFBmy1ncFLtufT-q9MwAzMbCPCM
Message-ID: <CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b41cd28fcb77104f7bbb251
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: 1Wd3v3-0002wH-VL
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:37:27 -0000
--047d7b41cd28fcb77104f7bbb251
Content-Type: text/plain; charset=UTF-8
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <gmaxwell@gmail.com>wrote:
> 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.
>
Yes, but that can be fixed with double spend alerts.
> 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.
>
No? It's not just your decision that matters, the receiver also has to
trust them. They're like a dispute mediator in this regard. You can pick
whoever you want, but that doesn't matter if the receiver doesn't recognise
them or trust them. You have to find an overlap to make an instant trade.
In practice if people have to think about this, evaluate brands etc then
you'd get a very small number of parties because the value of global
agreement is so high. Then it becomes hard to remove ones that have a lot
of momentum.
The censorship resistance of the block chain doesn't matter if your double
spending partners refuse to help you spend your money (because they're
being coerced). The censorship can just happen at a different place.
> To stop GHash.io we would have to take away their hardware or change the
> Bitcoin
> protocol to make their hardware useless
>
..... or, have a majority decide to zero out their coinbase rewards for
blocks that double spent against dice sites. That wouldn't undo the double
spend, but you can't do that with the multisig scheme either. All you can
do is punish the corrupted party post-hoc, either by not using them again,
or by "unpaying" them for the service they did not provide.
--047d7b41cd28fcb77104f7bbb251
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">On W=
ed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <span dir=3D"ltr"><<a href=
=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@gmail.com</a>>=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">Right, this works in the Bit=
coin network today absent any collusion by<br></div>
the miners. You give one miner a transaction and you give every other<br>
node you can reach another transaction.<br></blockquote><div><br></div><div=
>Yes, but that can be fixed with double spend alerts.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D"">Someone you ask to not double spend is an entirely separate=
matter.<br></div>
They aren't self-selecting: you select who you trust to not make<br>
double spends and there is no need for this trust to be globally<br>
consistent.<br></blockquote><div><br></div><div>No? It's not just your =
decision that matters, the receiver also has to trust them. They're lik=
e a dispute mediator in this regard. You can pick whoever you want, but tha=
t doesn't matter if the receiver doesn't recognise them or trust th=
em. You have to find an overlap to make an instant trade.</div>
<div><br></div><div>In practice if people have to think about this, evaluat=
e brands etc then you'd get a very small number of parties because the =
value of global agreement is so high. Then it becomes hard to remove ones t=
hat have a lot of momentum.</div>
<div><br></div><div>The censorship resistance of the block chain doesn'=
t matter if your double spending partners refuse to help you spend your mon=
ey (because they're being coerced). The censorship can just happen at a=
different 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">To stop GHash.io=C2=A0we wo=
uld have to take away their hardware or change the Bitcoin<br>
protocol to make their hardware useless<br></blockquote><div>=C2=A0</div><d=
iv>..... or, have a majority decide to zero out their coinbase rewards for =
blocks that double spent against dice sites. That wouldn't undo the dou=
ble spend, but you can't do that with the multisig scheme either. All y=
ou can do is punish the corrupted party post-hoc, either by not using them =
again, or by "unpaying" them for the service they did not provide=
.</div>
<div><br></div></div></div></div>
--047d7b41cd28fcb77104f7bbb251--
|
