[Bitcoin-development] Proposed alternatives to the 20MB step function
gavinandresen at gmail.com
Sat May 9 11:58:20 UTC 2015
RE: fixing sigop counting, and building in UTXO cost: great idea! One of
the problems with this debate is it is easy for great ideas get lost in all
RE: a hard upper limit, with a dynamic limit under it:
I like that idea. Can we drill down on the hard upper limit?
There are lots of people who want a very high upper limit, right now (all
the big Bitcoin companies, and anybody who thinks as-rapid-as-possible
growth now is the best path to long-term success). This is the "it is OK if
you have to run full nodes in a data center" camp.
There are also lots of people who want an upper limit low enough that they
can continue to run Bitcoin on the hardware and Internet connection that
they have (or are concerned about centralization, so want to make sure
OTHER people can continue to run....).
Is there an upper limit "we" can choose to make both sets of people mostly
happy? I've proposed "must be inexpensive enough that a 'hobbyist' can
afford to run a full node" ...
Is the limit chosen once, now, via hard-fork, or should we expect multiple
hard-forks to change it "when necessary" ?
The economics change every time the block reward halves, which make me
think that might be a good time to adjust the hard upper limit. If we have
a hard upper limit and a lower dynamic limit, perhaps adjusting the hard
upper limit (up or down) to account for the block reward halving, based on
the dynamic limit....
RE: the lower dynamic limit algorithm: I REALLY like that idea.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev