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, "sick...@gmail.com" <sick...@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
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
