Hardfork Wishlist - Revision history

Luke-jr: /* Bug fixes */ Some way for bigger BIP 16 P2SH scripts

2016-05-11T18:53:59Z

Bug fixes: Some way for bigger BIP 16 P2SH scripts

← Older revision		Revision as of 18:53, 11 May 2016
Line 43:		Line 43:
	* This changes would involve converting old blocks: uint64_t for timestamp field in blocks.		* 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].		* 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==		==See Also==

Luke-jr: /* Navel gazing / Protocol housekeeping */ This is missing

2016-02-06T00:07:29Z

Navel gazing / Protocol housekeeping: This is missing

← Older revision		Revision as of 00:07, 6 February 2016
Line 31:		Line 31:
	* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.		* 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 ==

Gmaxwell at 06:49, 8 November 2014

2014-11-08T06:49:10Z

← Older revision		Revision as of 06:49, 8 November 2014
Line 1:		Line 1:
	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]]).		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 (for example, by making transactions [[~~Nonstandard block~~\|nonstandard]] or by [[Discouraged block\|discouraging blocks]]).		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]]).

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

Eldentyrell: /* Bug fixes */

2014-03-30T13:22:00Z

Bug fixes

← Older revision		Revision as of 13:22, 30 March 2014
Line 40:		Line 40:
	* 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].		* 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.		* coinbases must be parseable.
	This changes would involve converting old blocks:		* This changes would involve converting old blocks: uint64_t for timestamp field in 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].		* 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].

Eldentyrell: add timewarp attack

2014-03-30T13:05:29Z

add timewarp attack

← Older revision		Revision as of 13:05, 30 March 2014
Line 42:		Line 42:
	This changes would involve converting old blocks:		This changes would involve converting old blocks:
	* uint64_t for timestamp field in 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].

	==See Also==		==See Also==

Eldentyrell: move softfork-implementable changes to Softfork_wishlist

2014-03-22T17:51:09Z

move softfork-implementable changes to Softfork_wishlist

← Older revision		Revision as of 17:51, 22 March 2014
Line 12:		Line 12:
	* 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.		* Switch to block hashing algorithm secure against block withholding attacks.
	* Require a [https://en.bitcoin.it/wiki/Thin_Client_Security#Unused_Output_Tree_in_the_Blockchain_.28UOT.29 UTXO tree] in every block

	== Transaction behavior changes==		== Transaction behavior changes==
Line 20:		Line 19:
	* Allow additional inputs to generation transactions		* 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.		* 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.
	* Pay-to-[http://eprint.iacr.org/2013/507.pdf SNARK] (aka [https://bitcointalk.org/index.php?topic=277389.0 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)
	* [http://ed25519.cr.yp.to/ Ed25519] (variant*) for much faster validation operations. (variant because the normal way Ed25519 is specified is not key recovery compatible)
	* 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 [http://en.wikipedia.org/wiki/Post-quantum_cryptography post-quantum] signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature 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 [http://en.wikipedia.org/wiki/NTRU IEEE1363.1] (patent expires in 2016) do not. See the [http://pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf introductory chapter of DJB's book] and the [http://pqcrypto.org PQCrypto conference webpage] for full details.

	== Privacy ==		== Privacy ==

Eldentyrell: Add link to Softfork_wishlist

2014-03-22T17:46:57Z

Add link to Softfork_wishlist

← Older revision		Revision as of 17:46, 22 March 2014
Line 2:		Line 2:

	This page is ''not'' for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[Nonstandard block\|nonstandard]] or by [[Discouraged block\|discouraging 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 block\|nonstandard]] or by [[Discouraged block\|discouraging blocks]]).

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

	== Changes to hard-coded limits ==		== Changes to hard-coded limits ==

Eldentyrell at 17:41, 22 March 2014

2014-03-22T17:41:17Z

← Older revision		Revision as of 17:41, 22 March 2014
Line 1:		Line 1:
	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]]).		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 (for example, by making transactions [[Nonstandard block\|nonstandard]] or by [[Discouraged block\|discouraging 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 block\|nonstandard]] or by [[Discouraged block\|discouraging blocks]]).

Eldentyrell at 17:41, 22 March 2014

2014-03-22T17:41:05Z

← Older revision		Revision as of 17:41, 22 March 2014
Line 1:		Line 1:
	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 [[Protocol rules\|rules]], considering them to be [[Invalid block\|invalid blocks]]).		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 (for example, by making transactions [[Nonstandard block\|nonstandard]] or by [[Discouraged block\|discouraging 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 block\|nonstandard]] or by [[Discouraged block\|discouraging blocks]]).

Eldentyrell: /* Transaction behavior changes */

2014-03-22T17:40:21Z

Transaction behavior changes

← Older revision		Revision as of 17:40, 22 March 2014
Line 18:		Line 18:
	* Allow additional inputs to generation transactions		* 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.		* 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.
			* Pay-to-[http://eprint.iacr.org/2013/507.pdf SNARK] (aka [https://bitcointalk.org/index.php?topic=277389.0 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==		== Cryptographic changes==