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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <alex.mizrahi@gmail.com>) id 1YyrBC-0002f4-DY
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 00:32:42 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.51 as permitted sender)
client-ip=74.125.82.51; envelope-from=alex.mizrahi@gmail.com;
helo=mail-wg0-f51.google.com;
Received: from mail-wg0-f51.google.com ([74.125.82.51])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YyrBB-0003DS-1S
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 00:32:42 +0000
Received: by wgme6 with SMTP id e6so88276456wgm.2
for <bitcoin-development@lists.sourceforge.net>;
Sat, 30 May 2015 17:32:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.194.193.71 with SMTP id hm7mr28677022wjc.40.1433032355004;
Sat, 30 May 2015 17:32:35 -0700 (PDT)
Received: by 10.27.102.73 with HTTP; Sat, 30 May 2015 17:32:34 -0700 (PDT)
In-Reply-To: <COL402-EAS257D9744762445A974BDA85CDC80@phx.gbl>
References: <COL402-EAS257D9744762445A974BDA85CDC80@phx.gbl>
Date: Sun, 31 May 2015 03:32:34 +0300
Message-ID: <CAE28kUQ8HYFAjsUXrah0CoRY9xJBVx7jo8RFgpVsP11ppThXtw@mail.gmail.com>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b873dc478c848051755d857
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
(alex.mizrahi[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: 1YyrBB-0003DS-1S
Subject: Re: [Bitcoin-development] Block Size Increase Requirements
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: Sun, 31 May 2015 00:32:42 -0000
--047d7b873dc478c848051755d857
Content-Type: text/plain; charset=UTF-8
>
> Stop trying to dictate block growth limits. Block size will be determined
> by competition between miners and availability of transactions, not through
> hard-coded limits.
>
Do you even game theory, bro? It doesn't work that way.
Mike Hearn described the problem in this article:
https://medium.com/@octskyward/hashing-7d04a887acc8
But the solution he's proposing is ridiculously bad and unsound: he expects
business owners to donate large sums of money towards mining. If it comes
to this, what sane business owner will donate, say, 100 BTC to miners
instead of seeking some alternatives? Proof-of-stake coins are already
there. I'm well aware of theoretical issues with PoS security, but those
theoretical issues aren't as bad as donation-funded cryptocurrency security.
But you know what works? Mining fees + block size limit.
Users and merchants are interested in their transactions being confirmed,
but block size limit won't allow it to turn into a race to bottom.
This is actually game-theoretically sound.
> I see now the temporary 1MB limit was a mistake. It should have gone in
> as a dynamic limit that scales with average block size.
>
This means that miners will control it, and miners couldn't care less about
things like decentralization and about problems of ordinary users. This
means that in this scenario Bitcoin will be 100% controlled by few huge-ass
mining operations.
Possibly a single operation. We already saw GHASH.IO using 51% of total
hashpower. Is that what you want?
Miners are NOT benevolent. This was already demonstrated. They are greedy.
--047d7b873dc478c848051755d857
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:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><p dir=3D"ltr">Stop trying to dictate block growth limits.=C2=
=A0 Block size will be determined by competition between miners and availab=
ility of transactions, not through hard-coded limits.</p></blockquote><div>=
Do you even game theory, bro? It doesn't work that way.</div><div><br><=
/div><div>Mike Hearn described the problem in this article:</div><div><a hr=
ef=3D"https://medium.com/@octskyward/hashing-7d04a887acc8">https://medium.c=
om/@octskyward/hashing-7d04a887acc8</a><br></div><div><br></div><div>But th=
e solution he's proposing is ridiculously bad and unsound: he expects b=
usiness owners to donate large sums of money towards mining. If it comes to=
this, what sane business owner will donate, say, 100 BTC to miners instead=
of seeking some alternatives? Proof-of-stake coins are already there. I=
9;m well aware of theoretical issues with PoS security, but those theoretic=
al issues aren't as bad as donation-funded cryptocurrency security.</di=
v><div><br></div><div>But you know what works? Mining fees + block size lim=
it.</div><div>Users and merchants are interested in their transactions bein=
g confirmed, but block size limit won't allow it to turn into a race to=
bottom.</div><div>This is actually game-theoretically sound.</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;padding-left:1ex"><p dir=3D"ltr">=C2=A0 I see now the temporary=
1MB limit was a mistake.=C2=A0 It should have gone in as a dynamic limit t=
hat scales with average block size.</p></blockquote><div>This means that mi=
ners will control it, and miners couldn't care less about things like d=
ecentralization and about problems of ordinary users. This means that in th=
is scenario Bitcoin will be 100% controlled by few huge-ass mining operatio=
ns.</div><div><br></div><div>Possibly a single operation. We already saw <a=
href=3D"http://GHASH.IO">GHASH.IO</a> using 51% of total hashpower. Is tha=
t what you want?</div><div><br></div><div>Miners are NOT benevolent. This w=
as already demonstrated. They are greedy.</div></div></div></div>
--047d7b873dc478c848051755d857--
|
