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
|
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 <pete@petertodd.org>) id 1YqAww-0003uE-5X
for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 01:50:06 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.55 as permitted sender)
client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
helo=outmail149055.authsmtp.co.uk;
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1YqAwu-0002Ky-A7 for bitcoin-development@lists.sourceforge.net;
Thu, 07 May 2015 01:50:06 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t471nvwm012272;
Thu, 7 May 2015 02:49:57 +0100 (BST)
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t471nrXs091233
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 7 May 2015 02:49:55 +0100 (BST)
Date: Wed, 6 May 2015 21:49:52 -0400
From: Peter Todd <pete@petertodd.org>
To: Matt Corallo <bitcoin-list@bluematt.me>
Message-ID: <20150507014952.GA5657@savin.petertodd.org>
References: <554A91BE.6060105@bluematt.me>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB"
Content-Disposition: inline
In-Reply-To: <554A91BE.6060105@bluematt.me>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 5c98a2bb-f45b-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgUUFVQNAgsB AmMbW1ZeVFR7XGU7 bA9PbARUfEhLXhtr
VklWR1pVCwQmRRgG B0BcOlpyfgREe30+ ZEFmWXgVWRdzfRd/
EBxJQ2kDN3phaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDNDo7 TBNKJjQ9EAUkQS4p IhU9JzYB
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1YqAwu-0002Ky-A7
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
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, 07 May 2015 01:50:06 -0000
--DocE+STaALJfprDB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, May 06, 2015 at 10:12:14PM +0000, Matt Corallo wrote:
> Personally, I'm rather strongly against any commitment to a block size
> increase in the near future. Long-term incentive compatibility requires
> that there be some fee pressure, and that blocks be relatively
> consistently full or very nearly full. What we see today are
> transactions enjoying next-block confirmations with nearly zero pressure
> to include any fee at all (though many do because it makes wallet code
> simpler).
Agreed.
I'm not sure if you've seen this, but a good paper on this topic was
published recently: "The Economics of Bitcoin Transaction Fees"
Abstract
--------
We study the economics of Bitcoin transaction fees in a simple static
partial equilibrium model with the specificity that the system security
is directly linked to the total computational power of miners. We show
that any situation with a fixed fee is equivalent to another situation
with a limited block size. In both cases, we give the optimal value of
the transaction fee or of the block size. We also show that making the
block size a non binding constraint and, in the same time, letting the
fee be fixed as the outcome of a decentralized competitive market cannot
guarantee the very existence of Bitcoin in the long-term.
-http://papers.ssrn.com/sol3/papers.cfm?abstract_id=3D2400519
In short, without either a fixed blocksize or fixed fee per transaction
Bitcoin will will not survive as there is no viable way to pay for PoW
security. The latter option - fixed fee per transaction - is non-trivial
to implement in a way that's actually meaningful - it's easy to give
miners "kickbacks" - leaving us with a fixed blocksize.
> This allows the well-funded Bitcoin ecosystem to continue building
> systems which rely on transactions moving quickly into blocks while
> pretending these systems scale. Thus, instead of working on technologies
I think this lack of understanding of the limitations of blockchain tech
is very dangerous, never mind, downright misleading. I keep running into
startups at conferences with completely unrealistic ideas about how
large they'll be able to grow their on-blockchain businesses. For
example, a few weeks ago at the Stanford blockchain conference I spoke
to a company planning on using multisig escrow contracts to settle
financial instruments, and expected to be doing about as many
transactions/day on the blockchain for their business within a year or
so as all other Bitcoin users currently do combined. These guys quite
frankly had no understanding of the issues, and had apparently based
their plans on the highly optimistic Bitcoin wiki page on
scalability.(1) (I'd fix this now, but the wiki seems to not be allowing
logins)
We'd do a lot of startups a lot of good to give them accurate, and
honest, advice about the scalability of the system. The wiki definitely
isn't that. Neither is the bitcoin.org developer documentation(2), which
doesn't mention scalability at all.
> which bring Bitcoin's trustlessness to systems which scale beyond a
> blockchain's necessarily slow and (compared to updating numbers in a
> database) expensive settlement, the ecosystem as a whole continues to
> focus on building centralized platforms and advocate for changes to
> Bitcoin which allow them to maintain the status quo[1].
Even a relatively small increase to 20MB will greatly reduce the number
of people who can participate fully in Bitcoin, creating an environment
where the next increase requires the consent of an even smaller portion
of the Bitcoin ecosystem. Where does that stop? What's the proposed
mechanism that'll create an incentive and social consensus to not just
'kick the can down the road'(3) and further centralize but actually
scale up Bitcoin the hard way? The only proposal that I've seen that
attempts to do this is John Dillon's proof-of-stake blocksize vote(4),
and that is far from getting consensus.
1) https://en.bitcoin.it/wiki/Scalability
2) https://bitcoin.org/en/developer-guide
3) http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea
4) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms=
g02323.html
--=20
'peter'[:-1]@petertodd.org
000000000000000004dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e
--DocE+STaALJfprDB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVSsS8XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNGRjODY3ZTQ1NDEzMTUwOTAzMjlmNDVlZDRkZDMwZTJm
ZDc0MjNhMzhhNzJjMGUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftCCgf/U4SSDbDT8iDjs/1CIgizJPDW
CQjaoEEXNVnOav088jKu6HjzCh1oml/BNn3DL275KKMzNp4y1+BAmTswRQMCGwv1
RJGkhKjSdQKmF++cd8pRnm9kMX/JQDBxykMEs1PytBe0yL4wD1G6GOY0niyyQDDg
MueIc89Iz1nTLCOxkuzs9LdRtsrX36+Jmg3V9mfdhtYzIOVJxZCfzIfxi86BTBM6
GF8l0+hMdlnDcFshE8DZzIh1R1dvrT7Qo3jtjcFpN3j1/AIjqor2BlBa3xXCU/yg
jF2NBEIv75dcCA4gsK5+h7TeJt1PN0Y5trg+lLVzGw8AzZeROLk825oEALw3WA==
=JhUT
-----END PGP SIGNATURE-----
--DocE+STaALJfprDB--
|
