public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      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 [Bitcoin-development] comments on BIP 100 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.com \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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