Hardfork Wishlist: Difference between revisions
Jump to navigation
Jump to search
→Bug fixes: Removing subsidy-drop changes as a non-viable economically significant change. |
No edit summary |
||
Line 30: | Line 30: | ||
* CHECKMULTISIG popping one-too-many items off the stack | * CHECKMULTISIG popping one-too-many items off the stack | ||
* Difficulty adjustment periods should overlap (prevent potential 'timejacking') | * Difficulty adjustment periods should overlap (prevent potential 'timejacking') | ||
* Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. | * Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block. | ||
* Scripts should be fully enabled after a careful audit. | * Scripts should be fully enabled after a careful audit. | ||
* Miners/relays should not be able to inject extra arbitrary data into transactions? | * Miners/relays should not be able to inject extra arbitrary data into transactions? |
Revision as of 23:25, 4 January 2012
This page is to record changes to Bitcoin that might be desirable, but that will require a "hard" block-chain split (everybody must upgrade, old software will not accept blocks/transactions created with the new rules).
This page is *not* for changes that can be accomplished in way that is compatible with old software.
Changes to hard-coded limits
- Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with ???.
Major structural changes
- "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [1] [2]
- Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
Transaction behavior changes
- Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone elses transaction, or to take fees from a transaction without outputs set aside for that putpose)
- Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
Cryptographic changes
- Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
- Support for a post-quantum signature scheme. Lamport signatures have nice intuitive security properties, but it and all other similar schemes have extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.
Currency changes
Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting alternative chain.
- Increase currency divisibility.
- Byte order consistency (big endian)
- Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
- Avoiding hashes covering malleable fields
Bug fixes
- CHECKMULTISIG popping one-too-many items off the stack
- Difficulty adjustment periods should overlap (prevent potential 'timejacking')
- Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block.
- Scripts should be fully enabled after a careful audit.
- Miners/relays should not be able to inject extra arbitrary data into transactions?