Fidelity bonds - Revision history

Kristapsk: Add info about mainnet use of fidelity bonds in JoinMarket

2022-02-18T09:30:52Z

Add info about mainnet use of fidelity bonds in JoinMarket

← Older revision		Revision as of 09:30, 18 February 2022
Line 54:		Line 54:

	The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.		The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.

			Time-Locked fidelity bonds are currently used in mainnet in [[JoinMarket]].

	== See also ==		== See also ==

Furunodo: ref description: gmaxwell on Bitcointalk: Creating Bitcoin passports using sacrifices, February 2nd 2013

2020-06-17T21:30:37Z

ref description: gmaxwell on Bitcointalk: Creating Bitcoin passports using sacrifices, February 2nd 2013

← Older revision		Revision as of 21:30, 17 June 2020
Line 13:		Line 13:
	=== Single/Consecutive Block Sacrifices ===		=== Single/Consecutive Block Sacrifices ===

	The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806]</ref>		The sacrifice can be done with transactions that pay abnormally high fees, either single such transactions, or groups of multiple ones in a row, latter intended to prevent miners themselves from creating the sacrifices and mining them in their own blocks. Problems with consecutive transaction sacrifices include the potential for gaps, as well as the large size of the proofs of the sacrifices.<ref>[https://bitcointalk.org/index.php?topic=140711.msg1498806#msg1498806 gmaxwell on Bitcointalk: Creating Bitcoin passports using sacrifices, February 2nd 2013]</ref>

	=== Announce/Commit Sacrifices ===		=== Announce/Commit Sacrifices ===

Furunodo: formatting, links, etc

2020-06-17T21:28:46Z

formatting, links, etc

Belcher: /* Temporary Fidelity Bond */ Renamed concept and section

2018-01-26T15:00:48Z

Temporary Fidelity Bond: Renamed concept and section

← Older revision		Revision as of 15:00, 26 January 2018
Line 49:		Line 49:
	Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.		Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.

	== ~~Temporary~~ Fidelity Bond ==		== Time-Locked Fidelity Bond ==

	A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and redeemScript to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin\|coinjoin]] or coinswap.		A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and redeemScript to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin\|coinjoin]] or coinswap.

Belcher: added "see also" with links to bip65 (op_cltv) and bip112 (op_csv)

2017-08-10T20:19:49Z

added "see also" with links to bip65 (op_cltv) and bip112 (op_csv)

← Older revision		Revision as of 20:19, 10 August 2017
Line 49:		Line 49:
	Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.		Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.

	==Temporary Fidelity Bond==		== Temporary Fidelity Bond ==

	A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and redeemScript to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin\|coinjoin]] or coinswap.		A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and redeemScript to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin\|coinjoin]] or coinswap.

	The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.		The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.

			== See also ==

			* [[BIP 0065]] and [[BIP 0112]]. BIPs describing the opcodes used to make time-locked addresses

	== References ==		== References ==

Belcher: added "Temporary Fidelity Bond" section and added article to Technical catagory

2017-08-10T20:15:10Z

added "Temporary Fidelity Bond" section and added article to Technical catagory

← Older revision		Revision as of 20:15, 10 August 2017
Line 48:		Line 48:

	Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.		Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.

			==Temporary Fidelity Bond==

			A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and redeemScript to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin\|coinjoin]] or coinswap.

			The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.

	== References ==		== References ==

	<references/>		<references/>

			[[Category:Technical]]

Petertodd: /* Financial Services */ history

2013-07-25T18:05:02Z

Financial Services: history

← Older revision		Revision as of 18:05, 25 July 2013
Line 47:		Line 47:
	== Financial Services ==		== Financial Services ==

	Fidelity bonds can be used to make financial fraud unprofitable. For instance ~~one early~~ proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> ~~was to use fidelity bonds~~ - called "Trusted identities" by the ~~proposal's author -~~ to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.		Fidelity bonds can be used to make financial fraud unprofitable. For instance the original fidelity bond proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> - called "Trusted identities" at that time - included the idea of using fidelity bonds to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.

	== References ==		== References ==

	<references/>		<references/>

Petertodd: /* Financial Services */ spelling

2013-07-25T18:03:02Z

Financial Services: spelling

