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
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1WdEYS-00036O-Iq
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 07:58:48 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.50 as permitted sender)
client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f50.google.com;
Received: from mail-oa0-f50.google.com ([209.85.219.50])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdEYR-0003je-GG
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 07:58:48 +0000
Received: by mail-oa0-f50.google.com with SMTP id i11so2231995oag.23
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 00:58:42 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.28.195 with SMTP id d3mr240907obh.19.1398326322138; Thu,
24 Apr 2014 00:58:42 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Thu, 24 Apr 2014 00:58:42 -0700 (PDT)
In-Reply-To: <CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
References: <CANEZrP0szimdFSk23aMfO8p2Xtgfbm6kZ=x3rmdPDFUD73xHMg@mail.gmail.com>
<CAAS2fgTS65b0mfJakEA5s3xJHuWU2BDW8MbEVgMFMNz8YAmEiA@mail.gmail.com>
<CANEZrP15DDdfT+o5jVKMO=tGTvHYx53yzhXfaVyzq7imfwJsZQ@mail.gmail.com>
<CAE28kUSLXG0y350gMiwnv0CoOHUorMgLup9TG77Mjj+BJcuowA@mail.gmail.com>
Date: Thu, 24 Apr 2014 09:58:42 +0200
X-Google-Sender-Auth: 7YD1iPWWiGDXurPtKuc6Afq0BBA
Message-ID: <CANEZrP0j0KoLUB+SE+W3fL8vTKay0niqoeQ38RKnU9cyGgvvYw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2cd18b6323a04f7c537d2
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: 1WdEYR-0003je-GG
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: Thu, 24 Apr 2014 07:58:48 -0000
--001a11c2cd18b6323a04f7c537d2
Content-Type: text/plain; charset=UTF-8
On Thu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi <alex.mizrahi@gmail.com>wrote:
>
> Different approaches have different trade-offs, and thus different areas
> of applicability.
>
> Proof-of-work's inherent disadvantage is that it takes some time until
> transaction becomes practically irreversible. On the other hand, it has
> advantages like neutrality, censorship-resistance, high degree of security,
> etc.
>
Sure, they have different tradeoffs. My assertion is this: the costs and
disadvantages that come with building what is in effect an entirely
parallel and separate system for stopping double spends, are much much
worse than making simple tweaks to strengthen the mechanism we already have.
Put another way, the cost/benefit ratio of this proposal seems much better
to me than the alternatives.
> In this case you get benefits of both approaches.
>
You also get the costs of both approaches, which are extremely significant.
Censorship-resistance is irrelevant when one buys a cup of coffee with his
> pocket money, isn't it?
That's like saying banks can't censor you because you can always withdraw
all your money in cash. But in practice:
1. That's a huge pain in the ass so nobody does it
2. Many merchants will refuse non-trivial payments in cash and demand
bank money because it's simpler for them
Analogously, having to wait some large expiry period to extract your money
from the "double spending prevention service" (a.k.a. bitbank) is a pain in
the ass, and many merchants would refuse to take your newly double
spendable money even if theoretically they could, because it keeps their
operations much simpler if they can just assume a sale is final and can't
be reversed.
So I think such a scheme would rapidly return to the a world that looks
much like the one we have now.
> For some reason, instead of considering these hybrid solutions (which can
> also address scalability problems), you want to make PoW-based system more
> complex to be applicable for real-time transaction too.
>
The complexity overhead is trivial - we already used coinbase scriptSigs
for voting on P2SH, I'm sure it'll be used for voting on other things in
future too. So that's already in place. Counting up votes and editing the
UTXO set is the sort of patch one guy can create, it's not very big. And
it's conceptually just the same as what miners can do today by re-orging
out blocks, but with much less impact on end users and less implementation
complexity (no giant reorgs that might themselves have to split recursively
whilst they're being built).
On the other hand, building an entirely separate system, with separate
trusted companies that have trusted brand names, adding support to all the
wallets, getting all sellers on board, making everything use an extended
BIP 70 (as that's the only real way to implement it), trying to explain to
users why they're now expected to pay extra fees when they previously
didn't and then discovering that you got a choice of only a handful of
double-spend-preventers everyone could agree on with little potential for
more .... that's hugely complex and messy.
> This will, likely, weaken advantages provided by PoW
>
Why? Remember deleting coinbases with nothing more than a simple majority
is already possible in the existing protocol and always has been.
--001a11c2cd18b6323a04f7c537d2
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 T=
hu, Apr 24, 2014 at 12:06 AM, Alex Mizrahi <span dir=3D"ltr"><<a href=3D=
"mailto:alex.mizrahi@gmail.com" target=3D"_blank">alex.mizrahi@gmail.com</a=
>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>Different approaches have different trade-offs, and thus different areas o=
f applicability.<br>
</div><div><br></div><div>Proof-of-work's inherent disadvantage is that=
it takes some time until transaction becomes practically irreversible. On =
the other hand, it has advantages like neutrality, censorship-resistance, h=
igh degree of security, etc.</div>
</div></div></div></blockquote><div><br></div><div>Sure, they have differen=
t tradeoffs. My assertion is this: =C2=A0the costs and disadvantages that c=
ome with building what is in effect an entirely parallel and separate syste=
m for stopping double spends, are much much worse than making simple tweaks=
to strengthen the mechanism we already have.</div>
<div><br></div><div>Put another way, the cost/benefit ratio of this proposa=
l seems much better to me than the alternatives.</div><div>=C2=A0<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div>In this case you get benefits of both approaches.<br></div></div></div=
></div></blockquote><div><br></div><div>You also get the costs of both appr=
oaches, which are extremely significant.</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x">
=C2=A0Censorship-resistance is irrelevant when one buys a cup of coffee wit=
h his pocket money, isn't it?</blockquote><div><br></div><div>That'=
s like saying banks can't censor you because you can always withdraw al=
l your money in cash. But in practice:</div>
<div><ol><li>That's a huge pain in the ass so nobody does it</li><li>Ma=
ny merchants will refuse non-trivial payments in cash and demand bank money=
because it's simpler for them</li></ol><div>Analogously, having to wai=
t some large expiry period to extract your money from the "double spen=
ding prevention service" (a.k.a. bitbank) is a pain in the ass, and ma=
ny merchants would refuse to take your newly double spendable money even if=
theoretically they could, because it keeps their operations much simpler i=
f they can just assume a sale is final and can't be reversed.</div>
</div><div><br></div><div>So I think such a scheme would rapidly return to =
the a world that looks much like the one we have now.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
></div><div>For some reason, instead of considering these hybrid solutions =
(which can also address scalability problems), you want to make PoW-based s=
ystem more complex to be applicable for real-time transaction too.<br>
</div></div></div></div></blockquote><div><br></div><div>The complexity ove=
rhead is trivial - we already used coinbase scriptSigs for voting on P2SH, =
I'm sure it'll be used for voting on other things in future too. So=
that's already in place. Counting up votes and editing the UTXO set is=
the sort of patch one guy can create, it's not very big. And it's =
conceptually just the same as what miners can do today by re-orging out blo=
cks, but with much less impact on end users and less implementation complex=
ity (no giant reorgs that might themselves have to split recursively whilst=
they're being built).</div>
<div><br></div><div>On the other hand, building an entirely separate system=
, with separate trusted companies that have trusted brand names, adding sup=
port to all the wallets, getting all sellers on board, making everything us=
e an extended BIP 70 (as that's the only real way to implement it), try=
ing to explain to users why they're now expected to pay extra fees when=
they previously didn't and then discovering that you got a choice of o=
nly a handful of double-spend-preventers everyone could agree on with littl=
e potential for more .... that's hugely complex and messy.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote">
<div></div>
<div>This will, likely, weaken advantages provided by PoW</div></div></div>=
</div></blockquote><div><br></div><div>Why? Remember deleting coinbases wit=
h nothing more than a simple majority is already possible in the existing p=
rotocol and always has been.=C2=A0</div>
</div></div></div>
--001a11c2cd18b6323a04f7c537d2--
|
