This topic is straying from Bitcoin development into general Bitcoin
governance, policy, or other meta-issues.
We have now the new bitcoin-discuss mailing list now, specifically for
these more free-flowing topics:
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
Please take fur
> It looks like some specific meta-level criteria would help more at this point
> than new proposals all exploring a different variants of block size increase
> schedules.
I agree. In fact, I’ll go meta on your meta and suggest that we should first
discuss how Bitcoin should be governed in the
> Date: Fri, 13 Nov 2015 11:37:51 -0500
> From: Emin G?n Sirer
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] How to evaluate block size increase
> suggestions.
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
>
I agree with the usefulness of at least trying to define a formal set
of criteria.
I'm afraid that with proposals that schedule future increases to the
blocksize consensus maximum or leave it for miners to decide (like
BIP100, BIP101 and BIP103) cannot be evaluated without making
assumptions about
I believe in the end it's the usability of bitcoin that matters.
For instance, a goal could be that no user on the network should wait more
than an hour to get 3 confirmations on the blockchain so that they can
actually have useful Bitcoins.
We can debate all we want about lots of technical aspec
By now, we have seen quite a few proposals for the block size increase.
It's hard not to notice that there are potentially infinitely many
functions for future block size increases. One could, for instance, double
every N years for any rational number N, one could increase linearly, one
could doubl
