User:Gmaxwell/features - Revision history

Gmaxwell: /* Proofs */ formatting

2014-04-08T19:37:01Z

Proofs: formatting

← Older revision		Revision as of 19:37, 8 April 2014
Line 97:		Line 97:
	** Possible in the current system: Proof is tree fragments for the invalid txn in question as well as one invalid input (no need to include more than one).		** Possible in the current system: Proof is tree fragments for the invalid txn in question as well as one invalid input (no need to include more than one).
	** Could be made more efficient by including commitments to intermediate states, but with the 201 opcode limit all scripts are compact to verify in Bitcoin without doing anything fancier.		** Could be made more efficient by including commitments to intermediate states, but with the 201 opcode limit all scripts are compact to verify in Bitcoin without doing anything fancier.
	Also proves nlocktime, etc.		** Also proves nlocktime, etc.
	** To prove output value greater than inputs all inputs must be provided in the proof.		** To prove output value greater than inputs all inputs must be provided in the proof.

Line 104:		Line 104:

	* Proof of false inflation		* Proof of false inflation
	** Not possible ~~in the current system~~: The coinbase payment is the sum of fees in a block and the subsidy. Fees require knowing the transaction's inputs output values, to check subsidy you must not only have all the transactions but all their inputs as well.		** Not possible without more data: The coinbase payment is the sum of fees in a block and the subsidy. Fees require knowing the transaction's inputs output values, to check subsidy you must not only have all the transactions but all their inputs as well.
	** This is fixable. Replace the hash tree with one that H((fees_left+fees_right)\|\|H(left)\|\|H(right)) so that the tree commits to the fees. Nodes can randomly check this by grabbing a random txn and checking its inputs, and compactly prove violation by showing where the fees don't match their commitments.		** This is fixable. Replace the hash tree with one that H((fees_left+fees_right)\|\|H(left)\|\|H(right)) so that the tree commits to the fees. Nodes can randomly check this by grabbing a random txn and checking its inputs, and compactly prove violation by showing where the fees don't match their commitments.

Line 111:		Line 111:

	* Proof of spending a non-existing input		* Proof of spending a non-existing input
	** ~~Not possible in the current system~~: proof requires scanning the entire blockchain history		** Requires additional data: proof requires scanning the entire blockchain history
	** Requires a UXTO set commitment as well as a tree for outputs created and consumed within one block. Proof is a pair of tree fragments for the higher and lower records for the missing entry, and another pair for the outputs created within a block but consumed.		** Requires a UXTO set commitment as well as a tree for outputs created and consumed within one block. Proof is a pair of tree fragments for the higher and lower records for the missing entry, and another pair for the outputs created within a block but consumed.

Gmaxwell: /* Fee tweaks */

2014-04-08T19:04:46Z

Fee tweaks

← Older revision		Revision as of 19:04, 8 April 2014
Line 80:		Line 80:

	===Fee tweaks===		===Fee tweaks===
	*Consider net unspent output change (txn which decrease the unspent outputs on the network should have fewer fees)		*<s>Consider net unspent output change (txn which decrease the unspent outputs on the network should have fewer fees)</s> (Done, not quite net change as that has some weird incentives, but some of the signature size is ignored for priority calculating purposes now)
	*NAK for dropped transactions so clients (sometimes) know when their txn aren't making progress		*NAK for dropped transactions so clients (sometimes) know when their txn aren't making progress

Gmaxwell: /* Backend security */

2014-04-08T19:03:26Z

Backend security

