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