← Older revision		Revision as of 18:03, 25 July 2013
Line 47:		Line 47:
	== Financial Services ==		== Financial Services ==

	Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposal's author - to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of ~~blacklisted~~, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.		Fidelity bonds can be used to make financial fraud unprofitable. For instance one early proposal<ref>[http://sourceforge.net/mailarchive/message.php?msg_id=29185108 Trusted identities]</ref> was to use fidelity bonds - called "Trusted identities" by the proposal's author - to create decentralized [[Green address\|green addresses]]. Someone wishing for their transactions to be accepted without confirmations would first purchase a fidelity bond of some value tied to their identity. Someone determining if they should accept a payment without confirmations can check that the bond was sufficiently expensive to make it unprofitable for the sender to commit fraud. If the sender does commit fraud by double-spending the payment, the recipient can prove that fraud to the world by providing both transactions spending the same inputs. This proof is added to some sort of blacklist, centralized or decentralized, which later recipients can consult to determine if the fidelity bond is now invalidated.

	== References ==		== References ==

	<references/>		<references/>

Petertodd: /* Coinbase TxOut Sacrifices */ note problems with midstate compression

2013-07-25T17:46:10Z

Coinbase TxOut Sacrifices: note problems with midstate compression

← Older revision		Revision as of 17:46, 25 July 2013
Line 28:		Line 28:

	Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)		Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)

			A proof for a coinbase txout is particularly short if the txout is the last txout and the script is meant to be unspendable. SHA256 midstate compression can then be used to prove the committed digest, and that the last opcode was OP_RETURN; it is not possible for a script to return true unless without the last opcode being executed. Fortunately the anyone-can-spend version can-not be proven so easily - consider the following txout fragment:

			<SHA256 midstate> <scriptPubKey length> <digest> <nLockTime>

			The problem is the fragment could actually be part of this scriptPubkey:

			<pubkey> OP_CHECKSIGVERIFY OP_PUSHDATA (<scriptPubKey length> <digest>)

			In reality this isn't a true sacrifice. The only way around this problem is if the proven data is greater than the maximum pushdata length allowed, 520 bytes, which undesirably depends on a constant whose value may be changed in a future hard-fork.

	== Passports ==		== Passports ==

Petertodd: Add Coinbase TxOut Sacrifice

2013-07-25T17:11:06Z

Add Coinbase TxOut Sacrifice

← Older revision		Revision as of 17:11, 25 July 2013
Line 24:		Line 24:

	The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)		The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)

			=== Coinbase TxOut Sacrifices ===

			Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)

	== Passports ==		== Passports ==

← Older revision		Revision as of 21:28, 17 June 2020
Line 1:		Line 1:
	A fidelity bond is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.		A '''fidelity bond''' is a proposed mechanism where Bitcoins are deliberately sacrificed to make a cryptographic identity expensive to obtain. The sacrifice is done in a way that can be proven to a third party. By making the identity expensive it can be trusted not to commit unwanted acts, such as spamming message boards, or committing fraud, because upon detection of the unwanted acts the identity becomes useless, requiring the owner of the identity to purchase another one.

	== Mechanism ==		== Mechanism ==
