Re: [Bitcoin-development] comments on BIP 100

[Jeff Garzik <jgarzik@bitpay.com>]

[-- Attachment #1: Type: text/plain, Size: 6508 bytes --]

Adding - in re pay-to-FOO - these schemes are inherently short term, such
that it is near-impossible for the market to plan for what happens in 12+
months.

On Sun, Jun 14, 2015 at 10:28 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:

> 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/
>



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

[-- Attachment #2: Type: text/html, Size: 9189 bytes --]