Softfork wishlist
The Softfork Wishlist is to record changes to Bitcoin that might be desirable, but that will require a "soft" block-chain split (consensus of the miners). These changes are implemented by convincing a majority of the miners to reject or discourage blocks that were previously considered valid. This is often combined with a special form of pay-to-anybody transaction, which is declared to have a new meaning. Old clients will see the new transaction types as a pay-to-anybody, but attempts to "steal" these pay-to-anybody outputs without using the new transaction type will be refused by the miners and all upgraded clients.
This page is not for changes that 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). See Hardfork_Wishlist.
Block format
- Require a UTXO tree in every block
New Transaction Types
- Pay-to-SNARK (aka CoinWitness). This allows payment to a user who can produce cryptographic evidence that they ran a certain (time-bounded) program on a certain input argument. The size of the cryptographic evidence is linear in the input argument but constant with respect to the size and running time of the program, so bounding the size of the input argument bounds the size of the data that needs to be put into the blockchain. Unfortunately the time+space constant factors are, with current algorithms, rather large.
Cryptographic changes
- Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
- Support for more than one public-key cryptosystem (ECDSA-k1) and key size (256bits) as a hedge against future cryptanalysis or designed-in flaws in any one algorithm. Every node must support validation of signatures with every cryptosystem, but a small number of very-cryptograpically-diverse options is still better than just one. Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.
- Support for a post-quantum signature scheme. Lamport signatures have nice intuitive security properties, but it has extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). However other post-quantum schemes like IEEE1363.1 (patent expires in 2016) do not. See the introductory chapter of DJB's book and the PQCrypto conference webpage for full details.