Talk:Hardfork Wishlist

Proposals which reduce security

"Difficulty adjustment should adapt to sudden hashrate loss"

It's really hard to construct general proofs, but I believe that _all_ such schemes substantially reduce the cost of performing forged chain attacks against isolated nodes. I gave an argument of this here, assuming a particular decrease handling improvement: [1]

Beyond those problems schemes with asymmetric difficulty creates non-linearities which make it profitable for miners as a group to game the system: e.g. turn off until it falls fast, then turn on until it catches back up. The current mostly linear system doesn't enable this even if the miners conspire.

One of my concerns about this page is that lots of ideas sound just fantastic until you consider their costs, or sound great so long as you don't mind their particular costs. Because these changes must be adopted by consensus and because people evaluate costs differently it's hard to find things that win the cost/benefit analysis for almost everyone.

In my opinion, the drop risk is inconsequential: Having the average txn time go to 20 minutes for a month isn't really a big deal... and if there is a bigger drop then the slow txn processing time will be the least of our problems. The costs here are not speculative, altchains with "improved" difficulty adjustments have been exploited several times. The benefit is purely speculative and primarily matters only if bitcoin is already failing.

Perhaps we should change the page to tabular layout so that we can link to for and against arguments for features where ones exist? --Gmaxwell 19:59, 4 January 2012 (GMT)

OP_FAIL FAILS

I've removed this suggestion:

Futureproofing

• Add a few new opcodes called OP_FAILn or repurpose them from OP_NOPn. These would immediately fail a transaction, and like OP_NOPn, would be available as new opcodes for future purposes, but without the burden of old clients dangerously understanding them as "do nothing".

Because it's idiotic. You could already use undefined opcodes for this— but even that is stupid, the reason the the OP_NOPs are useful for futureproofing is specifically because they pass. The fact that they pass is what enables you to run a mixed network. If you use an opcode that always fails for old nodes as an extension mechanism the instant that it gets mined the network forks. --Gmaxwell 17:13, 19 February 2012 (GMT)

Removed 'Proof of Stake'

I've removed:

• Augment Proof of work with Proof of Stake as the mechanism for generating blocks.

As non-viable due to being economically significant. --Gmaxwell 14:42, 12 March 2012 (GMT) Economic theory unambiguously indicates that the current protocol will fail eventually. It will need to be changed either before or when this happens. A proof-of-stake system is likely the only viable long-term solution. Preparing for a forseeable problem is only prudent. --[[User:Cunicula 7 April 2012