Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Dave Scotese <dscotese@litmocracy.com>]

[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]

I've already publicly declared that I offer one bitcoin to "those who
suffer from a May 5, 2016 hardfork to 2MB blocks" but that's probably way
too sloppy.  Here's a better idea that transmits the economic power of
merchants and customers (well, anyone with bitcoin) to the miners on whom
they must rely for confirmations:

The bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be
pledged to a miner.  Here is how that miner earns the reward:

   1. Wait until a core dev signs a release of bitcoin core in which the
   limit is double it's current level.
   2. Use the new release to mine, but use a soft limit on the blocksize to
   produce only blocks that are valid according to the old software.
   3. Wait until May 5th, 2016.
   4. Remove the soft limit on blocksize.
   5. Create a block that breaks the old limit and is valid according to
   the new signed release.
   6. Wait for the new large block to be orphaned.

Hopefully, the reward will be greater than 25 bitcoins and therefore cover
the transaction fees.  Of course, if they wait until after the halving in
step 3, then they will get twice the (new, 12.5 btc) reward if they can
arrange for the orphaning of their own block.

Any core dev could do this but I guess it would be playing with fire.  So
maybe Satoshi will do it.  He played with fire (right?) and look how that
worked out.  Come on, someone, be a hero.  Mike and Gavin tried, but I
think they went a little overboard.

Another way to do this is to identify the position in each binary where the
hard limit is stored, and write a little script that will (check the date
first, and then) alter the data at that position so that currently running
bitcoin software can be hot-patched on May 5th without the help of any core
devs (if that would work).  Obviously, the little script should be signed
by a competent programmer whom the user trusts, a slightly less stringent
requirement than being an actual core dev.

notplato

On Fri, Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On Dec 18, 2015 2:13 AM, "sickpig@gmail.com" <sickpig@gmail.com> wrote:
> > 1.75 x 0.5 + 1 x 0.5 = 1.375
> >
> > after six month.
> >
> > An hard-fork on the others side would bring 1.75 since the activation,
> am I right?
>
> Yes.
>
> However, SW immediately gives a 1.75 capacity increase for anyone who
> adopts it, after the softfork, instantly. They don't need to wait for
> anyone else.
>
> A hard fork is an orthogonal improvement, which is also needed if we don't
> want to be stuck with a constant maximum ultimately.
>
> Hardforks can however only be deployed at a time when all full node
> software can reasonably have agreed to upgrade, while a softfork can be
> deployed much earlier.
>
> They are independent improvements, and we need both. I am however of the
> opinion that hard forks need a much clearer consensus and much longer
> rollout timeframes to be safe (see my thread on the security of softforks).
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>


-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 4858 bytes --]