From: Peter Todd <pete@petertodd•org>
To: Matt Corallo <bitcoin-list@bluematt•me>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Block Size Increase
Date: Wed, 6 May 2015 21:49:52 -0400 [thread overview]
Message-ID: <20150507014952.GA5657@savin.petertodd.org> (raw)
In-Reply-To: <554A91BE.6060105@bluematt.me>
[-- Attachment #1: Type: text/plain, Size: 4393 bytes --]
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=2400519
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/msg02323.html
--
'peter'[:-1]@petertodd.org
000000000000000004dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-05-07 1:50 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 22:12 Matt Corallo
2015-05-06 22:30 ` slush
2015-05-06 23:06 ` Eric Lombrozo
2015-05-06 22:44 ` Tier Nolan
2015-05-06 23:12 ` Matt Corallo
2015-05-06 23:33 ` Tier Nolan
2015-05-06 23:41 ` Matt Corallo
2015-05-07 2:16 ` Peter Todd
2015-05-06 23:11 ` Matt Whitlock
2015-05-06 23:13 ` Matt Corallo
2015-05-07 0:00 ` Tom Harding
2015-05-07 0:07 ` Bryan Bishop
2015-05-07 0:37 ` Gregory Maxwell
2015-05-07 1:49 ` Peter Todd [this message]
2015-05-07 3:03 ` Justus Ranvier
2015-05-08 11:02 ` Thomas Zander
2015-05-08 20:17 ` Aaron Voisine
2015-05-07 3:47 ` Pieter Wuille
2015-05-07 9:25 ` Mike Hearn
2015-05-07 10:12 ` Peter Todd
2015-05-07 10:42 ` Btc Drak
2015-05-07 10:52 ` Jorge Timón
2015-05-07 11:15 ` Andrew
2015-05-07 11:29 ` Mike Hearn
2015-05-07 12:26 ` Jorge Timón
2015-05-07 14:05 ` Mike Hearn
2015-05-07 14:18 ` Bryan Bishop
2015-05-07 14:22 ` Peter Todd
2015-05-07 14:40 ` Peter Todd
2015-05-07 14:52 ` Gavin Andresen
2015-05-07 14:56 ` Peter Todd
2015-05-07 15:04 ` Alex Morcos
2015-05-07 15:09 ` Jeff Garzik
2015-05-07 15:12 ` Mike Hearn
2015-05-07 15:17 ` Jeff Garzik
2015-05-07 15:29 ` Mike Hearn
2015-05-07 15:35 ` Jeff Garzik
2015-05-07 16:18 ` Justus Ranvier
2015-05-07 16:21 ` Jorge Timón
2015-05-07 17:29 ` Peter Todd
2015-05-07 19:37 ` Mike Hearn
2015-05-07 19:44 ` Jérémie Dubois-Lacoste
2015-05-07 20:20 ` Jérémie Dubois-Lacoste
2015-05-07 15:58 ` Matthew Mitchell
2015-05-07 16:47 ` Matthew Mitchell
2015-05-07 17:26 ` Matt Corallo
[not found] ` <CABsx9T2vAQyZODRE9apu0R1n=LybssQcuTYD7P3mAQH_Fv6QCQ@mail.gmail.com>
2015-05-07 17:40 ` [Bitcoin-development] Fwd: " Gavin Andresen
2015-05-07 17:43 ` [Bitcoin-development] " Mike Hearn
2015-05-07 18:03 ` Btc Drak
2015-05-07 18:06 ` Mike Hearn
2015-05-07 18:21 ` Ross Nicoll
2015-05-07 18:40 ` Gavin Costin
2015-05-07 18:46 ` Btc Drak
2015-05-07 19:31 ` Bernard Rihn
2015-05-07 19:31 ` Alan Reiner
2015-05-07 19:54 ` Jeff Garzik
2015-05-07 19:59 ` Justus Ranvier
2015-05-08 1:40 ` Tom Harding
2015-05-08 2:09 ` Jeff Garzik
2015-05-08 5:13 ` Tom Harding
2015-05-08 9:43 ` Mike Hearn
2015-05-08 15:23 ` Alan Reiner
2015-05-08 14:59 ` Alan Reiner
2015-05-08 15:49 ` Jeff Garzik
2015-05-13 10:37 ` Oliver Egginger
2015-05-13 11:25 ` Angel Leon
2015-05-08 17:17 ` Andrew
2015-05-08 17:51 ` Alan Reiner
[not found] ` <CADZB0_bK+YsK8sN-di2pynvjsq5VjSvnEu0-cCGhPqFunyVm7Q@mail.gmail.com>
2015-05-09 12:02 ` Andrew
2015-05-09 12:53 ` Justus Ranvier
2015-05-09 18:33 ` Andrew
2015-05-08 1:51 ` Joel Joonatan Kaartinen
2015-05-08 3:41 ` Peter Todd
2015-05-07 18:38 ` Chris Wardell
2015-05-07 18:55 ` Alex Mizrahi
2015-05-07 18:59 ` Ross Nicoll
2015-05-07 19:03 ` Matt Corallo
2015-05-07 19:13 ` Jeff Garzik
2015-05-07 19:34 ` Mike Hearn
2015-05-07 21:29 ` Matt Corallo
2015-05-07 23:05 ` 21E14
2015-05-07 15:33 ` Jorge Timón
2015-05-07 16:11 ` Mike Hearn
2015-05-07 16:47 ` Jorge Timón
2015-05-07 16:59 ` Gavin Andresen
2015-05-07 17:42 ` Peter Todd
2015-05-07 18:05 ` Jorge Timón
2015-05-07 19:57 ` Btc Drak
2015-05-07 15:39 ` Btc Drak
2015-05-07 13:02 ` Peter Todd
2015-05-07 19:14 ` Matt Corallo
2015-05-07 11:55 ` Dave Hudson
2015-05-07 13:40 ` Jorge Timón
2015-05-08 4:46 ` Tom Harding
2015-05-07 14:04 ` Jeff Garzik
2015-05-07 14:32 ` Peter Todd
2015-05-07 14:38 ` Justus Ranvier
2015-05-07 14:49 ` Peter Todd
2015-05-07 15:13 ` Justus Ranvier
2015-05-07 15:25 ` Peter Todd
2015-05-07 15:04 ` Jeff Garzik
2015-05-07 15:16 ` Justus Ranvier
2015-05-07 15:27 ` Jeff Garzik
2015-05-07 15:33 ` Justus Ranvier
2015-05-07 15:47 ` Jeff Garzik
2015-05-07 15:50 ` Justus Ranvier
2015-05-07 11:20 ` Wladimir J. van der Laan
2015-05-07 11:30 ` Eric Lombrozo
2015-05-07 15:56 ` Jeff Garzik
2015-05-07 16:13 ` Mike Hearn
2015-05-07 16:54 John Bodeen
2015-05-08 20:38 Raystonn .
2015-05-08 20:40 ` Mark Friedenbach
2015-05-08 20:51 Raystonn
2015-05-08 20:55 ` Mark Friedenbach
2015-05-08 21:01 Raystonn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150507014952.GA5657@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-list@bluematt$(echo .)me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox