public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dave Scotese <dscotese@litmocracy.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard
Date: Sat, 19 Dec 2015 11:04:01 -0800	[thread overview]
Message-ID: <CAGLBAhejrg=xgjeSy4UJLt92hUz8H0=a7sO859weX3=+p+hD6Q@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBhsKD8jd9Y9+ngXY5tKUheO3d4P1b47eYL=Uzpat+KJ2w@mail.gmail.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 --]

  reply	other threads:[~2015-12-19 19:04 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-16 14:53 [bitcoin-dev] Block size: It's economics & user preparation & moral hazard Jeff Garzik
2015-12-16 18:34 ` Pieter Wuille
2015-12-16 21:08   ` Jeff Garzik
2015-12-16 21:11     ` Pieter Wuille
2015-12-17  2:06       ` Jameson Lopp
2015-12-17 16:58       ` Tier Nolan
2015-12-17 19:44         ` Peter Todd
2015-12-18  5:23           ` Jorge Timón
2015-12-18  9:44           ` Tier Nolan
2015-12-16 21:24     ` Jorge Timón
2015-12-16 21:36       ` Jeff Garzik
2015-12-18  5:11   ` Jeff Garzik
2015-12-18  7:56     ` Pieter Wuille
2015-12-18 10:13       ` sickpig
2015-12-18 15:48         ` Pieter Wuille
2015-12-19 19:04           ` Dave Scotese [this message]
     [not found]           ` <751DFAA9-9013-4C54-BC1E-5F7ECB7469CC@gmail.com>
2015-12-26 16:44             ` Pieter Wuille
2015-12-26 17:20               ` Jorge Timón
2015-12-26 22:55               ` Jonathan Toomim
2015-12-26 23:01                 ` Pieter Wuille
2015-12-26 23:07                   ` Jonathan Toomim
2015-12-26 23:16                     ` Pieter Wuille
2015-12-27  0:03                       ` Jonathan Toomim
2015-12-26 23:15                   ` Justus Ranvier
2015-12-27  0:13                     ` Bryan Bishop
2015-12-27  0:33                       ` Justus Ranvier
2015-12-18 13:56       ` Jeff Garzik
2015-12-23  6:26   ` Aaron Voisine
2015-12-16 18:36 ` jl2012
2015-12-16 22:27   ` Jeff Garzik
2015-12-17  6:12     ` Dave Scotese

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='CAGLBAhejrg=xgjeSy4UJLt92hUz8H0=a7sO859weX3=+p+hD6Q@mail.gmail.com' \
    --to=dscotese@litmocracy.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pieter.wuille@gmail.com \
    /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