Line 5:		Line 5:
	The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.		The core of the fidelity bond is the sacrifice - the mechanism by which Bitcoins are provably taken from their original owner. The Bitcoins may be given to someone else or destroyed, but regardless it must not be possible for their original owner to regain control of them.

	An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a scriptPubKey that is [[Script#Provably_Unspendable.2FPrunable_Outputs\|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.		An effective form of sacrifice is to simply create a transaction assigning the coins to an unspendable output, either an address known to not have a corresponding secret key, or to a <tt>scriptPubKey</tt> that is [[Script#Provably_Unspendable.2FPrunable_Outputs\|provably unspendable]]. The Bitcoins are removed from circulation forever, a criticism of this mechanism.

	The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.		The Bitcoins can also be donated to a third party, such as a charity, however such donations can be controversial, allow the charity itself (or anyone with access to their funds) to purchase bonds at little or no cost, pose the problem of verifying the bonds validity in the future should the chosen charity(s) change, and finally, pose the problem of coming to a consensus on the charities themselves.

	In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of transaction fees.		In the context of Bitcoin, miners have been proposed as a third party whom any Bitcoin user can agree should receive funds, as miners act to secure the network from attack for everyone. The value is sacrificed to miners in the form of [[Miner fees\|transaction fees]].

	=== Single/Consecutive Block Sacrifices ===		=== Single/Consecutive Block Sacrifices ===
Line 17:		Line 17:
	=== Announce/Commit Sacrifices ===		=== Announce/Commit Sacrifices ===

	To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs\|Anyone-Can-Spend Output]]. With [[nLockTime]] the transaction is made invalid until some time in the future.		To ensure that the miner collecting the sacrificed Bitcoin is picked at random the announce/commit sacrifice was proposed.<ref>[https://bitcointalk.org/index.php?topic=134827.0 Purchasing fidelity bonds by provably throwing away bitcoins]</ref> First a sacrifice transaction is prepared that either sacrifices value to transaction fees, or spends coins to an [[Script#Anyone-Can-Spend_Outputs\|Anyone-Can-Spend Output]]. With <tt>[[nLockTime]]</tt> the transaction is made invalid until some time in the future.

	The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs\|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.		The second step is the announcement. The transaction is enclosed in another transaction as data, for instance by using a [[Script#Provably_Unspendable.2FPrunable_Outputs\|prunable output]]. The announcement is then broadcast and is included in the blockchain, proving that anyone could have seen the inner transaction prior to it becoming valid.

	Finally the inner transaction becomes valid when the [[nLockTime]] is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.		Finally the inner transaction becomes valid when the <tt>nLockTime</tt> is reached. Because mining is a random process, any miner can collect the value sacrified, and the purchaser of the fidelity bond has no control over where that value goes.

	The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)		The proof of the sacrifice is then two transactions: the proof the announcement transaction exists in the chain, and the proof that the inner sacrifice exists in the chain. (possibly with proof of the inner sacrifice inputs to prove what fees were actually paid)

	=== Coinbase TxOut Sacrifices ===		=== Coinbase <tt>TxOut</tt> Sacrifices ===

	Coinbase transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (or have someone else do so on their behalf)		[[Coinbase]] transactions are unique in that they can't be spent for 100 blocks, thus solving the problem of proving a transaction output was made public prior to it being possible to spend that output in a single transaction. In addition coinbase transactions can be created anonymously without linking the transaction to any other transaction provided that the creator has the ability to mine anonymously. (Or have someone else do so on their behalf.)

	A proof for a coinbase txout is particularly short if the txout is the last txout and the script is meant to be unspendable. SHA256 midstate compression can then be used to prove the committed digest, and that the last opcode was OP_RETURN; it is not possible for a script to return true unless without the last opcode being executed. Fortunately the anyone-can-spend version can-not be proven so easily - consider the following txout fragment:		A proof for a coinbase [[Protocol_documentation#tx\|txout]] is particularly short if the txout is the last txout and the script is meant to be unspendable. SHA256 midstate compression can then be used to prove the committed digest, and that the last opcode was <tt>OP_RETURN</tt>; it is not possible for a script to return true unless without the last opcode being executed. Fortunately the anyone-can-spend version can-not be proven so easily - consider the following txout fragment:

	<SHA256 midstate> <scriptPubKey length> <digest> <nLockTime>		<SHA256 midstate> <scriptPubKey length> <digest> <nLockTime>
Line 41:		Line 41:
	== Passports ==		== Passports ==

	This wiki combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.		[[Bitcoin Wiki:About\|This wiki]] combats spam, while still allowing for users to sign up anonymously, by requiring users to pay a small amount of Bitcoins to the wiki before editing privileges are granted. Creating large numbers of "sock-puppets" to add spam content to articles is thus made expensive. The fee approach can be generalized with the concept of a Passport, first proposed by Mike Hearn,<ref>[https://bitcointalk.org/index.php?topic=140711.0 Creating Bitcoin passports using sacrifices]</ref> tied to the users identity. Wikis, forums, webmail and other services can then create blacklists of users who violate the rules of the services, with those blacklists tied to passports.

	The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.		The advantage of fidelity bonds in that application over simply charging fees is re-usability of an identity across multiple services, as well as the neutrality: if the value required to create the passport provably does not go to the person adding the passport to a blacklist, there is no incentive to do so to collect new sign-up fees.
Line 51:		Line 51:
	== Time-Locked Fidelity Bond ==		== Time-Locked Fidelity Bond ==

	A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and redeemScript to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin~~\|coinjoin~~]] or ~~coinswap~~.		A related concept which uses time-locked bitcoins to prove a sacrifice. The purchaser of the fidelity bond sends bitcoins to a time-locked address and can reveal the UTXO and <tt>redeemScript</tt> to prove the sacrifice. The thing being sacrificed here is time rather than money (although because of the time-value-of-money they are somewhat related). This idea may be particularly useful for creating a cost to deliberately DOS interactive protocols like [[CoinJoin]] or [[CoinSwap]].

	The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.		The lock-time can be chosen to be far enough in the future to provide a suitable cost. Note that from the point of view of an investor of many bitcoins, they can purchase bonds for nearly-free because they intend to hold their bitcoins for a very long time anyway. Although presumably a long-term bitcoin investor won't want to DOS coinjoin protocols that make bitcoin more private and fungible, as that would hurt the value of their own investment coins.