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 <jgar...@bitpay.com> wrote: > On Sun, Jun 14, 2015 at 5:23 PM, Adam Back <a...@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/
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
