From: Jeff Garzik <jgarzik@bitpay•com>
To: Adam Back <adam@cypherspace•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
Date: Sun, 14 Jun 2015 22:44:22 -0400 [thread overview]
Message-ID: <CAJHLa0OcHuWcQeS7dRYHjyqBBkLyxr3XXe2sYGC9Xh2e4UOKDw@mail.gmail.com> (raw)
In-Reply-To: <CAJHLa0Mj7kAz4=yrZo=+nvoV97rF_xAvHGt+A3D2qE3P16zKBw@mail.gmail.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 --]
prev parent reply other threads:[~2015-06-15 2:44 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 21:23 Adam Back
2015-06-14 22:23 ` Mike Hearn
2015-06-14 23:58 ` Adam Back
2015-06-15 0:53 ` Eric Lombrozo
2015-06-15 0:55 ` Eric Lombrozo
2015-06-15 4:11 ` Peter Todd
2015-06-15 4:43 ` Eric Lombrozo
2015-06-15 9:27 ` Mike Hearn
2015-06-15 9:39 ` Eric Lombrozo
2015-06-15 10:24 ` Pieter Wuille
2015-06-15 10:36 ` Mike Hearn
2015-06-15 10:40 ` Pieter Wuille
2015-06-15 10:50 ` Mike Hearn
2015-06-15 11:16 ` Rebroad (sourceforge)
2015-06-15 17:53 ` Raystonn .
2015-06-15 18:14 ` Adam Back
2015-06-15 18:57 ` [Bitcoin-development] The Bitcoin Node Market Raystonn .
2015-06-15 19:18 ` sickpig
2015-06-15 19:36 ` Raystonn .
2015-06-15 20:12 ` sickpig
2015-06-16 3:30 ` Kevin Greene
2015-06-16 3:41 ` Luke Dashjr
2015-06-16 3:49 ` Kevin Greene
2015-06-16 4:05 ` Kevin Greene
2015-06-16 4:12 ` Aaron Voisine
2015-06-16 5:28 ` justusranvier
2015-06-16 5:30 ` Potter QQ
2015-06-16 7:55 ` Aaron Voisine
2015-06-16 13:32 ` justusranvier
2015-06-16 17:04 ` Aaron Voisine
2015-06-16 17:22 ` Aaron Voisine
2015-06-16 15:52 ` devrandom
2015-06-15 4:43 ` [Bitcoin-development] comments on BIP 100 Peter Todd
2015-06-15 9:06 ` Mike Hearn
2015-06-15 2:28 ` Jeff Garzik
2015-06-15 2:44 ` Jeff Garzik [this message]
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=CAJHLa0OcHuWcQeS7dRYHjyqBBkLyxr3XXe2sYGC9Xh2e4UOKDw@mail.gmail.com \
--to=jgarzik@bitpay$(echo .)com \
--cc=adam@cypherspace$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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