summaryrefslogtreecommitdiff
path: root/38/8850a3dfbfb23b02fca6c14dd48c9bfc58d805
blob: 696cd29f595ec76258cfce98f0ba4579c0ec4e0e (plain)
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
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <aritter@gmail.com>) id 1Wd420-0004i4-Fh
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 20:44:36 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.128.181 as permitted sender)
	client-ip=209.85.128.181; envelope-from=aritter@gmail.com;
	helo=mail-ve0-f181.google.com; 
Received: from mail-ve0-f181.google.com ([209.85.128.181])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wd41z-0000jD-DL
	for bitcoin-development@lists.sourceforge.net;
	Wed, 23 Apr 2014 20:44:36 +0000
Received: by mail-ve0-f181.google.com with SMTP id oy12so1774873veb.40
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 23 Apr 2014 13:44:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.104.33 with SMTP id gb1mr1067754vdb.45.1398285869877;
	Wed, 23 Apr 2014 13:44:29 -0700 (PDT)
Received: by 10.220.140.208 with HTTP; Wed, 23 Apr 2014 13:44:29 -0700 (PDT)
In-Reply-To: <CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@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>
	<CANEZrP2t09bzmDkkWK3V2GpqEt54KhFnUQ8_u9ULMqniMaOA8Q@mail.gmail.com>
Date: Wed, 23 Apr 2014 22:44:29 +0200
Message-ID: <CAKuKjyV+FQs1goNK1uWXVg7ky4aGiROcTZ5idM3Ug2-+5bTc2w@mail.gmail.com>
From: Adam Ritter <aritter@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1136b5e491918e04f7bbcc8d
X-Spam-Score: -0.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
	(aritter[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-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: 1Wd41z-0000jD-DL
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:44:36 -0000

--001a1136b5e491918e04f7bbcc8d
Content-Type: text/plain; charset=UTF-8

Isn't a faster blockchain for transactions (maybe as a sidechain) solving
the problem? If there would be a safe way for 0-confirmation transactions,
the Bitcoin blockchain wouldn't even be needed.


On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn <mike@plan99.net> wrote:

> 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.
>
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--001a1136b5e491918e04f7bbcc8d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Isn&#39;t a faster blockchain for transactions (maybe as a=
 sidechain) solving the problem? If there would be a safe way for 0-confirm=
ation transactions, the Bitcoin blockchain wouldn&#39;t even be needed.</di=
v>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 2=
3, 2014 at 10:37 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mik=
e@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
 class=3D"">On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell <span dir=3D"=
ltr">&lt;<a href=3D"mailto:gmaxwell@gmail.com" target=3D"_blank">gmaxwell@g=
mail.com</a>&gt;</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>Right, this works in the Bitcoin networ=
k 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></di=
v><div>Yes, but that can be fixed with double spend alerts.</div><div class=
=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>Someone you ask to not double spend is an entirely separate matter.<br=
></div>
They aren&#39;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><div>No? It&#39;s not just=
 your decision that matters, the receiver also has to trust them. They&#39;=
re like a dispute mediator in this regard. You can pick whoever you want, b=
ut that doesn&#39;t matter if the receiver doesn&#39;t recognise them or tr=
ust them. 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&#39;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&#39;=
t matter if your double spending partners refuse to help you spend your mon=
ey (because they&#39;re being coerced). The censorship can just happen at a=
 different place.</div>
<div class=3D"">
<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></=
div><div>..... or, have a majority decide to zero out their coinbase reward=
s for blocks that double spent against dice sites. That wouldn&#39;t undo t=
he double spend, but you can&#39;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 &quot;unpaying&quot; them for the service they did not p=
rovide.</div>

<div><br></div></div></div></div>
<br>-----------------------------------------------------------------------=
-------<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>_______________________________________________<b=
r>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a1136b5e491918e04f7bbcc8d--