Author: Dave Scotese 2015-12-19 19:04:01
Published on: 2015-12-19T19:04:01+00:00
The author of the email has offered one Bitcoin to those who suffer from a May 5, 2016 hardfork to 2MB blocks. However, he suggests a better way to incentivize miners for confirming transactions - by pledging a portion of a fund that will be awarded to a miner when it reaches 25 BTC. The miner would earn the reward by waiting until a core dev signs a release of bitcoin core in which the limit is double its current level, using the new release to mine, but with a soft limit on the blocksize to produce only blocks that are valid according to the old software, and finally breaking the old limit and creating a block that is valid according to the new signed release. The author acknowledges the risks involved in this approach, stating that any core dev could do this but it would be playing with fire. Another way to achieve this would be to identify the position in each binary where the hard limit is stored, and write a script that will 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. Pieter Wuille responds to another email in the thread, noting that while a hard fork is an orthogonal improvement, which is also needed if we don't want to be stuck with a constant maximum ultimately, hard forks need a much clearer consensus and much longer rollout timeframes to be safe.
Updated on: 2023-06-11T02:11:07.888571+00:00