Talk:Hardfork Wishlist

Obsolete item in "Bug Fixes"?

• Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network

As of BIP 34, isn't this item obsolete? --Airbreather (talk) 19:06, 9 February 2014 (GMT)

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)

And yet another variant of this: * Replace the 10 minute block finding target with a dynamic target decided by the market [2]. This one misses that the interblock time is important for convergence, also a naive implementation would change the payout schedule. --Gmaxwell (talk) 03:03, 28 July 2012 (GMT)

Trying to eliminate hard-coded time parameters means working in the "Partially Synchronous" communications model [3]. It's also equivalent to building a "partition tolerant" system in the sense of P in the CAP theorem. This is a difficult problem, and most proposed solutions to it are going to be broken. Still it's a fundamental goal, and it deserves its own section in the wishlist. --Amiller (talk) 08:46, 9 August 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. --Cunicula 7 April 2012

Merkle trees, lite clients, coinbase commitments, UTXOs

There have been at least four generations now of essentially the same proposal. I just added etotheipi's and DiThi's. The language for them has changed has many times. Should this be consolidated somewhere else? For what it's worth, I now prefer "hash graph" as the general term including chains, trees, and skiplists. --Amiller (talk) 08:37, 9 August 2012 (GMT)

'Permanent Forwarding'

As roughly sketched in the proposal bullet, this proposes some kind of new blockchain transaction-like directive to indicate permanent retirement of an old key and by-rule delegation of outputs to a new key. (This could solve some usability problems with prominently-advertised, but then lost or compromised, or suspected-compromised, keys.)

This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. WargeGeoshington (talk) 10:52, 13 June 2013 (GMT)

The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)

In idealized theory -- and perhaps in Satoshi's vision -- addresses are single-use. But that's not protocol-required and in practice, many users/apps reuse addresses and advertise long-lived addresses... which gives rise to the exact security/usability problem this proposal attempts to address.

So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --WargeGeoshington (talk) 05:15, 15 June 2013 (GMT)

Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? WargeGeoshington (talk) 18:42, 12 August 2013 (GMT)

Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -WargeGeoshington (talk) 02:14, 15 August 2013 (GMT)