Hardfork Wishlist: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
Luke-jr (talk | contribs)
Luke-jr (talk | contribs)
→‎Bug fixes: Some way for bigger BIP 16 P2SH scripts
 
(68 intermediate revisions by 14 users not shown)
Line 1: Line 1:
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).
The '''Hardfork Wishlist''' is to record changes to Bitcoin that might be desirable, but that will require a [[Hardfork|"hard" block-chain split]] (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]).


This page is *not* for changes that can be accomplished in way that is compatible with old software.
This page is ''not'' for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[IsStandard|nonstandard]] or by [[Discouraged block|discouraging blocks]]).


====Changes to hard-coded limits====
This page is also not for changes that can be accomplished by a [[Softfork]].  See [[Softfork_wishlist]].
* Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000)


====Major structural changes====
== Changes to hard-coded limits ==
* "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0]
* 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: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0] [https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain.] [https://bitcointalk.org/index.php?topic=88208.0]
* 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.
* 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.
* Switch to block hashing algorithm secure against block withholding attacks.


====Transaction behavior changes====
== 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)
* Improved signature types to allow for partial malleability of outputs.  (e.g. make it easier to add a fee onto someone else's transaction, or to take fees from a transaction without outputs set aside for that purpose)
* 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.
* Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
* Allow additional inputs to generation transactions
* Add new signature hashtype to include value of TxOut being spent, in the hash to be signed.  Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.


====Cryptographic changes====
== Privacy ==
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* Better privacy using [http://en.wikipedia.org/wiki/Non-interactive_zero-knowledge_proof NIZKP]s, as proposed in [http://zerocoin.org Zerocoin] or similar.  
* Support for a post-quantum signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature 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. Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.


====Currency changes====
== 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 Chains|alternative chain]].''
''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<ref>[http://bitcointalk.org/index.php?topic=45468.msg542375#msg542375 Suggested MAJOR change to Bitcoin]</ref>, 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 granularity: three more decimal places would still fit all Bitcoin in 2^62 (e.g. you could sum any two signed bitcoin values without overflow in 64 bits) and would allow for pico-btc.
* Increase currency divisibility.


====Navel gazing / Protocol housekeeping====
== Navel gazing / Protocol housekeeping==
* Byte order consistency
* Byte order consistency (big endian)
* Eliminate redundancies in the variable length integer encodings
* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
* Avoiding hashes covering malleable fields
* Avoiding hashes covering malleable fields
* Mask out the must-be-zero bits in the previous-block-hash (block header) so miners can reuse them for nonce space.


====Bug fixes====
== Bug fixes ==
* 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') Note: An ideal adjustment algorithm would ensure there is no easy dispute on "next target" for any block. Eg, it should not be possible for MinerX to set his block time 2 hours in the future to achieve a slightly higher difficulty and win any same-block-height race by default.
* Difficulty adjustment should adapt to sudden hashrate loss. Note: many altchains which have attempted this have created significant security vulnerabilities in the process, but experimentation continues.
* Scripts should be fully enabled after a careful audit.
* Miners/relays should not be able to inject extra arbitrary data into transactions?
* 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.  Note that this problem has already been solved with a softfork in [https://bitcointalk.org/index.php?topic=92558.0 BIP34].
* coinbases must be parseable.
* This changes would involve converting old blocks: uint64_t for timestamp field in blocks.
* Retarget using previous 2016 intervals instead of 2015 intervals; this bug enables Artforz' [https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 time warp attack].
* Some way for bigger BIP 16 P2SH scripts
 
==See Also==
*[[Prohibited changes]]
 
==References==
<references />


[[Category:Technical]]
[[Category:Technical]]
[[Category:Developer]]
[[Category:Developer]]

Latest revision as of 18:53, 11 May 2016

The Hardfork Wishlist 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, considering them to be invalid blocks).

This page is not for changes that can be accomplished in way that is compatible with old software (for example, by making transactions nonstandard or by discouraging blocks).

This page is also not for changes that can be accomplished by a Softfork. See Softfork_wishlist.

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] [3] [4]
  • 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.
  • Switch to block hashing algorithm secure against block withholding attacks.

Transaction behavior changes

  • Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone else's transaction, or to take fees from a transaction without outputs set aside for that purpose)
  • 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.
  • Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
  • Allow additional inputs to generation transactions
  • Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.

Privacy

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[1], 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.

Navel gazing / Protocol housekeeping

  • Byte order consistency (big endian)
  • Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
  • Avoiding hashes covering malleable fields
  • Mask out the must-be-zero bits in the previous-block-hash (block header) so miners can reuse them for nonce space.

Bug fixes

  • CHECKMULTISIG popping one-too-many items off the stack
  • Difficulty adjustment periods should overlap (prevent potential 'timejacking') Note: An ideal adjustment algorithm would ensure there is no easy dispute on "next target" for any block. Eg, it should not be possible for MinerX to set his block time 2 hours in the future to achieve a slightly higher difficulty and win any same-block-height race by default.
  • Difficulty adjustment should adapt to sudden hashrate loss. Note: many altchains which have attempted this have created significant security vulnerabilities in the process, but experimentation continues.
  • Scripts should be fully enabled after a careful audit.
  • Miners/relays should not be able to inject extra arbitrary data into transactions?
  • 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. Note that this problem has already been solved with a softfork in BIP34.
  • coinbases must be parseable.
  • This changes would involve converting old blocks: uint64_t for timestamp field in blocks.
  • Retarget using previous 2016 intervals instead of 2015 intervals; this bug enables Artforz' time warp attack.
  • Some way for bigger BIP 16 P2SH scripts

See Also

References