On Sun, Jun 14, 2015 at 5:23 PM, Adam Back <adam@cypherspace.org> wrote:

Hi

I made these comments elsewhere, but I think really we should be
having these kind of conversations here rather than scattered around.

These are about Jeff Garzik's outline draft BIP 100 I guess this is
the latest draft:  (One good thing about getting off SF would be
finally JGarzik's emails actually not getting blocked!).

http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

may have changed since the original [1]

Over the original proposal:

1. there should be a hard cap, not indefinitely growing.

In the latest draft there is an explicit 32MB ceiling now.

Users will need to opt into growth beyond 32MB via a 2nd hard fork.

 

2. there should be  a growth limiter (no more than X%/year)

As a general principle, this is an area of market disagreement, and should not be our call.  Encoding this into software veers into personal opinion about what economic policy should be.

That said  -- BIP 100, as a compromise, includes a growth limiter.  Abrupt change (1MB -> 32MB!) is awful on markets.  Good policies include a measured pace of transition from policy A to policy B.  It gives the community time to assess system effectiveness - while also allowing free market input.

In the long run I hope the cap is removed (see below), and the intention is to -slowly- and -transparently- move from the tightly controlled limit to something the free market and users are choosing.

 

3. I think the miners should not be given a vote that has no costs to
cast, because their interests are not necessarily aligned with users
or businesses.

I think Greg Maxwell's difficulty adjust [2] is better here for that
reason.  It puts quadratic cost via higher difficulty for miners to
vote to increase block-size, which miners can profitably do if there
are transactions with fees available to justify it. There is also the
growth limiter as part of Greg's proposal. [3]

"paying with difficulty" has severe negative elements that will likely cause it never to be used:

- complex and difficult for miners to reason

- fails the opportunity cost test - dollar cost lost losing the block race versus value gained by increasing block size

- inherently unpredictable in the short term - user experience is that it's possibly difficult to see a gain in utility versus the revenue you are giving up

- REQUIRES informal miner collusion - probably less transparent than BIP 100 - in order to solve the who-goes-first problem.

- net result: tough sell

Paying bitcoins to future miners makes a lot more sense.  Initially I was a fan of pay-with-diff, but freezing bitcoins (CLTV) or timelock'd anyone-can-spend has much more clear incentives, if you want to go down that road.

Problems with pay-to-increase-block-size:

- how much to pay?  You are inherently setting your growth policy on top of bitcoin by choosing a price here.

- another who-goes-first problem

Anyway, there is a natural equilibrium block size that the free market and user choice will seek.

Related:  There is a lot of naive "miner = max income = max block size" reasoning going on, with regards to fees.  This is defining the bounds of an economically scarce resource.  There are many reasons why a miner will today, in the real world, limit their block size. WRT fee income, if block size is too large the fee competition in the overall market is low-to-zero, fee income rapidly collapses.  Then factor in price and demand elasticity on top of that.

Quite frankly, there seems to be a natural block size equilibrium ceiling, and I worry about miners squeezing the market by maximizing their fee income through constrained block sizes and competition at the low end.  This is of course already possible today - miners may openly or covertly collude to keep the block size low.

 

I think bitcoin will have to involve layering models that uplift
security to higher layers, but preserve security assurances, and
smart-contracts even, with protocols that improve the algorithmic
complexity beyond O(n^2) in users, like lightning, and there are
multiple other candidates with useful tradeoffs for various use-cases.

One thing that is concerning is that few in industry seem inclined to
take any development initiatives or even integrate a library.  I
suppose eventually that problem would self-correct as new startups
would make a more scalable wallet and services that are layer2 aware
and eat the lunch of the laggards.  But it will be helpful if we
expose companies to the back-pressure actually implied by an O(n^2)
scaling protocol and don't just immediately increase the block-size to
levels that are dangerous for decentralisation security, as an
interventionist subsidy to save them having to do basic integration
work.  Otherwise I think whichever any kind of kick the can some 2-5
years down the road we consider, we risk the whole saga repeating in a
few years, when no algorithmic progress has been made and even more
protocol inertia has set in.

Adam

[1] original proposal comments on reddit
https://www.reddit.com/r/Bitcoin/comments/39kzyt/draft_bip_100_soft_fork_block_size_increase/

[2] flexcap propoal by Greg Maxwell see post by Mark Freidenbach
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07599.html

[3] growth limited proposal for flexcap by Greg Maxwell
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07620.html

------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--

Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/