From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D8DA5F2C for ; Sat, 19 Dec 2015 19:04:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 84D39174 for ; Sat, 19 Dec 2015 19:04:02 +0000 (UTC) Received: by mail-oi0-f44.google.com with SMTP id l9so46380259oia.2 for ; Sat, 19 Dec 2015 11:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cauaKz+Di6gaSJd7oHljbQFq/eyoiKqOP+1TDSAY3D8=; b=WwJMT68za9Jz6+dJWsZbul0Ez8mxfUr4Pg/7XZSe3ZYkUHRY5wOWkdbiOPbdBmeyc3 XW4Zqgvl+2w7Zq0hBbIp1rfBpK9cYYtA6HXAFRKUpPgyLz/E35rwffJEZYnCJM4VVBC7 ILcyF+Ar9b8uEehnPMB+OtX2Uf5yU1dGiTWJJEV8/aZRZ1JxXtNQ3DWlWB5GsGIe6zix nRRgwt1LPZDErQcE+Qq+85k7gh+th7aUFA878dVrwjXbp1YiIkknh6sMJ06U9ZHiccXP zWwzF2lJj2uSLruqXBQoYbRlIWDw4nCPwNIeX4EYOWlwPbFsHx+LpmNXkkF/IO1/yiI6 GWMw== MIME-Version: 1.0 X-Received: by 10.202.227.199 with SMTP id a190mr3683984oih.35.1450551841919; Sat, 19 Dec 2015 11:04:01 -0800 (PST) Sender: dscotese@gmail.com Received: by 10.60.135.101 with HTTP; Sat, 19 Dec 2015 11:04:01 -0800 (PST) In-Reply-To: References: Date: Sat, 19 Dec 2015 11:04:01 -0800 X-Google-Sender-Auth: E0AnX19iTTCDy3sGxoCiO-ljvyc Message-ID: From: Dave Scotese To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a11407c8c441b05052744ebb1 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Dec 2015 19:04:04 -0000 --001a11407c8c441b05052744ebb1 Content-Type: text/plain; charset=UTF-8 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" 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 and Meme Racing (in alpha). I'm the webmaster for The Voluntaryist which now accepts Bitcoin. I also code for The Dollar Vigilante . "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto --001a11407c8c441b05052744ebb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've already publicly declared that I offer one b= itcoin to "those who suffer from a May 5, 2016 hardfork to 2MB blocks" but th= at's probably way too sloppy.=C2=A0 Here's a better idea that trans= mits the economic power of merchants and customers (well, anyone with bitco= in) to the miners on whom they must rely for confirmations:

Th= e bitcoin I offer is part of a fund that, when it reaches 25 BTC, will be p= ledged to a miner.=C2=A0 Here is how that miner earns the reward:
    Wait until a core dev signs a release of bitcoin core in which the limit = is double it's current level.
  1. Use the new release to mine, but = use a soft limit on the blocksize to produce only blocks that are valid acc= ording to the old software.
  2. Wait until May 5th, 2016.
  3. Remov= e the soft limit on blocksize.
  4. Create a block that breaks the o= ld limit and is valid according to the new signed release.
  5. Wait for= the new large block to be orphaned.

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

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

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 currentl= y running bitcoin software can be hot-patched on May 5th without the help o= f any core devs (if that would work).=C2=A0 Obviously, the little script sh= ould be signed by a competent programmer whom the user trusts, a slightly l= ess stringent requirement than being an actual core dev.

notplato
=


On Fri,= Dec 18, 2015 at 7:48 AM, Pieter Wuille via bitcoin-dev &= lt;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 =3D 1.375
>
> after six month.=C2=A0
>
> 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 a= nyone 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 need= ed if we don't want to be stuck with a constant maximum ultimately.

Hardforks can however only be deployed at a time when all fu= ll node software can reasonably have agreed to upgrade, while a softfork ca= n be deployed much earlier.

They are independent improvements, and we need both. I am ho= wever 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 sof= tforks).

--=C2=A0
Pieter


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev




--
I like to provide some work at no charge to pr= ove my value. Do you need a techie?=C2=A0
I own Litmocracy and Meme Racing (in alpha).
I'm th= e webmaster for T= he Voluntaryist which now accepts Bitcoin.
I also code for The Dollar Vigilante= .
"He ought to find it more profitable to play by the rules" -= Satoshi Nakamoto
--001a11407c8c441b05052744ebb1--