← Older revision		Revision as of 19:03, 8 April 2014
Line 50:		Line 50:

	===Backend security===		===Backend security===
	*scrypt wallet encryption		*<s>scrypt wallet encryption</s>
			** Removed, because I'm no longer convinced that scrypt provides a material cost increase for an attack with a amortized asic infrastructure, whos costs are power limited.
	*Network sanity checks. Trusted peers down, network very slow? don't take txn out of unconfirmed.		*Network sanity checks. Trusted peers down, network very slow? don't take txn out of unconfirmed.
	*timewarp fix		*timewarp fix
	*More DOS/network attack hardening (time skewing, memory exhaustion, etc)		*More DOS/network attack hardening (time skewing, memory exhaustion, etc)
	*Ability to mark keys as compromised and enable autosweeping of inputs that are sent to them		*Ability to mark keys as compromised and enable autosweeping of inputs that are sent to them
	*Provable notice of doublespend (when a node sees a doublespend it prepares an alert indexed by the doublespent output, including at least two spends of it, and floods it, if a client receives a such a notice for a transaction sent to it, it shoots fireworks and greatly delays showing it as confirmed)		*Provable notice of doublespend (when a node sees a doublespend it prepares an alert indexed by the doublespent output, including at least two spends of it, and floods it, if a client receives a such a notice for a transaction sent to it, it shoots fireworks and greatly delays showing it as confirmed) (in progress, [
			https://github.com/bitcoin/bitcoin/pull/3883])

	===Validation performance===		===Validation performance===

Gmaxwell: /* Core user-facing client features */

2014-04-08T19:00:51Z

Core user-facing client features

← Older revision		Revision as of 19:00, 8 April 2014
Line 6:		Line 6:
	*Multi-wallet (including watchmode wallets)		*Multi-wallet (including watchmode wallets)
	*disk corruption robust wallet storage		*disk corruption robust wallet storage
			*Memory/cpu error robust key generation (I have an implementation of SHA512 that is polarity reversed, all 1s are 0 and all 0s are 1 that could be used for comparison).
	*Peer management RPCs (<s>peer info (last connect, version, transaction stats, blocks stats) (done)</s>, add, remove)		*Peer management RPCs (<s>peer info (last connect, version, transaction stats, blocks stats) (done)</s>, add, remove)
	*<s>A pseudo-cli interface for the GUI. e.g. file->console</s> (done, 0.7.0)		*<s>A pseudo-cli interface for the GUI. e.g. file->console</s> (done, 0.7.0)
Line 17:		Line 18:

	*Show negative confirmations— how deep is the deepest conflicting transaction. Allow canceling transactions which have at least -6 (say) confirmations. Easier to do safely than general cancellation.		*Show negative confirmations— how deep is the deepest conflicting transaction. Allow canceling transactions which have at least -6 (say) confirmations. Easier to do safely than general cancellation.
			**We now have negative confirmation in Bitcoin core, but it doesn't know how deep the conflict is.

	*Async RPC		*Async RPC

Gmaxwell: /* Proofs */ link to prior discussion.

2014-04-08T18:44:40Z

Proofs: link to prior discussion.

← Older revision		Revision as of 18:44, 8 April 2014
Line 83:		Line 83:

	In general, in any deterministic computation process if you have simple state updates and commit to the sequence of states a compact proof of invalidity can be generated by producing a hash tree fragment to the first invalidate state transition.		In general, in any deterministic computation process if you have simple state updates and commit to the sequence of states a compact proof of invalidity can be generated by producing a hash tree fragment to the first invalidate state transition.

			Ideas in this space have been previously discussed under the banner of proof-of-treachery [https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601].

	Right now not all of the rules can be checked randomly or have compact proofs.		Right now not all of the rules can be checked randomly or have compact proofs.

Gmaxwell: /* Proofs */

2014-04-08T18:43:57Z

Proofs

← Older revision		Revision as of 18:43, 8 April 2014
Line 80:		Line 80:

	===Proofs===		===Proofs===
	If full nodes become expensive to operate in the future then they may become uncommon and this could compromise the security of Bitcoin. This risk can be reduced if it's made possible for Bitcoin nodes to check all the rules at random and transmit compact proofs of rule violations. If this is done even if there is only one honest full node in the world the system is secure so long as it can communicate to all others. Right now not all of the rules can be checked randomly or have compact proofs.		If full nodes become expensive to operate in the future then they may become uncommon and this could compromise the security of Bitcoin. This risk can be reduced if it's made possible for Bitcoin nodes to check all the rules at random and transmit compact proofs of rule violations. If this is done even if there is only one honest full node in the world the system is secure so long as it can communicate to all others.

			In general, in any deterministic computation process if you have simple state updates and commit to the sequence of states a compact proof of invalidity can be generated by producing a hash tree fragment to the first invalidate state transition.

			Right now not all of the rules can be checked randomly or have compact proofs.

	* SPV header checks — time, target, difficulty, already have them. But if future SPV nodes don't really check all the headers in the future it may be useful to arrange old header times in a merkle mountain range to proofs of sum difficulty and compact proofs of incorrect difficulty.		* SPV header checks — time, target, difficulty, already have them. But if future SPV nodes don't really check all the headers in the future it may be useful to arrange old header times in a merkle mountain range to proofs of sum difficulty and compact proofs of incorrect difficulty.

	* Proof of invalid script		* Proof of invalid script
	** Possible in the current system: Proof is tree fragments for the invalid txn in question as well as one invalid input (no need to include more than one). Also proves nlocktime, etc.		** Possible in the current system: Proof is tree fragments for the invalid txn in question as well as one invalid input (no need to include more than one).
			** Could be made more efficient by including commitments to intermediate states, but with the 201 opcode limit all scripts are compact to verify in Bitcoin without doing anything fancier.
			Also proves nlocktime, etc.
	** To prove output value greater than inputs all inputs must be provided in the proof.		** To prove output value greater than inputs all inputs must be provided in the proof.

Gmaxwell: /* Network layer improvements */

2013-03-24T16:33:10Z

Network layer improvements

← Older revision		Revision as of 16:33, 24 March 2013
Line 42:		Line 42:
	*<s>Peer management RPCs (peer info (last connect, version, transaction stats, blocks stats), add, remove)</s> (done, info in 0.7, management in 0.8)		*<s>Peer management RPCs (peer info (last connect, version, transaction stats, blocks stats), add, remove)</s> (done, info in 0.7, management in 0.8)
	*<s>IPv6</s> (done, 0.7.0)		*<s>IPv6</s> (done, 0.7.0)
	*Onion-cat style onion peers (~~pull semi-ready for~~ 0.7.0)		*<s>Onion-cat style onion peers</s> (done, 0.7.0)
	*Tor integration (request its own hidden service via the control port)		*Tor integration (request its own hidden service via the control port)

Gmaxwell: /* Network layer improvements */

2013-03-24T16:32:42Z

Network layer improvements

← Older revision		Revision as of 16:32, 24 March 2013
Line 40:		Line 40:
	*Priority relaying (measure which nodes are most 'useful' based on blocks/txn-w-fees then relay to them before other nodes, relay to them first— move to front on good actions probably enough)		*Priority relaying (measure which nodes are most 'useful' based on blocks/txn-w-fees then relay to them before other nodes, relay to them first— move to front on good actions probably enough)
	*Authenticated peers for addnode so a network attacker can't isolate you without your knowledge		*Authenticated peers for addnode so a network attacker can't isolate you without your knowledge
	*Peer management RPCs (peer info (last connect, version, transaction stats, blocks stats), add, remove)		*<s>Peer management RPCs (peer info (last connect, version, transaction stats, blocks stats), add, remove)</s> (done, info in 0.7, management in 0.8)
	*<s>IPv6</s> (done, 0.7.0)		*<s>IPv6</s> (done, 0.7.0)
	*Onion-cat style onion peers (pull semi-ready for 0.7.0)		*Onion-cat style onion peers (pull semi-ready for 0.7.0)

Gmaxwell: /* Proofs */

2013-03-22T05:42:56Z

Proofs

← Older revision		Revision as of 05:42, 22 March 2013
Line 86:		Line 86:
	* Proof of invalid script		* Proof of invalid script
	** Possible in the current system: Proof is tree fragments for the invalid txn in question as well as one invalid input (no need to include more than one). Also proves nlocktime, etc.		** Possible in the current system: Proof is tree fragments for the invalid txn in question as well as one invalid input (no need to include more than one). Also proves nlocktime, etc.
			** To prove output value greater than inputs all inputs must be provided in the proof.

	* Proof of double spend		* Proof of double spend

Gmaxwell: /* Proofs */ spv checks

2013-03-22T05:28:49Z

Proofs: spv checks

← Older revision		Revision as of 05:28, 22 March 2013
Line 81:		Line 81:
	===Proofs===		===Proofs===
	If full nodes become expensive to operate in the future then they may become uncommon and this could compromise the security of Bitcoin. This risk can be reduced if it's made possible for Bitcoin nodes to check all the rules at random and transmit compact proofs of rule violations. If this is done even if there is only one honest full node in the world the system is secure so long as it can communicate to all others. Right now not all of the rules can be checked randomly or have compact proofs.		If full nodes become expensive to operate in the future then they may become uncommon and this could compromise the security of Bitcoin. This risk can be reduced if it's made possible for Bitcoin nodes to check all the rules at random and transmit compact proofs of rule violations. If this is done even if there is only one honest full node in the world the system is secure so long as it can communicate to all others. Right now not all of the rules can be checked randomly or have compact proofs.

			* SPV header checks — time, target, difficulty, already have them. But if future SPV nodes don't really check all the headers in the future it may be useful to arrange old header times in a merkle mountain range to proofs of sum difficulty and compact proofs of incorrect difficulty.

	* Proof of invalid script		* Proof of invalid script