https://en.bitcoin.it/w/api.php?action=feedcontributions&user=Mike&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T17:47:05ZUser contributionsMediaWiki 1.30.0https://en.bitcoin.it/w/index.php?title=Scalability&diff=58839Scalability2015-09-18T22:28:39Z<p>Mike: </p>
<hr />
<div>The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).<br />
<br />
''Please note that this page exists to give calculations about the scalability of the Bitcoin protocol and transactions on the block chain. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that.''<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [http://usa.visa.com/about-visa/our-business/visa-transaction.js] however they never actually use more than about a third of this even during peak shopping periods. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]<br />
<br />
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [https://www.paypal-media.com/about]<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.<br />
<br />
===CPU===<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some [[ECDSA]] signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2015 the network is handling 1.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.<br />
<br />
===Network===<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
===Storage===<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the UTXO set never becomes a serious bottleneck.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).<br />
<br />
At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.<br />
<br />
===Simplified payment verification===<br />
<!-- "Simplified payment verification" redirects here. Update the redirect if you change the section title --><br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
== Related work ==<br />
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.<br />
<br />
* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"<br />
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.<br />
* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which payment hubs set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with hubs.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Scalability&diff=58838Scalability2015-09-18T22:28:24Z<p>Mike: Move mention of Lightning Network to the end, delete material that isn't related to raw calculations about the existing protocol. This page is not meant to summarise the entire block size debate</p>
<hr />
<div>The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this).<br />
<br />
_Please note that this page exists to give calculations about the scalability of the Bitcoin protocol and transactions on the block chain. It is not intended to discuss the scalability of alternative protocols or try and summarise philosophical debates. Create alternative pages if you want to do that._<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [http://usa.visa.com/about-visa/our-business/visa-transaction.js] however they never actually use more than about a third of this even during peak shopping periods. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]<br />
<br />
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [https://www.paypal-media.com/about]<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.<br />
<br />
===CPU===<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some [[ECDSA]] signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2015 the network is handling 1.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.<br />
<br />
===Network===<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
===Storage===<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. Once hard disks are phased out in favour of SSDs, it is quite possible that access to the UTXO set never becomes a serious bottleneck.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).<br />
<br />
At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.<br />
<br />
===Simplified payment verification===<br />
<!-- "Simplified payment verification" redirects here. Update the redirect if you change the section title --><br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
== Related work ==<br />
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.<br />
<br />
* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"<br />
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.<br />
* [https://lightning.network/ Lightning Network], an alternative protocol for transaction clearance in which payment hubs set up micropayment channels between each other and settle up on the block chain occasionally. Ordinary users interact primarily or only with hubs.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Scalability&diff=54021Scalability2015-01-31T17:17:06Z<p>Mike: Some fixes: remove comment that implies running on desktop is defined by the white paper as a core principle (no such statement exists in the paper), and correct a misunderstanding of the VISA press release</p>
<hr />
<div>The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to more powerful backbone nodes is capable of scaling to millions of users and tens of thousands of transactions per second.<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 47,000 transactions per second, however they never actually use more than about a third of this even during peak shopping periods. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]<br />
<br />
PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [https://www.paypal-media.com/about]<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
==Current bottlenecks==<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.<br />
<br />
==CPU==<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.<br />
<br />
==Network==<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
==Storage==<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).<br />
<br />
At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.<br />
<br />
===Simplified payment verification===<br />
<!-- "Simplified payment verification" redirects here. Update the redirect if you change the section title --><br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
== Related work ==<br />
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.<br />
<br />
* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"<br />
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Address_reuse&diff=53856Address reuse2015-01-19T18:56:26Z<p>Mike: Remove bitcoinj as a notable offender - it is now BIP32/HD based since the last release and wallets that still reuse addresses should upgrade soon</p>
<hr />
<div>Address reuse is the practice of sending multiple transactions to the same address.<br />
This works by "accident", not by design.<br />
It is considered a bad practice, and not something that should be done.<br />
<br />
== Problems ==<br />
=== Privacy ===<br />
Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction.<br />
In some cases, these risks are serious enough that they are likely in violation of reasonable consumer protection laws.<br />
<br />
=== Security ===<br />
Bitcoin does not, at a low level, have any concept of addresses, only individual coins.<br />
Address reuse, at this layer, requires producing multiple digital signatures when you spend bitcoins.<br />
Multiple situations have been found where more than one digital signature can be used to calculate the private key needed to spend bitcoins.<br />
Even if you spend all the bitcoins claimed by this private key at once, it is still possible to double-spend them in theft before they confirm.<br />
While the situations for finding the private key from signatures have been fixed, it is not prudent to assume there aren't more such situations yet unknown.<br />
<br />
In the case of spending all the TXOs in a single transaction, there is an additional risk if someone is actively monitoring the network for vulnerable transactions:<br />
upon receiving such a transaction, they can split up their double spends such that there is only one ECDSA verification per transaction (making a single transaction for each TXO);<br />
this will cause the attacker's transactions to relay across the rest of the nodes ''faster'' than the legitimate one, increasing success of a double spend.<br />
<br />
==== Known attacks ====<br />
<br />
* Same K in multiple signatures, see [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html Recovering Bitcoin private keys using weak signatures from the blockchain].<br />
* [https://eprint.iacr.org/2014/140.pdf Timing sidechannel]<br />
<br />
=== Accidental loss ===<br />
In Bitcoin abstraction, an address is an invoice for a specific payment.<br />
Once that payment is made, the receiving party has no reason to retain the data for the address (technical details simplified) and may discard it.<br />
Even if someone does not choose to discard that data, it may have since been lost in an accident or compromised.<br />
In any of these situations, any future payments to the same address would go in to a "black hole", and be forever lost through no fault of the recipient.<br />
<br />
=== Confusion ===<br />
Users who see addresses reused may incorrectly be led to believe they function similarly to wallets or bank accounts.<br />
Often this is manifested in people talking about nonsense like "[[Address#Address_balances|address balance]]", "wallet address", "[[From_address|from address]]", and similar [[Address#Misconceptions|misconceptions]] that don't actually exist in Bitcoin.<br />
<br />
== Notable offenders ==<br />
Some notable Bitcoin software and services encourage or require address reuse:<br />
* Many bitcoin mining pools (especially [[Eligius]])<br />
* Electrum displays addresses in a way that encourages confusion and address reuse and misuse.</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=47608Contract2014-05-25T09:33:44Z<p>Mike: </p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
The [http://earlytemple.com/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=47564Contract2014-05-24T13:56:34Z<p>Mike: </p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
The [https://earlytemple.com/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Zero_Knowledge_Contingent_Payment&diff=47093Zero Knowledge Contingent Payment2014-05-07T13:15:09Z<p>Mike: /* Zero knowledge proof to binding */ fix link</p>
<hr />
<div><br />
It's possible to make payments using Bitcoin which are released if and only if some knowledge is disclosed by the payee and to do this in a trustless manner where neither the payer or payee can cheat. This is accomplished using the combination of a hash-locked transaction and a bitcoin-external protocol to set things up so that the data revealed in the hashlock release is the data they need.<br />
<br />
==Protocol outline==<br />
===Hash locked transactions===<br />
<br />
Its possible to author a payment in the existing Bitcoin system that requires the redeemer to provide a "secret" which hashes to a specified value. [https://blockexplorer.com/tx/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e The 0.01 output here with the SHA256 opcode] is an example of such a transaction. "To collect these funds your transaction must provide a value that hashes to this other value."<br />
<br />
Used directly, like in the above example, this is insecure: Once you've published the spending transaction another node could just drop your transaction and use the password in a new transaction that pays him instead.<br />
<br />
So— the advice is that you shouldn't use a password alone, you should require a signature and a password. But then what is the use of that?<br />
<br />
There are a couple uses but I'll give an example here of one of the more impressive and and far-out ones:<br />
<br />
===Zero knowledge proof to binding=== <br />
<br />
Let H() be a complicated computer program. For some H(X)=Y you want to know some X that gives you a particular Y.<br />
<br />
Say I happen to _know_ some X that answers your question... and I'd like to sell it to you. But we don't trust each other at all, and because we're computer geeks we have no friends who can act as trusted mediators. Can we make this exchange using Bitcoin with zero trust? The answer turns out to be yes.<br />
<br />
Here are some examples of what H() could be:<br />
<br />
* H() could be a password hashing algorithm and you're looking for the password that gives you a particular hash in order to crack it.<br />
* Perhaps H() is a complicated program that decides if a piece of music is one you would find beautiful (i.e. Y is a true/false output)<br />
* H() could be a program that verifies possession of a valid [http://en.wikipedia.org/wiki/Biometric_passport machine readable travel document] issued to a particular person. In this case, you would be able to define a payment to someone based on some arbitrary attributes about them, such as their name + date of birth, or perhaps by providing a photo of their face that's then matched against the travel document using the Eigenfaces algorithm. There would be no need to obtain a public key from them ahead of time meaning that, for example, you could send money to someone who was only just born and doesn't yet have a wallet.<br />
* H() could be a program that interprets another program on some secret input and yields true if the input data manages to put the program into a corrupted state. This would allow security researchers to sell exploits to software developers so they can be fixed, but in an anonymous and low trust way.<br />
<br />
A [https://en.wikipedia.org/wiki/Zero-knowledge_proof zero-knowledge proof] lets someone prove a mathematical fact to another person without teaching them anything about the fact itself. It has been proven that you can convert any computer program into a zero-knowledge proof (this is referred to mathematically as [http://en.wikipedia.org/wiki/IP_%28complexity%29#PSPACE_is_a_subset_of_IP PSPACE⊂IP] <!-- IIRC there is a better more direct statement about this someplace but I forget what to look for, please provide a better link -->). So, using a zero-knowledge proof I could prove to you that I know some X such that H(X)=Y ... which is helpful but it's not enough because you could pay me and I could not tell you the answer (or I could tell you and then you don't pay). Here is where the password locked transactions come in.<br />
<br />
First I encrypt X with random key K, Ex=AES(X,K).<br />
then I construct the program:<br />
<br />
<pre><br />
Program(K,Ex,H()) => [Ex,Hk,Y] {<br />
Hk=SHA256(K);<br />
Y=H(UNAES(Ex,K));<br />
return [Ex,Hk,Y];<br />
}<br />
</pre><br />
<br />
In English: The program takes the encrypted solution and the key to decrypt it, and outputs the encrypted solution, the hash of the decryption key, and the result of running the program on the solution.<br />
<br />
I convert that program into a zero knowledge proof. Externally to Bitcoin I tell you Ex,Hk,Y and then prove that I executed the program faithfully.<br />
<br />
You then form a Bitcoin payment which requires both my public key and password K. In order to redeem this transaction I must disclose K, the key you need to decrypt Ex and give you your solution. So neither of us can cheat, so no trust is required.<br />
<br />
The reason this isn't something people are using yet is because while the academics have proven it to be possible, actually converting complicated programs like compositions of ciphers and hash-functions into zero-knowledge proofs with useful levels of performance currently requires toolkits that are not yet publicly available. However, the [http://scipr-lab.org/ SCIPR Lab team] have claimed they will open source their software some time in 2014. "[http://eccc.hpi-web.de/report/2013/165/download/ Verifying computations without reexecuting them: from theoretical possibility to near practicality]" is a good paper that gives an overview of progress fo far.<br />
<br />
==But what if they're just anti-social and don't redeem the txn?==<br />
<br />
If you're concerned that they might rather leave the funds unspent rather than disclose their password, perhaps an effort to extort you, you could construct the payment so that it can alternatively be spent by a "refund transaction" which has a signature from both you and the other party.<br />
<br />
You first create the ZKP payment transaction which requires (Password+Their_signature) OR (Their signature plus Your signature). You keep this transaction private. You then write a new transaction, the refund transaction, which spends the payment back to you but has an nlocktime set in the future (e.g. 1000 blocks from now). You sign it, and give it to the other party to sign. He is able to sign it without actually seeing the payment transaction (he only sees its hash). When he returns it, you then release the payment transaction. If he does not redeem the payment transaction before the locktime expires you transmit the refund and recover it yourself. Because of the locktime you are unable to steal the payment back right after sending it to him.<br />
<br />
Alternatively, you could construct the payment as an anyone can pay transaction where the output is greater than the input you provide. You would give him this transaction, then he would add funds of his own and announce it and wait for it to be mined before announcing the key in the transaction spending it. This way he could not lock up your funds without locking up funds of his own.<br />
<br />
==Improving privacy==<br />
A ZK-payment can be transformed using the [https://bitcointalk.org/index.php?topic=321228.0 CoinSwap] approach where they payer first pays into an ordinary 2-of-2 escrow+refund with the payee. The then would perform the ZK-payment transactions described above externally to the Bitcoin network, and if everything goes through without cheating the payer just signs a 2-of-2 release to pay the payee directly, without disclosing to the network that a hashlocked transaction was used. If the payer fails to release the escrow directly, the payee can just release it by announcing the hashlock and hashlock redeem.</div>Mikehttps://en.bitcoin.it/w/index.php?title=Zero_Knowledge_Contingent_Payment&diff=47092Zero Knowledge Contingent Payment2014-05-07T13:13:49Z<p>Mike: /* Zero knowledge proof to binding */ Add more examples of what H() could be. Fold practicality update at the end of the page into main text.</p>
<hr />
<div><br />
It's possible to make payments using Bitcoin which are released if and only if some knowledge is disclosed by the payee and to do this in a trustless manner where neither the payer or payee can cheat. This is accomplished using the combination of a hash-locked transaction and a bitcoin-external protocol to set things up so that the data revealed in the hashlock release is the data they need.<br />
<br />
==Protocol outline==<br />
===Hash locked transactions===<br />
<br />
Its possible to author a payment in the existing Bitcoin system that requires the redeemer to provide a "secret" which hashes to a specified value. [https://blockexplorer.com/tx/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e The 0.01 output here with the SHA256 opcode] is an example of such a transaction. "To collect these funds your transaction must provide a value that hashes to this other value."<br />
<br />
Used directly, like in the above example, this is insecure: Once you've published the spending transaction another node could just drop your transaction and use the password in a new transaction that pays him instead.<br />
<br />
So— the advice is that you shouldn't use a password alone, you should require a signature and a password. But then what is the use of that?<br />
<br />
There are a couple uses but I'll give an example here of one of the more impressive and and far-out ones:<br />
<br />
===Zero knowledge proof to binding=== <br />
<br />
Let H() be a complicated computer program. For some H(X)=Y you want to know some X that gives you a particular Y.<br />
<br />
Say I happen to _know_ some X that answers your question... and I'd like to sell it to you. But we don't trust each other at all, and because we're computer geeks we have no friends who can act as trusted mediators. Can we make this exchange using Bitcoin with zero trust? The answer turns out to be yes.<br />
<br />
Here are some examples of what H() could be:<br />
<br />
* H() could be a password hashing algorithm and you're looking for the password that gives you a particular hash in order to crack it.<br />
* Perhaps H() is a complicated program that decides if a piece of music is one you would find beautiful (i.e. Y is a true/false output)<br />
* H() could be a program that verifies possession of a valid [http://en.wikipedia.org/wiki/Machine-readable_passport machine readable travel document] issued to a particular person. In this case, you would be able to define a payment to someone based on some arbitrary attributes about them, such as their name + date of birth, or perhaps by providing a photo of their face that's then matched against the travel document using the Eigenfaces algorithm. There would be no need to obtain a public key from them ahead of time meaning that, for example, you could send money to someone who was only just born and doesn't yet have a wallet.<br />
* H() could be a program that interprets another program on some secret input and yields true if the input data manages to put the program into a corrupted state. This would allow security researchers to sell exploits to software developers so they can be fixed, but in an anonymous and low trust way.<br />
<br />
A [https://en.wikipedia.org/wiki/Zero-knowledge_proof zero-knowledge proof] lets someone prove a mathematical fact to another person without teaching them anything about the fact itself. It has been proven that you can convert any computer program into a zero-knowledge proof (this is referred to mathematically as [http://en.wikipedia.org/wiki/IP_%28complexity%29#PSPACE_is_a_subset_of_IP PSPACE⊂IP] <!-- IIRC there is a better more direct statement about this someplace but I forget what to look for, please provide a better link -->). So, using a zero-knowledge proof I could prove to you that I know some X such that H(X)=Y ... which is helpful but it's not enough because you could pay me and I could not tell you the answer (or I could tell you and then you don't pay). Here is where the password locked transactions come in.<br />
<br />
First I encrypt X with random key K, Ex=AES(X,K).<br />
then I construct the program:<br />
<br />
<pre><br />
Program(K,Ex,H()) => [Ex,Hk,Y] {<br />
Hk=SHA256(K);<br />
Y=H(UNAES(Ex,K));<br />
return [Ex,Hk,Y];<br />
}<br />
</pre><br />
<br />
In English: The program takes the encrypted solution and the key to decrypt it, and outputs the encrypted solution, the hash of the decryption key, and the result of running the program on the solution.<br />
<br />
I convert that program into a zero knowledge proof. Externally to Bitcoin I tell you Ex,Hk,Y and then prove that I executed the program faithfully.<br />
<br />
You then form a Bitcoin payment which requires both my public key and password K. In order to redeem this transaction I must disclose K, the key you need to decrypt Ex and give you your solution. So neither of us can cheat, so no trust is required.<br />
<br />
The reason this isn't something people are using yet is because while the academics have proven it to be possible, actually converting complicated programs like compositions of ciphers and hash-functions into zero-knowledge proofs with useful levels of performance currently requires toolkits that are not yet publicly available. However, the [http://scipr-lab.org/ SCIPR Lab team] have claimed they will open source their software some time in 2014. "[http://eccc.hpi-web.de/report/2013/165/download/ Verifying computations without reexecuting them: from theoretical possibility to near practicality]" is a good paper that gives an overview of progress fo far.<br />
<br />
==But what if they're just anti-social and don't redeem the txn?==<br />
<br />
If you're concerned that they might rather leave the funds unspent rather than disclose their password, perhaps an effort to extort you, you could construct the payment so that it can alternatively be spent by a "refund transaction" which has a signature from both you and the other party.<br />
<br />
You first create the ZKP payment transaction which requires (Password+Their_signature) OR (Their signature plus Your signature). You keep this transaction private. You then write a new transaction, the refund transaction, which spends the payment back to you but has an nlocktime set in the future (e.g. 1000 blocks from now). You sign it, and give it to the other party to sign. He is able to sign it without actually seeing the payment transaction (he only sees its hash). When he returns it, you then release the payment transaction. If he does not redeem the payment transaction before the locktime expires you transmit the refund and recover it yourself. Because of the locktime you are unable to steal the payment back right after sending it to him.<br />
<br />
Alternatively, you could construct the payment as an anyone can pay transaction where the output is greater than the input you provide. You would give him this transaction, then he would add funds of his own and announce it and wait for it to be mined before announcing the key in the transaction spending it. This way he could not lock up your funds without locking up funds of his own.<br />
<br />
==Improving privacy==<br />
A ZK-payment can be transformed using the [https://bitcointalk.org/index.php?topic=321228.0 CoinSwap] approach where they payer first pays into an ordinary 2-of-2 escrow+refund with the payee. The then would perform the ZK-payment transactions described above externally to the Bitcoin network, and if everything goes through without cheating the payer just signs a 2-of-2 release to pay the payee directly, without disclosing to the network that a hashlocked transaction was used. If the payer fails to release the escrow directly, the payee can just release it by announcing the hashlock and hashlock redeem.</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=47091Contract2014-05-07T13:00:54Z<p>Mike: /* Example 6: Pay-for-proof contracts: buying a solution to any pure function */ Credit Gregory Maxwell as inventor of the ZKCP protocol</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
The [https://earlytemple.com:8181/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Gregory Maxwell has invented a protocol for doing this, which you can read about here: [[Zero Knowledge Contingent Payment]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=46983Contract2014-05-04T20:39:14Z<p>Mike: Link to Early Temple.</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
The [https://earlytemple.com:8181/ ''Early Temple'' project] has implemented a prototype of an oracle that looks for a key phrase in a web page.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Read an explanation of the protocol here: [[Zero Knowledge Contingent Payment]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Scalability&diff=45172Scalability2014-03-20T13:53:27Z<p>Mike: Link to GPGPU curve25519 paper</p>
<hr />
<div>The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to more powerful backbone nodes is capable of scaling to millions of users and tens of thousands of transactions per second.<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. They have burst capacity for over 10,000 tps which they need to handle the busiest points of the holiday period (~8,500 tps). [http://investor.visa.com/phoenix.zhtml?c=215693&p=irol-newsArticle_print&ID=1355716]<br />
<br />
PayPal, in contrast, handles around 4 million transactions per day for an average of 46 tps or a probably peak rate of 100 tps.<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
==Current bottlenecks==<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps by some artificial limits. These were put in place to stop people from ballooning the size of the block chain before the network and community was ready for it. Once those limits are lifted, the maximum transaction rate will go up significantly.<br />
<br />
==CPU==<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.<br />
<br />
==Network==<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
==Storage==<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).<br />
<br />
At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.<br />
<br />
===Simplified payment verification===<br />
<!-- "Simplified payment verification" redirects here. Update the redirect if you change the section title --><br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg, you only really need to store say 5000 blocks).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
== Related work ==<br />
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.<br />
<br />
* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"<br />
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=44644Contract2014-02-26T11:22:40Z<p>Mike: /* Example 6: Pay-for-proof contracts: buying a solution to any pure function */</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Read an explanation of the protocol here: [[Zero Knowledge Contingent Payment]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Agent&diff=44179Agent2014-02-01T16:05:55Z<p>Mike: </p>
<hr />
<div>An '''agent''' is an autonomous program that is able to survive by selling services for Bitcoins, and using the proceeds to rent server capacity. Agents that are profitable enough may replicate themselves by spawning additional instances on other servers. <br />
<br />
Bitcoin-using autonomous agents were first described in a forum post by julz in 2011 and further elaborated on in that same discussion by Gregory Maxwell, who used a file storage system called StorJ as an illustrative example[https://bitcointalk.org/index.php?topic=53855.msg642768#msg642768]. Mike Hearn gave a talk on the topic at the Turing Festival 2013 ([https://www.youtube.com/watch?v=Pu4PAMFPo5Y video] and [http://www.slideshare.net/mikehearn/future-of-money-26663148 slides]). The concept has also been referred to as a "decentralised autonomous corporation" or DAC in a series of articles by Vitalik Buterin called [http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/ "Bootstrapping a decentralised autonomous corporation"].<br />
<br />
==Core concepts==<br />
<br />
Agents interact with the world via the following mechanisms:<br />
<br />
# The Bitcoin network<br />
# APIs that allow for renting server capacity, and then remotely controlling that server (ie, ssh)<br />
# Human readable contracts posted to freelancer forums or the Mechanical Turk<br />
# Their own application protocols, for example, by serving HTTP<br />
<br />
By maintaining their own balance, for the first time it becomes possible for software to exist on a level playing field to humans. It may even be that people find themselves working for the programs because they need the money, rather than programs working for the people. Being a peer rather than a tool is what distinguishes a program that uses Bitcoin from an agent.<br />
<br />
Because server capacity is sold in well defined, standardized units (CPU seconds, gigabytes of RAM/disk, megabits of bandwidth) it becomes possible for software to automatically find and negotiate with providers who accept Bitcoin.<br />
<br />
If a better deal is found, the agent can move itself. An agent that is profitable can be programmed to use some of those profits to bring up a child instance and fund it with a starter pack of coins. If the child instance is able to break even or better, it will survive, otherwise when its bank balance expires the server provider will delete the account and the agent along with it.<br />
<br />
Agents can expose their services to humans (or other agents) by selecting a name and then registering it with [[Namecoin]]. If the agent has only Bitcoins it can use peer to peer exchanges to atomically trade Bitcoins for Namecoins or vice-versa. Using DNS hierarchies and Namecoin together allows interested parties to monitor for new agents coming online: the agent of registering a name under a particular part of the tree automatically advertises its existence.<br />
<br />
Agents can improve themselves by purchasing the services of humans and using dispute mediators to give the humans some assurance the coins will be paid upon completion of the contract. A/B testing can be used to determine if the delivered work is really better than the old one or not, with the dispute mediator only releasing the coins if the results of the test are positive. For example, a redesigned user interface can be tested on 10% of all users, to see if they are more or less likely to upload/download a file. Alternatively, a quorum of dispute mediators can be specified, and they decide if the contract was met or not. New code can also be bought to increase the agents abilities.<br />
<br />
==Reliance on low trust protocols==<br />
<br />
Low trust protocols are important for agents to protect themselves against being scammed by humans. Being merely dumb programs, they cannot make nuanced trust judgements and are potentially easy to scam, for example, by offering to sell something then not actually providing it. Humans can spread the word, use courts of law and so on to try and reclaim losses when scammed, but agents cannot.<br />
<br />
The most basic agent protocol is buying server time. By resigning transactions that are not broadcast, an agent can buy server capacity by the minute or even by the second. A very simple protocol can suffice, for instance, a ~/.account-billing-details file in the home directory of the new account that contains a Bitcoin address and the prices as negotiated. The agent can read the billing details from this standardized file and proceed to pay the server operator.<br />
<br />
To evolve the agent, new code is needed, which must be written by people. To avoid humans scamming the agent and providing code that steals its wallet, the agent can use sandboxing technologies like Java or NativeClient to ensure the newly developed code only has access to what it needs. This would impose a small amount of rigidity on the agents design, but would allow truly autonomous bargaining. The agent can be programmed to trust the judgement of long-term customers: if enough of those customers review and sign the new code, it could be released from the sandbox and allowed to modify the agent in arbitrary ways. If the agent is sufficiently improved, it will outcompete its peers and reproduce more.<br />
<br />
==Examples==<br />
<br />
Consider the original example of a file storage agent. <br />
<br />
# It rents its disk and bandwidth in return for coins. Anyone who wants a file to stay online can send coins to the files Bitcoin address.<br />
# If it starts to run out of capacity, it can use some of its profits to spawn children on other hosting services. If a service has unknown reputation, the child can be monitored for a while until the parent is convinced it's operating correctly.<br />
# Nodes can register their existence with names like "x536ma.storj.bit". Any name registered under storj.bit is assumed to offer the same services.<br />
# The agents can compete on the quality of their user interfaces. <br />
# Users could pledge for incorporation of a simple file viewer interface, to supplement download ability. <br />
<br />
Whilst there are companies that provide shell accounts for Bitcoins, most don't. Server brokers are agents that simply re-sell computing capacity to other agents:<br />
<br />
# By handling the details of how to interact with providers they offer a useful service, for which agents should be willing to pay.<br />
# Brokers can purchase from humans scripts that handle signing up for accounts at new services. They can interact with exchanges to sell Bitcoin for the currencies and payment mechanisms the providers accept.<br />
# Colo providers can run a modified sshd that understands how to treat SSH keys as [[Smart Property]]. By pre-creating shell accounts with resource quotas, and then selling the access keys to brokers, brokers can easily re-sell accounts automatically in a zero trust manner using the lock time and transaction input/output features of the Bitcoin protocol. The brokers would automatically handle recruitment of customers and matching agents with servers.<br />
<br />
==Use of trusted computing/TPM chips==<br />
<br />
To be truly autonomous, an agent should need to trust nobody (and nothing). But to make a trade you often need some assurance that the other side will behave as expected. People rely on the law to enforce contracts, but agents have no such recourse. Whilst clever protocols can configure incentives to ensure co-operation in some cases, trusted computing can be used to provide this assurance in the general case. <br />
<br />
For example, agents may need some assurance that the provider of computing time will not attempt to steal the agents profits. Whilst it may be uneconomic in the long term to steal vs revenue share, it's quick and easy to make bogus offers to whatever agents are out there and wait for the money to roll in.<br />
<br />
Modern CPUs have the ability to remotely prove what code they are running, and encrypt keys such that they are only available when the hardware is in the same configuration as before. The [http://sparrow.ece.cmu.edu/group/flicker.html Flicker] project demonstrates how to achieve this on AMD and Intel CPUs running Linux for short term computations (interrupts must be disabled in their simple implementation). Breaking the security requires modification of the TPM chip, which is designed to be tamper resistant. If it is protecting sums of money that are not extremely large, this should be a sufficiently high level of difficulty to discourage fraud.<br />
<br />
To use these facilities, a child agent (that is in the process of being created by its parent) would copy its code to the remote server. At this point it has no wallet. It would then enter the protected domain, where it is isolated from the regular operating system, and execute a PAL (piece of application logic) which creates itself a private key, which is then "sealed" to the state of the CPU at that time. Upon leaving the protected domain, it is left with encrypted data that cannot be read by the (possibly malicious) host operating system. The host OS is treated as an untrusted proxy and provider of resources. <br />
<br />
The parent needs to provide its child with a small amount of money to let it get started, but how does it know its sending money truly to the child it just created and not a greedy imposter? The child can use the TPM to remotely prove it was in total control of the CPU at the time it created the private key corresponding to the provided address. The parent can verify that remote attestation and be assured it's sending money to the program it thinks it is.<br />
<br />
If the services of an agent are purchased, for example, a file is uploaded to StorJ, the accompanying payment is presented to the secure PAL, along with the merkle branch linking it into the block chain. The PAL then updates its bookkeeping so it knows it needs to pay the host more, and when the host invoices the agent, the secure PAL verifies the bill is as expected and then creates/signs a transaction that pays the bill. The transaction is passed back to the untrusted host which broadcasts it.<br />
<br />
Not all hardware supports trusted computing facilities. However, various laptops and server/desktop class PCs can be purchased that have the relevant chips. Renting such hardware to brokers might prove a profitable way to reduce the cost of a new computer purchase.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Agent&diff=44178Agent2014-02-01T16:03:33Z<p>Mike: Add credit for julz and link to vitalik's articles</p>
<hr />
<div>An '''agent''' is an autonomous program that is able to survive by selling services for Bitcoins, and using the proceeds to rent server capacity. Agents that are profitable enough may replicate themselves by spawning additional instances on other servers. <br />
<br />
Bitcoin-using autonomous agents were first described by julz and Gregory Maxwell, who used a file storage system called StorJ as an illustrative example[https://bitcointalk.org/index.php?topic=53855.msg642768#msg642768]. Mike Hearn gave a talk on the topic at the Turing Festival 2013 ([https://www.youtube.com/watch?v=Pu4PAMFPo5Y video] and [http://www.slideshare.net/mikehearn/future-of-money-26663148 slides]). The concept has also been referred to as a "decentralised autonomous corporation" or DAC in a series of articles by Vitalik Buterin called [http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/ "Bootstrapping a decentralised autonomous corporation"].<br />
<br />
==Core concepts==<br />
<br />
Agents interact with the world via the following mechanisms:<br />
<br />
# The Bitcoin network<br />
# APIs that allow for renting server capacity, and then remotely controlling that server (ie, ssh)<br />
# Human readable contracts posted to freelancer forums or the Mechanical Turk<br />
# Their own application protocols, for example, by serving HTTP<br />
<br />
By maintaining their own balance, for the first time it becomes possible for software to exist on a level playing field to humans. It may even be that people find themselves working for the programs because they need the money, rather than programs working for the people. Being a peer rather than a tool is what distinguishes a program that uses Bitcoin from an agent.<br />
<br />
Because server capacity is sold in well defined, standardized units (CPU seconds, gigabytes of RAM/disk, megabits of bandwidth) it becomes possible for software to automatically find and negotiate with providers who accept Bitcoin.<br />
<br />
If a better deal is found, the agent can move itself. An agent that is profitable can be programmed to use some of those profits to bring up a child instance and fund it with a starter pack of coins. If the child instance is able to break even or better, it will survive, otherwise when its bank balance expires the server provider will delete the account and the agent along with it.<br />
<br />
Agents can expose their services to humans (or other agents) by selecting a name and then registering it with [[Namecoin]]. If the agent has only Bitcoins it can use peer to peer exchanges to atomically trade Bitcoins for Namecoins or vice-versa. Using DNS hierarchies and Namecoin together allows interested parties to monitor for new agents coming online: the agent of registering a name under a particular part of the tree automatically advertises its existence.<br />
<br />
Agents can improve themselves by purchasing the services of humans and using dispute mediators to give the humans some assurance the coins will be paid upon completion of the contract. A/B testing can be used to determine if the delivered work is really better than the old one or not, with the dispute mediator only releasing the coins if the results of the test are positive. For example, a redesigned user interface can be tested on 10% of all users, to see if they are more or less likely to upload/download a file. Alternatively, a quorum of dispute mediators can be specified, and they decide if the contract was met or not. New code can also be bought to increase the agents abilities.<br />
<br />
==Reliance on low trust protocols==<br />
<br />
Low trust protocols are important for agents to protect themselves against being scammed by humans. Being merely dumb programs, they cannot make nuanced trust judgements and are potentially easy to scam, for example, by offering to sell something then not actually providing it. Humans can spread the word, use courts of law and so on to try and reclaim losses when scammed, but agents cannot.<br />
<br />
The most basic agent protocol is buying server time. By resigning transactions that are not broadcast, an agent can buy server capacity by the minute or even by the second. A very simple protocol can suffice, for instance, a ~/.account-billing-details file in the home directory of the new account that contains a Bitcoin address and the prices as negotiated. The agent can read the billing details from this standardized file and proceed to pay the server operator.<br />
<br />
To evolve the agent, new code is needed, which must be written by people. To avoid humans scamming the agent and providing code that steals its wallet, the agent can use sandboxing technologies like Java or NativeClient to ensure the newly developed code only has access to what it needs. This would impose a small amount of rigidity on the agents design, but would allow truly autonomous bargaining. The agent can be programmed to trust the judgement of long-term customers: if enough of those customers review and sign the new code, it could be released from the sandbox and allowed to modify the agent in arbitrary ways. If the agent is sufficiently improved, it will outcompete its peers and reproduce more.<br />
<br />
==Examples==<br />
<br />
Consider the original example of a file storage agent. <br />
<br />
# It rents its disk and bandwidth in return for coins. Anyone who wants a file to stay online can send coins to the files Bitcoin address.<br />
# If it starts to run out of capacity, it can use some of its profits to spawn children on other hosting services. If a service has unknown reputation, the child can be monitored for a while until the parent is convinced it's operating correctly.<br />
# Nodes can register their existence with names like "x536ma.storj.bit". Any name registered under storj.bit is assumed to offer the same services.<br />
# The agents can compete on the quality of their user interfaces. <br />
# Users could pledge for incorporation of a simple file viewer interface, to supplement download ability. <br />
<br />
Whilst there are companies that provide shell accounts for Bitcoins, most don't. Server brokers are agents that simply re-sell computing capacity to other agents:<br />
<br />
# By handling the details of how to interact with providers they offer a useful service, for which agents should be willing to pay.<br />
# Brokers can purchase from humans scripts that handle signing up for accounts at new services. They can interact with exchanges to sell Bitcoin for the currencies and payment mechanisms the providers accept.<br />
# Colo providers can run a modified sshd that understands how to treat SSH keys as [[Smart Property]]. By pre-creating shell accounts with resource quotas, and then selling the access keys to brokers, brokers can easily re-sell accounts automatically in a zero trust manner using the lock time and transaction input/output features of the Bitcoin protocol. The brokers would automatically handle recruitment of customers and matching agents with servers.<br />
<br />
==Use of trusted computing/TPM chips==<br />
<br />
To be truly autonomous, an agent should need to trust nobody (and nothing). But to make a trade you often need some assurance that the other side will behave as expected. People rely on the law to enforce contracts, but agents have no such recourse. Whilst clever protocols can configure incentives to ensure co-operation in some cases, trusted computing can be used to provide this assurance in the general case. <br />
<br />
For example, agents may need some assurance that the provider of computing time will not attempt to steal the agents profits. Whilst it may be uneconomic in the long term to steal vs revenue share, it's quick and easy to make bogus offers to whatever agents are out there and wait for the money to roll in.<br />
<br />
Modern CPUs have the ability to remotely prove what code they are running, and encrypt keys such that they are only available when the hardware is in the same configuration as before. The [http://sparrow.ece.cmu.edu/group/flicker.html Flicker] project demonstrates how to achieve this on AMD and Intel CPUs running Linux for short term computations (interrupts must be disabled in their simple implementation). Breaking the security requires modification of the TPM chip, which is designed to be tamper resistant. If it is protecting sums of money that are not extremely large, this should be a sufficiently high level of difficulty to discourage fraud.<br />
<br />
To use these facilities, a child agent (that is in the process of being created by its parent) would copy its code to the remote server. At this point it has no wallet. It would then enter the protected domain, where it is isolated from the regular operating system, and execute a PAL (piece of application logic) which creates itself a private key, which is then "sealed" to the state of the CPU at that time. Upon leaving the protected domain, it is left with encrypted data that cannot be read by the (possibly malicious) host operating system. The host OS is treated as an untrusted proxy and provider of resources. <br />
<br />
The parent needs to provide its child with a small amount of money to let it get started, but how does it know its sending money truly to the child it just created and not a greedy imposter? The child can use the TPM to remotely prove it was in total control of the CPU at the time it created the private key corresponding to the provided address. The parent can verify that remote attestation and be assured it's sending money to the program it thinks it is.<br />
<br />
If the services of an agent are purchased, for example, a file is uploaded to StorJ, the accompanying payment is presented to the secure PAL, along with the merkle branch linking it into the block chain. The PAL then updates its bookkeeping so it knows it needs to pay the host more, and when the host invoices the agent, the secure PAL verifies the bill is as expected and then creates/signs a transaction that pays the bill. The transaction is passed back to the untrusted host which broadcasts it.<br />
<br />
Not all hardware supports trusted computing facilities. However, various laptops and server/desktop class PCs can be purchased that have the relevant chips. Renting such hardware to brokers might prove a profitable way to reduce the cost of a new computer purchase.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=43733Contract2014-01-14T11:15:34Z<p>Mike: /* A warning about the mempool transaction replacement mechanism */ Remove the editorialising</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==A warning about the mempool transaction replacement mechanism==<br />
<br />
In places this page refers to the ability to use the nSequence field for transaction mempool replacement. This mechanism was disabled in [https://github.com/bitcoin/bitcoin/commit/401926283a200994ecd7df8eae8ced8e0b067c46 2010], and more recently the code has been [https://github.com/bitcoin/bitcoin/commit/98c7c8fd1d3712e02be0e9f2eeca7e02aa54d197 removed completely], due to concerns over people using it to perform DoS attacks. Implementors should take this into account and try to create contract mechanisms that do not rely on mempool replacement if they wish to have their implementations work with current implementations. If Bitcoin changes in future to allow mempool replacement once again, this page will be updated.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Read an explanation of the protocol here: [[User:Gmaxwell/why_hash_locked]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Zero_Knowledge_Contingent_Payment&diff=42871Zero Knowledge Contingent Payment2013-12-04T16:03:10Z<p>Mike: /* Zero nowledge proof to binding */</p>
<hr />
<div><br />
It's possible to make payments using Bitcoin which are released if and only if some knowledge is disclosed by the payee and to do this in a trustless manner where neither the payer or payee can cheat. This is accomplished using the combination of a hash-locked transaction and a bitcoin-external protocol to set things up so that the data revealed in the hashlock release is the data they need.<br />
<br />
==Protocol outline==<br />
===Hash locked transactions===<br />
<br />
Its possible to author a payment in the existing Bitcoin system that requires the redeemer to provide a "secret" which hashes to a specified value. [https://blockexplorer.com/tx/9969603dca74d14d29d1d5f56b94c7872551607f8c2d6837ab9715c60721b50e The 0.01 output here with the SHA256 opcode] is an example of such a transaction. "To collect these funds your transaction must provide a value that hashes to this other value."<br />
<br />
Used directly, like in the above example, this is insecure: Once you've published the spending transaction another node could just drop your transaction and use the password in a new transaction that pays him instead.<br />
<br />
So— the advice is that you shouldn't use a password alone, you should require a signature and a password. But then what is the use of that?<br />
<br />
There are a couple uses but I'll give an example here of one of the more impressive and and far-out ones:<br />
<br />
===Zero knowledge proof to binding=== <br />
<br />
Let H() be a complicated computer program. For some H(X)=Y you want to know some X that gives you a particular Y.<br />
<br />
Perhaps H() is a password hashing algorithm and you're looking for the password that gives you a particular hash in order to crack it. Or perhaps H() is a complicated program that decides if a image is one you would find beautiful (e.g. Y is either zero or one, and you want some X where Y==1).<br />
<br />
Say I happen to _know_ some X that answers your question... and I'd like to sell it to you. But we don't trust each other at all, and because we're computer geeks we have no friends who can act as trusted mediators. Can we make this exchange using Bitcoin with zero trust? Yes.<br />
<br />
A [https://en.wikipedia.org/wiki/Zero-knowledge_proof zero-knowledge proof] lets someone prove a mathematical fact to another person without teaching them anything about the fact itself. It has been proven that you can convert any computer program into a zero-knowledge proof(e.g. [http://en.wikipedia.org/wiki/IP_%28complexity%29#PSPACE_is_a_subset_of_IP PSPACE⊂IP] <!-- IIRC there is a better more direct statement about this someplace but I forget what to look for, please provide a better link -->). So, using a zero-knowledge proof I could prove to you that I know some X such that H(X)=Y ... which is helpful but it's not enough because you could pay me and I could not tell you the answer (or I could tell you and then you don't pay). Here is where the password locked transactions come in.<br />
<br />
First I encrypt X with random key K, Ex=AES(X,K).<br />
then I construct the program:<br />
<br />
<pre><br />
Program(K,Ex,H()) => [Ex,Hk,Y] {<br />
Hk=SHA256(K);<br />
Y=H(UNAES(Ex,K));<br />
return [Ex,Hk,Y];<br />
}<br />
</pre><br />
<br />
In English: The program takes the encrypted solution and the key to decrypt it, and outputs the encrypted solution, the hash of the decryption key, and the result of running the program on the solution.<br />
<br />
I convert that program into a zero knowledge proof. Externally to Bitcoin I tell you Ex,Hk,Y and then prove that I executed the program faithfully.<br />
<br />
You then form a Bitcoin payment which requires both my public key and password K. In order to redeem this transaction I must disclose K, the key you need to decrypt Ex and give you your solution. So neither of us can cheat, so no trust is required.<br />
<br />
The reason this isn't something people are using yet is because while the academics have proven it to be possible actually converting complicated programs like compositions of ciphers and hash-functions into zero-knowledge proofs is apparently not something anyone has figured out how to do practically. ''2013 Update'': This is rapidly changing and [http://scipr-lab.org/ practical systems] now appear practically possible.<br />
<br />
==But what if they're just anti-social and don't redeem the txn?==<br />
<br />
If you're concerned that they might rather leave the funds unspent rather than disclose their password, perhaps an effort to extort you, you could construct the payment so that it can alternatively be spent by a "refund transaction" which has a signature from both you and the other party.<br />
<br />
You first create the ZKP payment transaction which requires (Password+Their_signature) OR (Their signature plus Your signature). You keep this transaction private. You then write a new transaction, the refund transaction, which spends the payment back to you but has an nlocktime set in the future (e.g. 1000 blocks from now). You sign it, and give it to the other party to sign. He is able to sign it without actually seeing the payment transaction (he only sees its hash). When he returns it, you then release the payment transaction. If he does not redeem the payment transaction before the locktime expires you transmit the refund and recover it yourself. Because of the locktime you are unable to steal the payment back right after sending it to him.<br />
<br />
Alternatively, you could construct the payment as an anyone can pay transaction where the output is greater than the input you provide. You would give him this transaction, then he would add funds of his own and announce it and wait for it to be mined before announcing the key in the transaction spending it. This way he could not lock up your funds without locking up funds of his own.<br />
<br />
==Improving privacy==<br />
A ZK-payment can be transformed using the [https://bitcointalk.org/index.php?topic=321228.0 CoinSwap] approach where they payer first pays into an ordinary 2-of-2 escrow+refund with the payee. The then would perform the ZK-payment transactions described above externally to the Bitcoin network, and if everything goes through without cheating the payer just signs a 2-of-2 release to pay the payee directly, without disclosing to the network that a hashlocked transaction was used. If the payer fails to release the escrow directly, the payee can just release it by announcing the hashlock and hashlock redeem.</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=42867Contract2013-12-04T15:43:00Z<p>Mike: Mention gmaxwells pay-for-proof scheme and the SMPC-on-bitcoin paper.</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 6: Pay-for-proof contracts: buying a solution to any pure function==<br />
<br />
In example 4, we saw how to make payments conditional on the output of some arbitrary program. Those programs are very powerful and can do anything a regular program can do, like fetching web pages. The downside is that a third party is required (an oracle). Although there are techniques that can help reduce the trust needed in the oracle, none can reduce it to zero.<br />
<br />
For a restricted class of programs, pure functions, new cryptographic techniques are starting to become available that can actually reduce the trust needed all the way to zero with no third parties. These programs cannot perform any I/O, but in many cases this restriction turns out to be unimportant or can be worked around in other ways, like by giving the program a signed/timestamped document as an input instead of having the program download it.<br />
<br />
Read an explanation of the protocol here: [[User:Gmaxwell/why_hash_locked]]<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==Example 8: Multi-party decentralised lotteries==<br />
<br />
Using some of the techniques from example 6 and some very advanced scripting, it becomes possible to build a multi-party lottery with no operator. The exact protocol used is explained in the paper [http://eprint.iacr.org/2013/784 "Secure multiparty computations on Bitcoin"]. A shorter explanation of how it works may be added to this wiki at some point in the future.<br />
<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=42864Contract2013-12-04T15:33:25Z<p>Mike: /* Trust minimization: verifiable computation */</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=42826Contract2013-12-03T00:24:41Z<p>Mike: note that micropayment channels are implemented in bcj</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: verifiable computation===<br />
<br />
Cryptographers have recently been making excellent progress in the field of '''verifiable computation'''. This allows an untrusted server to execute a pure function in which some inputs can be private, and produce a proof that it was executed correctly. If the oracle program can be expressed as a pure function, then this technique can be powerfully applied. However there are performance limits. The current best available code as of summer 2013 is [http://research.microsoft.com/pubs/180286/pinocchio.pdf Pinnochio], an open source system from Microsoft Research. The academic state of the art is [http://www.scipr-lab.org/tinyram TinyRAM], which is based on [http://www.scipr-lab.org/system/files/csnark-20130815.pdf this paper], but the code is presently unavailable. They plan to open source it at some point.<br />
<br />
For some classes of functions checking the proof can be faster than executing the program itself, for others it is still slower - however, quite within the realms of feasibility. Because the programs are pure functions, they cannot do any I/O, therefore no access to the internet. This is quite restrictive as often the point of an oracle program is to measure external state. We can work around this restriction by providing signed data to the program and have the program itself check the signatures - to make it as easy as possible to get signed data from as many sources as possible, an extension to the SSL/TLS protocol that allows for signing of arbitrary sessions may be appropriate.<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
This protocol has [https://code.google.com/p/bitcoinj/wiki/WorkingWithMicropayments been implemented in bitcoinj].<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=42717Contract2013-11-28T10:34:27Z<p>Mike: Mention the SSL logs and AWS oracles work. Also update the language about verifiable computation.</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Trust minimization: challenges===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
===Trust minimization: multiple independent oracles===<br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. Of course, it is vital to check that the oracles really are independent and not in collusion.<br />
<br />
===Trust minimization: trusted hardware===<br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
===Trust minimization: verifiable computation===<br />
<br />
Cryptographers have recently been making excellent progress in the field of '''verifiable computation'''. This allows an untrusted server to execute a pure function in which some inputs can be private, and produce a proof that it was executed correctly. If the oracle program can be expressed as a pure function, then this technique can be powerfully applied. However there are performance limits. The current best available code as of summer 2013 is [http://research.microsoft.com/pubs/180286/pinocchio.pdf Pinnochio], an open source system from Microsoft Research. The academic state of the art is [http://www.scipr-lab.org/tinyram TinyRAM], which is based on [http://www.scipr-lab.org/system/files/csnark-20130815.pdf this paper], but the code is presently unavailable. They plan to open source it at some point.<br />
<br />
For some classes of functions checking the proof can be faster than executing the program itself, for others it is still slower - however, quite within the realms of feasibility. Because the programs are pure functions, they cannot do any I/O, therefore no access to the internet. This is quite restrictive as often the point of an oracle program is to measure external state. We can work around this restriction by providing signed data to the program and have the program itself check the signatures - to make it as easy as possible to get signed data from as many sources as possible, an extension to the SSL/TLS protocol that allows for signing of arbitrary sessions may be appropriate.<br />
<br />
===Trust minimization: Amazon AWS oracles===<br />
<br />
Finally, perhaps the most practical approach currently is to use Amazon Web Services. As of November 2013, the closest we have to a working oracle is [https://bitcointalk.org/index.php?topic=301538.0 this recipe for creating a trusted computing environment using AWS], built in support of [https://bitcointalk.org/index.php?topic=173220.0 this project for doing selective SSL logging and decryption]. The idea is that an oracle, which can be proven trustworthy using the Amazon APIs with Amazon as the root of trust, records encrypted SSL sessions to an online banking interface in such a way that later if there is a dispute about a person-to-person exchange, the logs can be decrypted and the dispute settled.<br />
<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=42716Contract2013-11-28T10:26:35Z<p>Mike: </p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
===Minimizing trust in the oracle===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. <br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
Cryptographers have recently been making excellent progress in the field of '''verifiable computation'''. This allows an untrusted server to execute a pure function in which some inputs can be private, and produce a proof that it was executed correctly. If the oracle program can be expressed as a pure function, then this technique can be powerfully applied. However there are performance limits. The current state of the art as of summer 2013 is [http://research.microsoft.com/pubs/180286/pinocchio.pdf Pinnochio], an open source system from Microsoft Research. For some classes of functions checking the proof can be faster than executing the program itself, for others it is still slower - however, quite within the realms of feasibility. Because the programs are pure functions, they cannot do any I/O, therefore no access to the internet. This is quite restrictive as often the point of an oracle program is to measure external state. We can work around this restriction by providing signed data to the program and have the program itself check the signatures - to make it as easy as possible to get signed data from as many sources as possible, an extension to the SSL/TLS protocol that allows for signing of arbitrary sessions may be appropriate.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a [https://bitcointalk.org/index.php?topic=193281.msg2224949#msg2224949 protocol proposed by TierNolan] can be used:<br />
<br />
# Party 'A' generates some random data, x (the secret).<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'x', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. The lock time for 'B' should be much larger than the lock time for 'A'. Both sides of the trade are now pending but incomplete.<br />
# Since 'A' knows the secret, 'A' can claim his coins immediately. However, 'A', in the process of claiming his coin, reveals the secret 'x' to 'B', who then uses it to finish the other side of the trade with ('x', key 'B').<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret x> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret x> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
Sergio Demian-Lerner proposed [https://bitcointalk.org/index.php?topic=91843.0 P2PTradeX], a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Agent&diff=41444Agent2013-09-29T14:35:21Z<p>Mike: Add a link to my talk</p>
<hr />
<div>An '''agent''' is an autonomous program that is able to survive by selling services for Bitcoins, and using the proceeds to rent server capacity. Agents that are profitable enough may replicate themselves by spawning additional instances on other servers. <br />
<br />
Bitcoin-using autonomous agents were first described by Gregory Maxwell, who used a file storage system called StorJ as an illustrative example[https://bitcointalk.org/index.php?topic=53855.msg642768#msg642768]. Mike Hearn gave a talk on the topic at the Turing Festival 2013 ([https://www.youtube.com/watch?v=Pu4PAMFPo5Y video] and [http://www.slideshare.net/mikehearn/future-of-money-26663148 slides]).<br />
<br />
==Core concepts==<br />
<br />
Agents interact with the world via the following mechanisms:<br />
<br />
# The Bitcoin network<br />
# APIs that allow for renting server capacity, and then remotely controlling that server (ie, ssh)<br />
# Human readable contracts posted to freelancer forums or the Mechanical Turk<br />
# Their own application protocols, for example, by serving HTTP<br />
<br />
By maintaining their own balance, for the first time it becomes possible for software to exist on a level playing field to humans. It may even be that people find themselves working for the programs because they need the money, rather than programs working for the people. Being a peer rather than a tool is what distinguishes a program that uses Bitcoin from an agent.<br />
<br />
Because server capacity is sold in well defined, standardized units (CPU seconds, gigabytes of RAM/disk, megabits of bandwidth) it becomes possible for software to automatically find and negotiate with providers who accept Bitcoin.<br />
<br />
If a better deal is found, the agent can move itself. An agent that is profitable can be programmed to use some of those profits to bring up a child instance and fund it with a starter pack of coins. If the child instance is able to break even or better, it will survive, otherwise when its bank balance expires the server provider will delete the account and the agent along with it.<br />
<br />
Agents can expose their services to humans (or other agents) by selecting a name and then registering it with [[Namecoin]]. If the agent has only Bitcoins it can use peer to peer exchanges to atomically trade Bitcoins for Namecoins or vice-versa. Using DNS hierarchies and Namecoin together allows interested parties to monitor for new agents coming online: the agent of registering a name under a particular part of the tree automatically advertises its existence.<br />
<br />
Agents can improve themselves by purchasing the services of humans and using dispute mediators to give the humans some assurance the coins will be paid upon completion of the contract. A/B testing can be used to determine if the delivered work is really better than the old one or not, with the dispute mediator only releasing the coins if the results of the test are positive. For example, a redesigned user interface can be tested on 10% of all users, to see if they are more or less likely to upload/download a file. Alternatively, a quorum of dispute mediators can be specified, and they decide if the contract was met or not. New code can also be bought to increase the agents abilities.<br />
<br />
==Reliance on low trust protocols==<br />
<br />
Low trust protocols are important for agents to protect themselves against being scammed by humans. Being merely dumb programs, they cannot make nuanced trust judgements and are potentially easy to scam, for example, by offering to sell something then not actually providing it. Humans can spread the word, use courts of law and so on to try and reclaim losses when scammed, but agents cannot.<br />
<br />
The most basic agent protocol is buying server time. By resigning transactions that are not broadcast, an agent can buy server capacity by the minute or even by the second. A very simple protocol can suffice, for instance, a ~/.account-billing-details file in the home directory of the new account that contains a Bitcoin address and the prices as negotiated. The agent can read the billing details from this standardized file and proceed to pay the server operator.<br />
<br />
To evolve the agent, new code is needed, which must be written by people. To avoid humans scamming the agent and providing code that steals its wallet, the agent can use sandboxing technologies like Java or NativeClient to ensure the newly developed code only has access to what it needs. This would impose a small amount of rigidity on the agents design, but would allow truly autonomous bargaining. The agent can be programmed to trust the judgement of long-term customers: if enough of those customers review and sign the new code, it could be released from the sandbox and allowed to modify the agent in arbitrary ways. If the agent is sufficiently improved, it will outcompete its peers and reproduce more.<br />
<br />
==Examples==<br />
<br />
Consider the original example of a file storage agent. <br />
<br />
# It rents its disk and bandwidth in return for coins. Anyone who wants a file to stay online can send coins to the files Bitcoin address.<br />
# If it starts to run out of capacity, it can use some of its profits to spawn children on other hosting services. If a service has unknown reputation, the child can be monitored for a while until the parent is convinced it's operating correctly.<br />
# Nodes can register their existence with names like "x536ma.storj.bit". Any name registered under storj.bit is assumed to offer the same services.<br />
# The agents can compete on the quality of their user interfaces. <br />
# Users could pledge for incorporation of a simple file viewer interface, to supplement download ability. <br />
<br />
Whilst there are companies that provide shell accounts for Bitcoins, most don't. Server brokers are agents that simply re-sell computing capacity to other agents:<br />
<br />
# By handling the details of how to interact with providers they offer a useful service, for which agents should be willing to pay.<br />
# Brokers can purchase from humans scripts that handle signing up for accounts at new services. They can interact with exchanges to sell Bitcoin for the currencies and payment mechanisms the providers accept.<br />
# Colo providers can run a modified sshd that understands how to treat SSH keys as [[Smart Property]]. By pre-creating shell accounts with resource quotas, and then selling the access keys to brokers, brokers can easily re-sell accounts automatically in a zero trust manner using the lock time and transaction input/output features of the Bitcoin protocol. The brokers would automatically handle recruitment of customers and matching agents with servers.<br />
<br />
==Use of trusted computing/TPM chips==<br />
<br />
To be truly autonomous, an agent should need to trust nobody (and nothing). But to make a trade you often need some assurance that the other side will behave as expected. People rely on the law to enforce contracts, but agents have no such recourse. Whilst clever protocols can configure incentives to ensure co-operation in some cases, trusted computing can be used to provide this assurance in the general case. <br />
<br />
For example, agents may need some assurance that the provider of computing time will not attempt to steal the agents profits. Whilst it may be uneconomic in the long term to steal vs revenue share, it's quick and easy to make bogus offers to whatever agents are out there and wait for the money to roll in.<br />
<br />
Modern CPUs have the ability to remotely prove what code they are running, and encrypt keys such that they are only available when the hardware is in the same configuration as before. The [http://sparrow.ece.cmu.edu/group/flicker.html Flicker] project demonstrates how to achieve this on AMD and Intel CPUs running Linux for short term computations (interrupts must be disabled in their simple implementation). Breaking the security requires modification of the TPM chip, which is designed to be tamper resistant. If it is protecting sums of money that are not extremely large, this should be a sufficiently high level of difficulty to discourage fraud.<br />
<br />
To use these facilities, a child agent (that is in the process of being created by its parent) would copy its code to the remote server. At this point it has no wallet. It would then enter the protected domain, where it is isolated from the regular operating system, and execute a PAL (piece of application logic) which creates itself a private key, which is then "sealed" to the state of the CPU at that time. Upon leaving the protected domain, it is left with encrypted data that cannot be read by the (possibly malicious) host operating system. The host OS is treated as an untrusted proxy and provider of resources. <br />
<br />
The parent needs to provide its child with a small amount of money to let it get started, but how does it know its sending money truly to the child it just created and not a greedy imposter? The child can use the TPM to remotely prove it was in total control of the CPU at the time it created the private key corresponding to the provided address. The parent can verify that remote attestation and be assured it's sending money to the program it thinks it is.<br />
<br />
If the services of an agent are purchased, for example, a file is uploaded to StorJ, the accompanying payment is presented to the secure PAL, along with the merkle branch linking it into the block chain. The PAL then updates its bookkeeping so it knows it needs to pay the host more, and when the host invoices the agent, the secure PAL verifies the bill is as expected and then creates/signs a transaction that pays the bill. The transaction is passed back to the untrusted host which broadcasts it.<br />
<br />
Not all hardware supports trusted computing facilities. However, various laptops and server/desktop class PCs can be purchased that have the relevant chips. Renting such hardware to brokers might prove a profitable way to reduce the cost of a new computer purchase.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=BIP_0050&diff=40115BIP 00502013-08-13T09:01:26Z<p>Mike: matt's patch was merged in</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 50<br />
Title: March 2013 Chain Fork Post-Mortem<br />
Author: Gavin Andresen <gavinandresen@gmail.com><br />
Status: Draft<br />
Type: Informational<br />
Created: 20-03-2013<br />
</pre><br />
<br />
==What went wrong==<br />
A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.<br />
<br />
In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.<br />
<br />
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.<br />
<br />
==What went right==<br />
* The split was detected very quickly.<br />
* The right people were online and available in IRC or could be raised via Skype.<br />
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.<br />
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.<br />
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money<br />
<br />
==Root cause==<br />
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:<br />
<br />
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.<br />
<br />
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.<br />
<br />
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.<br />
<br />
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.<br />
<br />
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).<br />
<br />
==Action items==<br />
<br />
===Immediately===<br />
<br />
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:<br />
# Reject blocks that could cause more than 10,000 locks to be taken.<br />
# Limit the maximum block-size created to 500,000 bytes<br />
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000<br />
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.<br />
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.<br />
<br />
===Alert system===<br />
<br />
'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.<br />
<br />
'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify=<command> Run command when an AppliesToMe() alert is received.<br />
<br />
'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).<br />
<br />
Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.<br />
<br />
===Safe mode===<br />
<br />
'''Done''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).<br />
<br />
===Testing===<br />
<br />
Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.<br />
<br />
===Double spending===<br />
<br />
A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.</div>Mikehttps://en.bitcoin.it/w/index.php?title=BIP_0050&diff=38841BIP 00502013-06-22T11:50:52Z<p>Mike: /* Safe mode */ pending review of code by matt</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 50<br />
Title: March 2013 Chain Fork Post-Mortem<br />
Author: Gavin Andresen <gavinandresen@gmail.com><br />
Status: Draft<br />
Type: Informational<br />
Created: 20-03-2013<br />
</pre><br />
<br />
==What went wrong==<br />
A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.<br />
<br />
In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.<br />
<br />
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.<br />
<br />
==What went right==<br />
* The split was detected very quickly.<br />
* The right people were online and available in IRC or could be raised via Skype.<br />
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.<br />
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.<br />
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money<br />
<br />
==Root cause==<br />
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:<br />
<br />
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.<br />
<br />
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.<br />
<br />
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.<br />
<br />
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.<br />
<br />
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).<br />
<br />
==Action items==<br />
<br />
===Immediately===<br />
<br />
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:<br />
# Reject blocks that could cause more than 10,000 locks to be taken.<br />
# Limit the maximum block-size created to 500,000 bytes<br />
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000<br />
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.<br />
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.<br />
<br />
===Alert system===<br />
<br />
'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.<br />
<br />
'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify=<command> Run command when an AppliesToMe() alert is received.<br />
<br />
'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).<br />
<br />
Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.<br />
<br />
===Safe mode===<br />
<br />
'''Pending review''': Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).<br />
<br />
===Testing===<br />
<br />
Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.<br />
<br />
===Double spending===<br />
<br />
A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.</div>Mikehttps://en.bitcoin.it/w/index.php?title=BIP_0050&diff=38840BIP 00502013-06-22T11:50:32Z<p>Mike: /* Alert system */ testnet alerts are done by matt</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 50<br />
Title: March 2013 Chain Fork Post-Mortem<br />
Author: Gavin Andresen <gavinandresen@gmail.com><br />
Status: Draft<br />
Type: Informational<br />
Created: 20-03-2013<br />
</pre><br />
<br />
==What went wrong==<br />
A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected hard fork of the chain. The pre-0.8 incompatible chain at that point had around 60% of the hash power ensuring the split did not automatically resolve.<br />
<br />
In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. This placed majority hashpower on the chain without the larger block.<br />
<br />
During this time there was at least [https://bitcointalk.org/index.php?topic=152348.0 one large double spend]. However, it was done by someone experimenting to see if it was possible and was not intended to be malicious.<br />
<br />
==What went right==<br />
* The split was detected very quickly.<br />
* The right people were online and available in IRC or could be raised via Skype.<br />
* Marek Palatinus and Michael Marsee quickly downgraded their nodes to restore a pre-0.8 chain as canonical, despite the fact that this caused them to sacrifice significant amounts of money and they were the ones running the bug-free version.<br />
* Deposits to the major exchanges and payments via BitPay were also suspended (and then un-suspended) very quickly.<br />
* Fortunately, the only attack on a merchant was done by someone who was not intending to actually steal money<br />
<br />
==Root cause==<br />
Bitcoin versions prior to 0.8 configure an insufficient number of Berkeley DB locks to process large but technically valid blocks. Berkeley DB locks have to be manually configured by API users depending on anticipated load. The manual says this:<br />
<br />
:The recommended algorithm for selecting the maximum number of locks, lockers, and lock objects is to run the application under stressful conditions and then review the lock system's statistics to determine the maximum number of locks, lockers, and lock objects that were used. Then, double these values for safety.<br />
<br />
Because max-sized blocks had been successfully processed on the testnet, it did not occur to anyone that there could be blocks that were smaller but require more locks than were available. Prior to 0.7 unmodified mining nodes self-imposed a maximum block size of 500,000 bytes, which further prevented this case from being triggered. 0.7 made the target size configurable and miners had been encouraged to increase this target in the week prior to the incident.<br />
<br />
Bitcoin 0.8 does not use Berkeley DB. It uses LevelDB instead, which does not require this kind of pre-configuration. Therefore it was able to process the forking block successfully.<br />
<br />
Note that BDB locks are also required during processing of re-organizations. Versions prior to 0.8 may be unable to process some valid re-orgs.<br />
<br />
This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page).<br />
<br />
==Action items==<br />
<br />
===Immediately===<br />
<br />
'''Done''': Release a version 0.8.1, forked directly from 0.8.0, that, for the next two months has the following new rules:<br />
# Reject blocks that could cause more than 10,000 locks to be taken.<br />
# Limit the maximum block-size created to 500,000 bytes<br />
# Release a patch for older versions that implements the same rules, but also increases the maximum number of locks to 120,000<br />
# Create a web page on bitcoin.org that will urge users to upgrade to 0.8.1, but will tell them how to set DB_CONFIG to 120,000 locks if they absolutely cannot.<br />
# Over the next 2 months, send a series of alerts to users of older versions, pointing to the web page.<br />
<br />
===Alert system===<br />
<br />
'''Done''': Review who has access to the alert system keys, make sure they all have contact information for each other, and get good timezone overlap by people with access to the keys.<br />
<br />
'''Done''': Implement a new bitcoind feature so services can get timely notification of alerts: -alertnotify=<command> Run command when an AppliesToMe() alert is received.<br />
<br />
'''Done''': Pre-generate 52 test alerts, and set a time every week when they are broadcast on -testnet (so -alertnotify scripts can be tested in as-close-to-real-world conditions as possible).<br />
<br />
Idea from Michael Gronager: encourage merchants/exchanges (and maybe pools) to run new code behind a bitcoind running the network-majority version.<br />
<br />
===Safe mode===<br />
<br />
Perhaps trigger an alert if there is a long enough side chain detected, even if it is not the main chain. Pools could use this to automatically suspend payouts if a long side-chain suddenly appeared out of nowhere (it’s hard for an attacker to mine such a thing).<br />
<br />
===Testing===<br />
<br />
Start running bots on the testnet that grab some coins from a testnet faucet, generate large numbers of random transactions that split/recombine them and then send them back to the faucet. Randomized online testing on the testnet might have revealed the pathological block type earlier.<br />
<br />
===Double spending===<br />
<br />
A double spend attack was successful, despite that both sides of the chain heard about the transactions in the same order. The reason is most likely that the memory pools were cleared when the mining pool nodes were downgraded. A solution is for nodes to sync their mempools to each other at startup, however, this requires a memory pool expiry policy to be implemented as currently node restarts are the only way for unconfirmed transactions to be evicted from the system.</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=38762Contract2013-06-17T13:21:42Z<p>Mike: /* Minimizing trust in the oracle */</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
As of May 2013 work on implementing this protocol has begun. Please contact Mike if you would like to work on this, so you can be put in touch with the people who are already implementing it.<br />
<br />
===Minimizing trust in the oracle===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly '''challenge''' the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for '''n-of-m''' oracles if need be. <br />
<br />
Using commodity hardware, you can use '''trusted computing''' in the form of Intel TXT or the AMD equivalent (SKINIT) to set up a sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
Cryptographers have recently been making excellent progress in the field of '''verifiable computation'''. This allows an untrusted server to execute a pure function in which some inputs can be private, and produce a proof that it was executed correctly. If the oracle program can be expressed as a pure function, then this technique can be powerfully applied. However there are performance limits. The current state of the art as of summer 2013 is [http://research.microsoft.com/pubs/180286/pinocchio.pdf Pinnochio], an open source system from Microsoft Research. For some classes of functions checking the proof can be faster than executing the program itself, for others it is still slower - however, quite within the realms of feasibility. Because the programs are pure functions, they cannot do any I/O, therefore no access to the internet. This is quite restrictive as often the point of an oracle program is to measure external state. We can work around this restriction by providing signed data to the program and have the program itself check the signatures - to make it as easy as possible to get signed data from as many sources as possible, an extension to the SSL/TLS protocol that allows for signing of arbitrary sessions may be appropriate.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details and alternative implementations.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=38761Contract2013-06-17T13:20:51Z<p>Mike: /* Example 4: Using external state */ Some improvements.</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<hash> OP_DROP 2 <sons pubkey> <oracle pubkey> CHECKMULTISIG<br />
<br />
This is the oracle script. It has an unusual form - it pushes data to the stack then immediately deletes it again. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return (10.0, 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an output: an amount of value and an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and returns the signature to the user. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The user accepts the new signature, inserts it into the scriptSig and broadcasts the transaction.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
As of May 2013 work on implementing this protocol has begun. Please contact Mike if you would like to work on this, so you can be put in touch with the people who are already implementing it.<br />
<br />
===Minimizing trust in the oracle===<br />
<br />
There are various ways to reduce the level of required trust in the oracle.<br />
<br />
Going back to our first example, the oracle has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, it cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. <br />
<br />
The number of keys in the CHECKMULTISIG can be increased to allow for n-of-m oracles if need be. <br />
<br />
Using commodity hardware, you can use Intel TXT or the AMD equivalent (SKINIT) to set up a trusted, sealed hardware environment and then use the TPM chip to attest that fact to a third party. That third party can verify the hardware was in the required state. Defeating this requires someone to be able to interfere with the execution of a program that may run entirely on the CPU, even in extreme cases without any data traversing the memory bus (you can run entirely using on-die cache if the program is small enough).<br />
<br />
Cryptographers have recently been making excellent progress in the field of '''verifiable computation'''. This allows an untrusted server to execute a pure function in which some inputs can be private, and produce a proof that it was executed correctly. If the oracle program can be expressed as a pure function, then this technique can be powerfully applied. However there are performance limits. The current state of the art as of summer 2013 is [http://research.microsoft.com/pubs/180286/pinocchio.pdf Pinnochio], an open source system from Microsoft Research. For some classes of functions checking the proof can be faster than executing the program itself, for others it is still slower - however, quite within the realms of feasibility. Because the programs are pure functions, they cannot do any I/O, therefore no access to the internet. This is quite restrictive as often the point of an oracle program is to measure external state. We can work around this restriction by providing signed data to the program and have the program itself check the signatures - to make it as easy as possible to get signed data from as many sources as possible, an extension to the SSL/TLS protocol that allows for signing of arbitrary sessions may be appropriate.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
See [[Atomic cross-chain trading]] for details and alternative implementations.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=37800Contract2013-05-15T01:02:57Z<p>Mike: Add forgotten step in example 7</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be. Trusted computing allows for remote attestation, which is another way to minimise required trust levels. <br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
As of May 2013 work on implementing this protocol has begun. Please contact Mike if you would like to work on this to avoid duplication of effort.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client signs T1 and passes the signature to the server, which now broadcasts the transaction (either party can do this if they both have connectivity). This locks in the money.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=37769Contract2013-05-14T01:47:35Z<p>Mike: Note that someone has started working on oracles. Also note that challenges where the control conditions are always false poses open questions. Mention remote attestation.</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. How to challenge the oracle with conditions that are not yet true is however an open research question. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be. Trusted computing allows for remote attestation, which is another way to minimise required trust levels. <br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
As of May 2013 work on implementing this protocol has begun. Please contact Mike if you would like to work on this to avoid duplication of effort.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=37768Contract2013-05-14T01:44:52Z<p>Mike: Re-write the micropayment channels contract to not be buggy</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, the following protocol can be used. This protocol relies upon a '''different''' behavior of nLockTime to the original design. Starting around 2013 time-locked transactions were made non standard and no longer enter the memory pool, thus cannot be broadcast before the timelock expires. When the behaviour of nLockTime is restored to the original design from Satoshi, a variant of this protocol is required which is discussed below.<br />
<br />
We define the client to be the party sending value, and the server to be the party receiving it. This is written from the clients perspective.<br />
<br />
# Create a public key (K1). Request a public key from the server (K2). <br />
# Create and sign but do not broadcast a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the server's public key and one of your own to be used. A good way to do this is use OP_CHECKMULTISIG. The value to be used is chosen as an efficiency tradeoff.<br />
# Create a refund transaction (T2) that is connected to the output of T1 which sends all the money back to yourself. It has a time lock set for some time in the future, for instance a few hours. Don't sign it, and provide the unsigned transaction to the server. By convention, the output script is "2 K1 K2 2 CHECKMULTISIG"<br />
# The server signs T2 using its public key K2 and returns the signature to the client. Note that it has not seen T1 at this point, just the hash (which is in the unsigned T2).<br />
# The client verifies the servers signature is correct and aborts if not.<br />
# The client then creates a new transaction, T3, which connects to T1 like the refund transaction does and has two outputs. One goes to K1 and the other goes to K2. It starts out with all value allocated to the first output (K1), ie, it does the same thing as the refund transaction but is not time locked. The client signs T3 and provides the transaction and signature to the server.<br />
# The server verifies the output to itself is of the expected size and verifies the client's provided signature is correct.<br />
# When the client wishes to pay the server, it adjusts its copy of T3 to allocate more value to the server's output and less to its ow. It then re-signs the new T3 and sends the signature to the server. It does not have to send the whole transaction, just the signature and the amount to increment by is sufficient. The server adjusts its copy of T3 to match the new amounts, verifies the signature and continues.<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP then signs and broadcasts the last transaction it saw, allocating the final amount to itself. The refund transaction is needed to handle the case where the server disappears or halts at any point, leaving the allocated value in limbo. If this happens then once the time lock has expired the client can broadcast the refund transaction and get back all the money.<br />
<br />
Mike Hearn is working on an implementation of this protocol in bitcoinj. Please [mailto:mike@plan99.net contact him] for more information.<br />
<br />
When nLockTime'd transactions are able to enter the memory pool (once more) and transaction replacement has been re-enabled, a variant on the protocol must be used. In this case, no refund transaction is used. Instead each T3 has a sequence number one higher than the previous and all T3's have a time lock set to the same period as above. Each time a payment is made the sequence number is incremented, ensuring that the last version will take precedence. If the channel protocol is not closed cleanly, this means the value transfer won't commit until the time lock expires. To avoid this both parties can cooperate by signing a T3 that has a sequence number of 0xFFFFFFFF resulting in immediate confirmation regardless of the value of nLockTime.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
The latter protocol that relies on transaction replacement is more flexible because it allows the value allocated to go down as well as up during the lifetime of the channel as long as the client receives signatures from the server, but for many use cases this functionality is not required. Replacement also allows for more complex configurations of channels that involve more than two parties. Elaboration on such use cases is a left as an exercise for the reader.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36999Funding network security2013-04-14T18:49:40Z<p>Mike: Point users back to the original document.</p>
<hr />
<div>If you have followed a link to this page from reddit or elsewhere, please see for the original document.<br />
<br />
https://bitcointalk.org/index.php?topic=157141.msg1665332#msg1665332</div>Mikehttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36984Funding network security2013-04-14T11:36:07Z<p>Mike: Roll back a complete replacement of this page</p>
<hr />
<div>One open question is how will '''funding of network security''' (mining) work if there's no competition for block space. If funding for proof of work comes from fees attached to transactions and the fees are motivated by scarcity of block space, then the funding mechanism is clear, though whether it will achieve "enough" funding is not.<br />
<br />
This page is written by [[Mike Hearn]]. Please contact him with questions rather than using the Talk page.<br />
<br />
In a world where block sizes are always large enough to meet demand for space, we can fund mining using per-block [https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts assurance contracts]. From Wikipedia:<br />
<br />
::An assurance contract, also known as a provision point mechanism, is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of the free rider problem.<br />
<br />
::The free rider problem is that there may be actions that would benefit a large group of people, but once the action is taken, there is no way to exclude those who did not pay for the action from the benefits. This leads to a game theoretic problem: all members of a group might be better off if an action were taken, and the members of the group contributed to the cost of the action, but many members of the group may make the perfectly rational decision to let others pay for it, then reap the benefits for free, possibly with the result that no action is taken. The result of this rational game play is lower utility for everyone.<br />
<br />
This describes network security with large block sizes. Everyone needs mining to be done, but nobody wants to be the one who pays for it given that everyone else will get the benefits for free.<br />
<br />
As described on the contracts wiki page, an assurance contract is one in which an entrepreneur says "I will pay X towards the cost of a public good, but only if other people chip in enough to reach Y (the cost of providing the good)". If not enough people pledge money, the contract does not complete and nobody pays anything. This mechanism has a proven track record of funding public goods, mostly obviously via Kickstarter.<br />
<br />
== What is the target? ==<br />
<br />
We need to figure out what "enough" mining means. This is related to the maximum time-value of transactions on the network. For micropayments, you don't need a whole lot of mining to protect all of them because the value of reversing them is very low, and any given attacker isn't trying to reverse all transactions but only the one for their own payment (they can't reverse arbitrary transactions). If you have very high value transactions where the receivers are willing to wait six months then you also don't need a whole lot. If you have very high value transactions that are occurring only between people/entities who trust each other, again, don't need much mining. That might sound unrealistic, but once you go above a certain level transactions almost always take place between people who know and can find each other - think about billion dollar business deals, etc. You don't need miners to ensure that won't be reversed. You just need a functioning legal system.<br />
<br />
The type of transaction that's most tricky to secure are kind of middle of the road transactions - not billion dollar business deals, not micropayments but the ones where some real value is moving and it's not worth enough to sue the other side if something goes wrong. If there is enough mining to secure this kind of transaction, then there's enough for the other kinds too. There should be a lot of these, and there should also be a lot of participants.<br />
<br />
For an assurance contract to work, do you need everyone who benefits to be a participant? No, some freeloading is OK, as long as those freeloaders weren't going to contribute anyway. Let's imagine that 200 major Bitcoin participants get together and form an assurance contract that funds 10 terahashes of mining (numbers are arbitrary). Does their agreement break if 200,000 users then make 500,000 micropayments? Not really - those micropayments hardly need any mining to be secure and those users weren't going to pay for 10 Thash no matter what, not even collectively. There's no downside to them being able to benefit from the extra mining you pay for and indeed, there may be indirect upsides (your Bitcoins become more valuable because they have greater utility).<br />
<br />
== Implementation ==<br />
<br />
Implementation can be done effectively via the introduction of a new network rule. It says that money spent to an output that contains an unspendable script can be claimed as fees. We're already introducing the idea of OP_RETURN outputs that simply result in insta-pruning of that output, as it's provably unspendable. Allowing that value to be claimed as fees is a hard-forking rule change, but it's also a relatively straightforward one (the alternative is to have the money be destroyed ... which is bad), and we need to hard fork to increase the block size anyway. Once this is done, we can have a separate P2P broadcast network in which participants broadcast pledges. The pledge is an invalid transaction that takes X coins with a SIGHASH_ANYONECANPAY signature and then re-allocates it to an unspendable output of Y coins, where Y > X. X is the pledge and Y is the target, of course. Peers listen and when they have seen enough pledges to sum up to a value of greater than Y, they just combine them to make the tx valid and broadcast it on the regular Bitcoin network. Peers can do this in parallel - there's a chance of naturally occurring double spends but rules on how to construct the contract out of the pledges can probably reduce that to a trivial level.<br />
<br />
Note that it is possible to do spend-to-fee assurance contracts without the new rule, but it'd be complicated and involve a multi-round protocol in which people first announce they want to pledge an output, then someone has to build a template transaction based on all the announcements, then the group signs it in parallel. It can be done but it's messier.<br />
<br />
What are X and Y set to? That depends on what the participants want. It'd be nice to find economic research on the case where the public good in question is continuous, but I don't know of any at the moment. I think it'd likely work like this - merchants that have noticed that they start seeing double spends when network speed drops below 5 THash/sec would clearly be targeting that amount and no more. Other merchants might only care about 1 Thash/sec. In that case, the first class of merchants can set their Y to 1 Thash and just broadcast multiple independent contracts, this means there is a chance that they'll get less than what they wanted (which weakens the definition of the target) but there's more of a chance of the contracts completing. At any rate, they would reduce their pledge size as well for each contract, so they aren't exposing themselves to freeloaders at any greater level.<br />
<br />
For X, I imagine that if you start from a steady state your goal is to lower it as much as possible without stopping the contracts from completing entirely. One way is to lower your pledge and see how fast the contract completes - if the contract doesn't complete within your required time limit, you can just (anonymously) broadcast a second pledge to make it back to what you were previously pledging. But other players don't know you might do that.<br />
<br />
In a healthy system I'd expect there to be many independent, overlapping contracts being formed. They're simple to construct so doing one per block is reasonable.<br />
<br />
== Conclusion == <br />
<br />
Obviously whilst there are many participants with different ideas about what network speed is "enough", with only one chain there can only be one speed. People with extreme needs would end up not being able to use the block chain for their security and would have to find alternative arrangements, or just accept that they'd be subsidising the activities of others who can tolerate lower security.<br />
<br />
I think the next piece of work needed to explore this idea is searching the literature for studies of assurance contracts for continuous public goods, as the primary difference between what this scheme would do and proven models like Kickstarter is the need for group consensus on what "enough" mining means.<br />
<br />
That said, I note that the alternative proposal (restrict block size and charge fees to get in) doesn't even try to answer the question of how much mining is enough. It's just assumed that some arbitrary byte limit would result in demand exceeding supply to the level that mining is well funded. The problem being that limiting blocks by physical size doesn't jive with the fact that they move abstract value - if anything, for such a scheme to work, block sizes should be limited by satoshis transferred. Otherwise you could get a bunch of very high value transactions that end up with tiny fees because that's all that's necessary to get into the block, as lower value transactions have long since given up on the system and gone elsewhere.<br />
<br />
== References ==<br />
* [https://bitcointalk.org/index.php?topic=157141.0 Bitcointalk thread]<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36714Funding network security2013-04-05T13:23:48Z<p>Mike: Add technical category tag</p>
<hr />
<div>One open question is how will '''funding of network security''' (mining) work if there's no competition for block space. If funding for proof of work comes from fees attached to transactions and the fees are motivated by scarcity of block space, then the funding mechanism is clear, though whether it will achieve "enough" funding is not.<br />
<br />
This page is written by [mailto:mike@plan99.net Mike Hearn]. Please contact him with questions rather than using the Talk page.<br />
<br />
In a world where block sizes are always large enough to meet demand for space, we can fund mining using per-block [https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts assurance contracts]. From Wikipedia:<br />
<br />
::An assurance contract, also known as a provision point mechanism, is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of the free rider problem.<br />
<br />
::The free rider problem is that there may be actions that would benefit a large group of people, but once the action is taken, there is no way to exclude those who did not pay for the action from the benefits. This leads to a game theoretic problem: all members of a group might be better off if an action were taken, and the members of the group contributed to the cost of the action, but many members of the group may make the perfectly rational decision to let others pay for it, then reap the benefits for free, possibly with the result that no action is taken. The result of this rational game play is lower utility for everyone.<br />
<br />
This describes network security with large block sizes. Everyone needs mining to be done, but nobody wants to be the one who pays for it given that everyone else will get the benefits for free.<br />
<br />
As described on the contracts wiki page, an assurance contract is one in which an entrepreneur says "I will pay X towards the cost of a public good, but only if other people chip in enough to reach Y (the cost of providing the good)". If not enough people pledge money, the contract does not complete and nobody pays anything. This mechanism has a proven track record of funding public goods, mostly obviously via Kickstarter.<br />
<br />
== What is the target? ==<br />
<br />
We need to figure out what "enough" mining means. This is related to the maximum time-value of transactions on the network. For micropayments, you don't need a whole lot of mining to protect all of them because the value of reversing them is very low, and any given attacker isn't trying to reverse all transactions but only the one for their own payment (they can't reverse arbitrary transactions). If you have very high value transactions where the receivers are willing to wait six months then you also don't need a whole lot. If you have very high value transactions that are occurring only between people/entities who trust each other, again, don't need much mining. That might sound unrealistic, but once you go above a certain level transactions almost always take place between people who know and can find each other - think about billion dollar business deals, etc. You don't need miners to ensure that won't be reversed. You just need a functioning legal system.<br />
<br />
The type of transaction that's most tricky to secure are kind of middle of the road transactions - not billion dollar business deals, not micropayments but the ones where some real value is moving and it's not worth enough to sue the other side if something goes wrong. If there is enough mining to secure this kind of transaction, then there's enough for the other kinds too. There should be a lot of these, and there should also be a lot of participants.<br />
<br />
For an assurance contract to work, do you need everyone who benefits to be a participant? No, some freeloading is OK, as long as those freeloaders weren't going to contribute anyway. Let's imagine that 200 major Bitcoin participants get together and form an assurance contract that funds 10 terahashes of mining (numbers are arbitrary). Does their agreement break if 200,000 users then make 500,000 micropayments? Not really - those micropayments hardly need any mining to be secure and those users weren't going to pay for 10 Thash no matter what, not even collectively. There's no downside to them being able to benefit from the extra mining you pay for and indeed, there may be indirect upsides (your Bitcoins become more valuable because they have greater utility).<br />
<br />
== Implementation ==<br />
<br />
Implementation can be done effectively via the introduction of a new network rule. It says that money spent to an output that contains an unspendable script can be claimed as fees. We're already introducing the idea of OP_RETURN outputs that simply result in insta-pruning of that output, as it's provably unspendable. Allowing that value to be claimed as fees is a hard-forking rule change, but it's also a relatively straightforward one (the alternative is to have the money be destroyed ... which is bad), and we need to hard fork to increase the block size anyway. Once this is done, we can have a separate P2P broadcast network in which participants broadcast pledges. The pledge is an invalid transaction that takes X coins with a SIGHASH_ANYONECANPAY signature and then re-allocates it to an unspendable output of Y coins, where Y > X. X is the pledge and Y is the target, of course. Peers listen and when they have seen enough pledges to sum up to a value of greater than Y, they just combine them to make the tx valid and broadcast it on the regular Bitcoin network. Peers can do this in parallel - there's a chance of naturally occurring double spends but rules on how to construct the contract out of the pledges can probably reduce that to a trivial level.<br />
<br />
Note that it is possible to do spend-to-fee assurance contracts without the new rule, but it'd be complicated and involve a multi-round protocol in which people first announce they want to pledge an output, then someone has to build a template transaction based on all the announcements, then the group signs it in parallel. It can be done but it's messier.<br />
<br />
What are X and Y set to? That depends on what the participants want. It'd be nice to find economic research on the case where the public good in question is continuous, but I don't know of any at the moment. I think it'd likely work like this - merchants that have noticed that they start seeing double spends when network speed drops below 5 THash/sec would clearly be targeting that amount and no more. Other merchants might only care about 1 Thash/sec. In that case, the first class of merchants can set their Y to 1 Thash and just broadcast multiple independent contracts, this means there is a chance that they'll get less than what they wanted (which weakens the definition of the target) but there's more of a chance of the contracts completing. At any rate, they would reduce their pledge size as well for each contract, so they aren't exposing themselves to freeloaders at any greater level.<br />
<br />
For X, I imagine that if you start from a steady state your goal is to lower it as much as possible without stopping the contracts from completing entirely. One way is to lower your pledge and see how fast the contract completes - if the contract doesn't complete within your required time limit, you can just (anonymously) broadcast a second pledge to make it back to what you were previously pledging. But other players don't know you might do that.<br />
<br />
In a healthy system I'd expect there to be many independent, overlapping contracts being formed. They're simple to construct so doing one per block is reasonable.<br />
<br />
== Conclusion == <br />
<br />
Obviously whilst there are many participants with different ideas about what network speed is "enough", with only one chain there can only be one speed. People with extreme needs would end up not being able to use the block chain for their security and would have to find alternative arrangements, or just accept that they'd be subsidising the activities of others who can tolerate lower security.<br />
<br />
I think the next piece of work needed to explore this idea is searching the literature for studies of assurance contracts for continuous public goods, as the primary difference between what this scheme would do and proven models like Kickstarter is the need for group consensus on what "enough" mining means.<br />
<br />
That said, I note that the alternative proposal (restrict block size and charge fees to get in) doesn't even try to answer the question of how much mining is enough. It's just assumed that some arbitrary byte limit would result in demand exceeding supply to the level that mining is well funded. The problem being that limiting blocks by physical size doesn't jive with the fact that they move abstract value - if anything, for such a scheme to work, block sizes should be limited by satoshis transferred. Otherwise you could get a bunch of very high value transactions that end up with tiny fees because that's all that's necessary to get into the block, as lower value transactions have long since given up on the system and gone elsewhere.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Funding_network_security&diff=36713Funding network security2013-04-05T13:22:43Z<p>Mike: Add a page on using network assurance contracts</p>
<hr />
<div>One open question is how will '''funding of network security''' (mining) work if there's no competition for block space. If funding for proof of work comes from fees attached to transactions and the fees are motivated by scarcity of block space, then the funding mechanism is clear, though whether it will achieve "enough" funding is not.<br />
<br />
This page is written by [mailto:mike@plan99.net Mike Hearn]. Please contact him with questions rather than using the Talk page.<br />
<br />
In a world where block sizes are always large enough to meet demand for space, we can fund mining using per-block [https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts assurance contracts]. From Wikipedia:<br />
<br />
::An assurance contract, also known as a provision point mechanism, is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of the free rider problem.<br />
<br />
::The free rider problem is that there may be actions that would benefit a large group of people, but once the action is taken, there is no way to exclude those who did not pay for the action from the benefits. This leads to a game theoretic problem: all members of a group might be better off if an action were taken, and the members of the group contributed to the cost of the action, but many members of the group may make the perfectly rational decision to let others pay for it, then reap the benefits for free, possibly with the result that no action is taken. The result of this rational game play is lower utility for everyone.<br />
<br />
This describes network security with large block sizes. Everyone needs mining to be done, but nobody wants to be the one who pays for it given that everyone else will get the benefits for free.<br />
<br />
As described on the contracts wiki page, an assurance contract is one in which an entrepreneur says "I will pay X towards the cost of a public good, but only if other people chip in enough to reach Y (the cost of providing the good)". If not enough people pledge money, the contract does not complete and nobody pays anything. This mechanism has a proven track record of funding public goods, mostly obviously via Kickstarter.<br />
<br />
== What is the target? ==<br />
<br />
We need to figure out what "enough" mining means. This is related to the maximum time-value of transactions on the network. For micropayments, you don't need a whole lot of mining to protect all of them because the value of reversing them is very low, and any given attacker isn't trying to reverse all transactions but only the one for their own payment (they can't reverse arbitrary transactions). If you have very high value transactions where the receivers are willing to wait six months then you also don't need a whole lot. If you have very high value transactions that are occurring only between people/entities who trust each other, again, don't need much mining. That might sound unrealistic, but once you go above a certain level transactions almost always take place between people who know and can find each other - think about billion dollar business deals, etc. You don't need miners to ensure that won't be reversed. You just need a functioning legal system.<br />
<br />
The type of transaction that's most tricky to secure are kind of middle of the road transactions - not billion dollar business deals, not micropayments but the ones where some real value is moving and it's not worth enough to sue the other side if something goes wrong. If there is enough mining to secure this kind of transaction, then there's enough for the other kinds too. There should be a lot of these, and there should also be a lot of participants.<br />
<br />
For an assurance contract to work, do you need everyone who benefits to be a participant? No, some freeloading is OK, as long as those freeloaders weren't going to contribute anyway. Let's imagine that 200 major Bitcoin participants get together and form an assurance contract that funds 10 terahashes of mining (numbers are arbitrary). Does their agreement break if 200,000 users then make 500,000 micropayments? Not really - those micropayments hardly need any mining to be secure and those users weren't going to pay for 10 Thash no matter what, not even collectively. There's no downside to them being able to benefit from the extra mining you pay for and indeed, there may be indirect upsides (your Bitcoins become more valuable because they have greater utility).<br />
<br />
== Implementation ==<br />
<br />
Implementation can be done effectively via the introduction of a new network rule. It says that money spent to an output that contains an unspendable script can be claimed as fees. We're already introducing the idea of OP_RETURN outputs that simply result in insta-pruning of that output, as it's provably unspendable. Allowing that value to be claimed as fees is a hard-forking rule change, but it's also a relatively straightforward one (the alternative is to have the money be destroyed ... which is bad), and we need to hard fork to increase the block size anyway. Once this is done, we can have a separate P2P broadcast network in which participants broadcast pledges. The pledge is an invalid transaction that takes X coins with a SIGHASH_ANYONECANPAY signature and then re-allocates it to an unspendable output of Y coins, where Y > X. X is the pledge and Y is the target, of course. Peers listen and when they have seen enough pledges to sum up to a value of greater than Y, they just combine them to make the tx valid and broadcast it on the regular Bitcoin network. Peers can do this in parallel - there's a chance of naturally occurring double spends but rules on how to construct the contract out of the pledges can probably reduce that to a trivial level.<br />
<br />
Note that it is possible to do spend-to-fee assurance contracts without the new rule, but it'd be complicated and involve a multi-round protocol in which people first announce they want to pledge an output, then someone has to build a template transaction based on all the announcements, then the group signs it in parallel. It can be done but it's messier.<br />
<br />
What are X and Y set to? That depends on what the participants want. It'd be nice to find economic research on the case where the public good in question is continuous, but I don't know of any at the moment. I think it'd likely work like this - merchants that have noticed that they start seeing double spends when network speed drops below 5 THash/sec would clearly be targeting that amount and no more. Other merchants might only care about 1 Thash/sec. In that case, the first class of merchants can set their Y to 1 Thash and just broadcast multiple independent contracts, this means there is a chance that they'll get less than what they wanted (which weakens the definition of the target) but there's more of a chance of the contracts completing. At any rate, they would reduce their pledge size as well for each contract, so they aren't exposing themselves to freeloaders at any greater level.<br />
<br />
For X, I imagine that if you start from a steady state your goal is to lower it as much as possible without stopping the contracts from completing entirely. One way is to lower your pledge and see how fast the contract completes - if the contract doesn't complete within your required time limit, you can just (anonymously) broadcast a second pledge to make it back to what you were previously pledging. But other players don't know you might do that.<br />
<br />
In a healthy system I'd expect there to be many independent, overlapping contracts being formed. They're simple to construct so doing one per block is reasonable.<br />
<br />
== Conclusion == <br />
<br />
Obviously whilst there are many participants with different ideas about what network speed is "enough", with only one chain there can only be one speed. People with extreme needs would end up not being able to use the block chain for their security and would have to find alternative arrangements, or just accept that they'd be subsidising the activities of others who can tolerate lower security.<br />
<br />
I think the next piece of work needed to explore this idea is searching the literature for studies of assurance contracts for continuous public goods, as the primary difference between what this scheme would do and proven models like Kickstarter is the need for group consensus on what "enough" mining means.<br />
<br />
That said, I note that the alternative proposal (restrict block size and charge fees to get in) doesn't even try to answer the question of how much mining is enough. It's just assumed that some arbitrary byte limit would result in demand exceeding supply to the level that mining is well funded. The problem being that limiting blocks by physical size doesn't jive with the fact that they move abstract value - if anything, for such a scheme to work, block sizes should be limited by satoshis transferred. Otherwise you could get a bunch of very high value transactions that end up with tiny fees because that's all that's necessary to get into the block, as lower value transactions have long since given up on the system and gone elsewhere.</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=36712Contract2013-04-05T13:17:55Z<p>Mike: /* Example 3: Assurance contracts */</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Transferable virtual property]] are digital items that can be traded but not duplicated.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared for '''[[Funding network security|funding network security]]''' for the next block. In this way, mining can be funded even if block space is not scarce.<br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other with limited trust. However, because distinct blockchains have different views of time, currently known proposals are susceptible to either a) a loss of funds if one party fails to complete the protocol; or, b) if timeouts are used, a race condition whereby one party could take all the funds. [https://bitcointalk.org/index.php?topic=91843 This was first pointed out] by Sergio Demian-Lerner, who proposed a solution requiring the validation rules for one blockchain to be effectively encoded into the validation rules for the other.<br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
This protocol makes it feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, a protocol similar to one proposed by hashcoin can be used:<br />
<br />
# Request a public key from the access point.<br />
# Create, but do not sign, a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the access point's public key and one of your own to be used. The value to be used is chosen as an efficiency tradeoff.<br />
# Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).<br />
# Send both unsigned transactions to the access point. It sees that T1 and T2 are of the expected form and signs T2. It hands T2 back to you.<br />
# Check that T2 is signed correctly, sign T1 and T2. Send them to the access point, which broadcasts them, thus locking in the agreement. Note that T2 won't get included into a block for at least one day, unless it's replaced by a newer transaction, as determined by the sequence numbers.<br />
# Each time you want 10kb of data quota, sign a new version of T2 with a higher sequence number, the same lock time, and adjust the outputs so more value is allocated to the access point, and send it. The AP sees that the output sizes are correct, signs it, and keeps it (does not broadcast).<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP broadcasts the last transaction it saw, replacing the original that was pending. Once the lock time passes, the value transfer is committed. Alternatively, if the session end is negotiated cleanly, the user can sign a transaction that's final (sequence number of UINT_MAX), which signals that no more data quota will be purchased, allowing instant commitment of the transaction.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Scalability&diff=36095Scalability2013-03-12T20:07:16Z<p>Mike: Some tweaks and a reference to sipas code</p>
<hr />
<div>The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to more powerful backbone nodes is capable of scaling to millions of users and tens of thousands of transactions per second.<br />
<br />
==Scalability targets==<br />
<br />
VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. They have burst capacity for over 10,000 tps which they need to handle the busiest points of the holiday period (~8,500 tps). [http://investor.visa.com/phoenix.zhtml?c=215693&p=irol-newsArticle_print&ID=1355716]<br />
<br />
PayPal, in contrast, handles around 4 million transactions per day for an average of 46 tps or a probably peak rate of 100 tps.<br />
<br />
Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.<br />
<br />
==Current bottlenecks==<br />
<br />
Today the Bitcoin network is restricted to a sustained rate of 7 tps by some artificial limits. These were put in place to stop people from ballooning the size of the block chain before the network and community was ready for it. Once those limits are lifted, the maximum transaction rate will go up significantly.<br />
<br />
==CPU==<br />
<br />
The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.<br />
<br />
The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.<br />
<br />
Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.<br />
<br />
As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.<br />
<br />
==Network==<br />
<br />
Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.<br />
<br />
That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.<br />
<br />
This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.<br />
<br />
When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.<br />
<br />
==Storage==<br />
<br />
At very high transaction rates each block can be over half a gigabyte in size.<br />
<br />
It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.<br />
<br />
Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.<br />
<br />
The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.<br />
<br />
==Optimizations==<br />
<br />
The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks). <br />
<br />
However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.<br />
<br />
===CPU===<br />
<br />
Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.<br />
<br />
Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a "soft fork" like the one done recently for pay-to-script-hash support. <br />
<br />
Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).<br />
<br />
Assuming no upgrades to lightweight/SPV clients, so just batch verification, we can reach 40,000 transactions per second which is far beyond the traffic levels of the entire credit card system. And with ed25519 we could go up to nearly half a million transactions per second - with todays hardware! At these speeds it is likely that bandwidth to disk would become the primary limiting factor.<br />
<br />
<br />
===Simplified payment verification===<br />
<br />
It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[BitCoinJ]] is an implementation of this mode.<br />
<br />
In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block. <br />
<br />
As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg, you only really need to store say 5000 blocks).<br />
<br />
The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.<br />
<br />
Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.<br />
<br />
See also: [[Thin Client Security]].<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Protocol_documentation&diff=35896Protocol documentation2013-03-06T09:21:20Z<p>Mike: add mention of merkle tools</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:<br />
<br />
hash(a) = sha256(sha256(a))<br />
<br />
hash(a) hash(b) hash(c)<br />
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))<br />
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))<br />
<br />
They are paired up, with the last element being _duplicated_.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
Footnote - if you're reading the Satoshi client code it refers to this as a "CompactSize" - VarInt's are something entirely different to the Satoshi code.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|-<br />
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]]<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
35 8D 49 32 - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
<br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== filterload, filteradd, filterclear, merkleblock ===<br />
<br />
These messages are related to Bloom filtering of connections and are defined in [[BIP 0037]].<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Protocol_documentation&diff=35895Protocol documentation2013-03-06T09:17:32Z<p>Mike: mention the pong</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:<br />
<br />
hash(a) = sha256(sha256(a))<br />
<br />
hash(a) hash(b) hash(c)<br />
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))<br />
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))<br />
<br />
They are paired up, with the last element being _duplicated_.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
Footnote - if you're reading the Satoshi client code it refers to this as a "CompactSize" - VarInt's are something entirely different to the Satoshi code.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
35 8D 49 32 - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
<br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. In modern protocol versions, a ''pong'' response is generated using a nonce included in the ping.<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Protocol_documentation&diff=35894Protocol documentation2013-03-06T09:16:54Z<p>Mike: add notfound message</p>
<hr />
<div>Sources:<br />
* [[Original Bitcoin client]] source<br />
<br />
Type names used in this documentation are from the C99 standard.<br />
<br />
For protocol used in mining, see [[Getwork]].<br />
<br />
==Common standards==<br />
<br />
=== Hashes ===<br />
<br />
Usually, when a hash is computed within bitcoin, it is computed twice. Most of the time [http://en.wikipedia.org/wiki/SHA-2 SHA-256] hashes are used, however [http://en.wikipedia.org/wiki/RIPEMD RIPEMD-160] is also used when a shorter hash is desirable (for example when creating a bitcoin address).<br />
<br />
Example of double-SHA-256 encoding of string "hello":<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round of sha-256)<br />
9595c9df90075148eb06860365df33584b75bff782a510c6cd4883a419833d50 (second round of sha-256)<br />
<br />
For bitcoin addresses (RIPEMD-160) this would give:<br />
<br />
hello<br />
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 (first round is sha-256)<br />
b6a9c8c230722b7c748331a8b450f05566dc7d0f (with ripemd-160)<br />
<br />
=== Merkle Trees ===<br />
<br />
Merkle trees are binary trees of hashes. Merkle trees in bitcoin use '''Double''' SHA-256, and are built up as so:<br />
<br />
hash(a) = sha256(sha256(a))<br />
<br />
hash(a) hash(b) hash(c)<br />
hash(hash(a)+hash(b)) hash(hash(c)+hash(c))<br />
hash(hash(hash(a)+hash(b))+hash(hash(c)+hash(c)))<br />
<br />
They are paired up, with the last element being _duplicated_.<br />
<br />
Note: Hashes in Merkle Tree displayed in the [[Block Explorer]] are of little-endian notation. For some implementations and [http://www.fileformat.info/tool/hash.htm calculations], the bits need to be reversed before they are hashed, and again after the hashing operation.<br />
<br />
=== Signatures ===<br />
<br />
Bitcoin uses [http://en.wikipedia.org/wiki/Elliptic_curve_cryptography Elliptic Curve] [http://en.wikipedia.org/wiki/Digital_Signature_Algorithm Digital Signature Algorithm] ([http://en.wikipedia.org/wiki/Elliptic_Curve_DSA ECDSA]) to sign transactions. <br />
<br />
For ECDSA the secp256k1 curve from http://www.secg.org/collateral/sec2_final.pdf is used.<br />
<br />
Public keys (in scripts) are given as 04 <x> <y> where ''x'' and ''y'' are 32 byte big-endian integers representing the coordinates of a point on the curve or in compressed form given as <sign> <x> where <sign> is 0x02 if ''y'' is even and 0x03 if ''y'' is odd.<br />
<br />
Signatures use [http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules DER encoding] to pack the ''r'' and ''s'' components into a single byte stream (this is also what OpenSSL produces by default).<br />
<br />
=== Transaction Verification ===<br />
Transactions are cryptographically signed records that reassign ownership of Bitcoins to new addresses. Transactions have ''inputs'' - records which reference the funds from other previous transactions - and ''outputs'' - records which determine the new owner of the transferred Bitcoins, and which will be referenced as inputs in future transactions as those funds are respent.<br />
<br />
Each ''input'' must have a cryptographic digital signature that unlocks the funds from the prior transaction. Only the person possessing the appropriate [[private key]] is able to create a satisfactory signature; this in effect ensures that funds can only be spent by their owners.<br />
<br />
Each ''output'' determines which Bitcoin address (or other criteria, see [[Scripting]]) is the recipient of the funds.<br />
<br />
In a transaction, the sum of all inputs must be equal to or greater than the sum of all outputs. If the inputs exceed the outputs, the difference is considered a [[transaction fee]], and is redeemable by whoever first includes the transaction into the block chain.<br />
<br />
A special kind of transaction, called a [[coinbase transaction]], has no inputs. It is created by [[miners]], and there is one coinbase transaction per block. Because each block comes with a reward of newly created Bitcoins (e.g. 50 BTC for the first 210,000 blocks), the first transaction of a block is, with few exceptions, the transaction that grants those coins to their recipient (the miner). In addition to the newly created Bitcoins, the coinbase transaction is also used for assigning the recipient of any transaction fees that were paid within the other transactions being included in the same block. The coinbase transaction can assign the entire reward to a single Bitcoin address, or split it in portions among multiple addresses, just like any other transaction. Coinbase transactions always contain outputs totaling the sum of the block reward plus all transaction fees collected from the other transactions in the same block.<br />
<br />
The [[coinbase transaction]] in block zero cannot be spent. This is due to a quirk of the reference client implementation that would open the potential for a block chain fork if some nodes accepted the spend and others did not<ref>[http://bitcointalk.org/index.php?topic=119645.msg1288552#msg1288552 Block 0 Network Fork]</ref>.<br />
<br />
Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key. The actual record saved with inputs and outputs isn't necessarily a key, but a ''script''. Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied, with which more complex operations are possible, such as outputs that require two ECDSA signatures, or two-of-three-signature schemes. An output that references a single Bitcoin address is a ''typical'' output; an output actually contains this information in the form of a script that requires a single ECDSA signature (see [[OP_CHECKSIG]]). The output script specifies what must be provided to unlock the funds later, and when the time comes in the future to spend the transaction in another input, that input must provide all of the thing(s) that satisfy the requirements defined by the original output script.<br />
<br />
=== Addresses ===<br />
<br />
A bitcoin address is in fact the hash of a ECDSA public key, computed this way:<br />
<br />
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111<br />
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))<br />
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))<br />
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)<br />
<br />
The Base58 encoding used is home made, and has some differences. Especially, leading zeroes are kept as single zeroes when conversion happens.<br />
<br />
== Common structures ==<br />
<br />
Almost all integers are encoded in little endian. Only IP or port number are encoded big endian.<br />
<br />
=== Message structure ===<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || magic || uint32_t || Magic value indicating message origin network, and used to seek to next message when stream state is unknown<br />
|-<br />
| 12 || command || char[12] || ASCII string identifying the packet content, NULL padded (non-NULL padding results in packet rejected)<br />
|-<br />
| 4 || length || uint32_t || Length of payload in number of bytes<br />
|-<br />
| 4 || checksum || uint32_t || First 4 bytes of sha256(sha256(payload))<br />
|-<br />
| ? || payload || uchar[] || The actual data<br />
|}<br />
<br />
<br />
Known magic values:<br />
<br />
{|class="wikitable"<br />
! Network !! Magic value !! Sent over wire as<br />
|-<br />
| main || 0xD9B4BEF9 || F9 BE B4 D9<br />
|-<br />
| testnet || 0xDAB5BFFA || FA BF B5 DA<br />
|-<br />
| testnet3 || 0x0709110B || 0B 11 09 07<br />
|}<br />
<br />
=== Variable length integer ===<br />
<br />
Integer can be encoded depending on the represented value to save space.<br />
Variable length integers always precede an array/vector of a type of data that may vary in length.<br />
Longer numbers are encoded in little endian.<br />
<br />
{|class="wikitable"<br />
! Value !! Storage length !! Format<br />
|-<br />
| < 0xfd || 1 || uint8_t<br />
|-<br />
| <= 0xffff || 3 || 0xfd followed by the length as uint16_t<br />
|-<br />
| <= 0xffffffff || 5 || 0xfe followed by the length as uint32_t<br />
|-<br />
| - || 9 || 0xff followed by the length as uint64_t<br />
|}<br />
<br />
Footnote - if you're reading the Satoshi client code it refers to this as a "CompactSize" - VarInt's are something entirely different to the Satoshi code.<br />
<br />
=== Variable length string ===<br />
<br />
Variable length string can be stored using a variable length integer followed by the string itself.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the string<br />
|-<br />
| ? || string || char[] || The string itself (can be empty)<br />
|}<br />
<br />
=== Network address ===<br />
<br />
When a network address is needed somewhere, this structure is used. This protocol and structure supports IPv6, '''but note that the original client currently only supports IPv4 networking'''. Network addresses are not prefixed with a timestamp in the version message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || time || uint32 || the Time (version >= 31402)<br />
|-<br />
| 8 || services || uint64_t || same service(s) listed in [[#version|version]]<br />
|-<br />
| 16 || IPv6/4 || char[16] || IPv6 address. Network byte order. The original client only supports IPv4 and only reads the last 4 bytes to get the IPv4 address. However, the IPv4 address is written into the message as a 16 byte [http://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses IPv4-mapped IPv6 address]<br />
(12 bytes ''00 00 00 00 00 00 00 00 00 00 FF FF'', followed by the 4 bytes of the IPv4 address).<br />
|-<br />
| 2 || port || uint16_t || port number, network byte order<br />
|}<br />
<br />
Hexdump example of Network address structure<br />
<br />
<pre><br />
0000 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0010 00 00 FF FF 0A 00 00 01 20 8D ........ .<br />
<br />
Network address:<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK: see services listed under version command)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv6: ::ffff:10.0.0.1 or IPv4: 10.0.0.1<br />
20 8D - Port 8333<br />
</pre><br />
<br />
=== Inventory Vectors ===<br />
<br />
Inventory vectors are used for notifying other nodes about objects they have or data which is being requested.<br />
<br />
Inventory vectors consist of the following data format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || type || uint32_t || Identifies the object type linked to this inventory<br />
|-<br />
| 32 || hash || char[32] || Hash of the object<br />
|}<br />
<br />
<br />
The object type is currently defined as one of the following possibilities:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || ERROR || Any data of with this number may be ignored<br />
|-<br />
| 1 || MSG_TX || Hash is related to a transaction<br />
|-<br />
| 2 || MSG_BLOCK || Hash is related to a data block<br />
|}<br />
<br />
Other Data Type values are considered reserved for future implementations.<br />
<br />
=== Block Headers ===<br />
<br />
Block headers are sent in a headers packet in response to a getheaders message.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transaction entries, this value is always 0<br />
|}<br />
<br />
== Message types ==<br />
<br />
=== version ===<br />
<br />
When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || int32_t || Identifies protocol version being used by the node<br />
|-<br />
| 8 || services || uint64_t || bitfield of features to be enabled for this connection<br />
|-<br />
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds<br />
|-<br />
| 26 || addr_recv || net_addr || The network address of the node receiving this message<br />
|-<br />
|colspan="4"| version >= 106<br />
|-<br />
| 26 || addr_from || net_addr || The network address of the node emitting this message<br />
|-<br />
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.<br />
|-<br />
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)<br />
|-<br />
| 4 || start_height || int32_t || The last block received by the emitting node<br />
|}<br />
<br />
A "verack" packet shall be sent if the version packet was accepted.<br />
<br />
The following services are currently assigned:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.<br />
|}<br />
<br />
Hexdump example of version message (OBSOLETE EXAMPLE. This example lacks a checksum and user-agent):<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 73 69 6F 6E 00 00 00 00 00 ....version.....<br />
0010 55 00 00 00 9C 7C 00 00 01 00 00 00 00 00 00 00 U....|..........<br />
0020 E6 15 10 4D 00 00 00 00 01 00 00 00 00 00 00 00 ...M............<br />
0030 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 ................<br />
0040 20 8D 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 FF FF 0A 00 00 02 20 8D DD 9D 20 2C .......... ... ,<br />
0060 3A B4 57 13 00 55 81 01 00 :.W..U...<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
55 00 00 00 - Payload is 85 bytes long<br />
- No checksum in version message until 20 February 2012. See https://bitcointalk.org/index.php?topic=55852.0<br />
Version message:<br />
9C 7C 00 00 - 31900 (version 0.3.19)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
E6 15 10 4D 00 00 00 00 - Mon Dec 20 21:50:14 EST 2010<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 20 8D - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 02 20 8D - Sender address info - see Network Address<br />
DD 9D 20 2C 3A B4 57 13 - Node random unique ID<br />
00 - "" sub-version string (string is 0 bytes long)<br />
55 81 01 00 - Last block sending node has is block #98645<br />
</pre><br />
<br />
And here's a modern (60002) protocol version client advertising itself to a local peer...<br />
<br />
Newer protocol includes the checksum now, this is from a mainline (satoshi) client during <br />
an outgoing connection to another local client, notice that it does not fill out the <br />
address information at all when the source or destination is "unroutable".<br />
<br />
<pre><br />
<br />
0000 f9 be b4 d9 76 65 72 73 69 6f 6e 00 00 00 00 00 ....version.....<br />
0010 64 00 00 00 35 8d 49 32 62 ea 00 00 01 00 00 00 d...5.I2b.......<br />
0020 00 00 00 00 11 b2 d0 50 00 00 00 00 01 00 00 00 .......P........<br />
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ................<br />
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0050 00 00 00 00 00 00 00 00 ff ff 00 00 00 00 00 00 ................<br />
0060 3b 2e b3 5d 8c e6 17 65 0f 2f 53 61 74 6f 73 68 ;..]...e./Satosh<br />
0070 69 3a 30 2e 37 2e 32 2f c0 3e 03 00 i:0.7.2/.>..<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 73 69 6F 6E 00 00 00 00 00 - "version" command<br />
64 00 00 00 - Payload is 100 bytes long<br />
35 8D 49 32 - payload checksum<br />
<br />
Version message:<br />
62 EA 00 00 - 60002 (protocol version 60002)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK services)<br />
11 B2 D0 50 00 00 00 00 - Tue Dec 18 10:12:33 PST 2012<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Recipient address info - see Network Address<br />
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF 00 00 00 00 00 00 - Sender address info - see Network Address<br />
3B 2E B3 5D 8C E6 17 65 - Node ID<br />
0F 2F 53 61 74 6F 73 68 69 3A 30 2E 37 2E 32 2F - "/Satoshi:0.7.2/" sub-version string (string is 15 bytes long)<br />
C0 3E 03 00 - Last block sending node has is block #212672<br />
</pre><br />
<br />
<br />
<br />
=== verack ===<br />
<br />
The ''verack'' message is sent in reply to ''version''. This message consists of only a [[#Message structure|message header]] with the command string "verack".<br />
<br />
Hexdump of the verack message:<br />
<br />
<pre><br />
0000 F9 BE B4 D9 76 65 72 61 63 6B 00 00 00 00 00 00 ....verack......<br />
0010 00 00 00 00 5D F6 E0 E2 ........<br />
<br />
Message header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
76 65 72 61 63 6B 00 00 00 00 00 00 - "verack" command<br />
00 00 00 00 - Payload is 0 bytes long<br />
5D F6 E0 E2 - Checksum<br />
</pre><br />
<br />
=== addr ===<br />
<br />
Provide information on known nodes of the network. Non-advertised nodes should be forgotten after typically 3 hours<br />
<br />
Payload:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1+ || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of address entries (max: 1000)<br />
|-<br />
| 30x? || addr_list || (uint32_t + net_addr)[] || Address of other nodes on the network. version < 209 will only read the first one. The uint32_t is a timestamp (see note below).<br />
|}<br />
<br />
'''Note''': Starting version 31402, addresses are prefixed with a timestamp. If no timestamp is present, the addresses should not be relayed to other peers, unless it is indeed confirmed they are up.<br />
<br />
Hexdump example of ''addr'' message:<br />
<pre><br />
0000 F9 BE B4 D9 61 64 64 72 00 00 00 00 00 00 00 00 ....addr........<br />
0010 1F 00 00 00 ED 52 39 9B 01 E2 15 10 4D 01 00 00 .....R9.....M...<br />
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF ................<br />
0030 FF 0A 00 00 01 20 8D ..... .<br />
<br />
Message Header:<br />
F9 BE B4 D9 - Main network magic bytes<br />
61 64 64 72 00 00 00 00 00 00 00 00 - "addr"<br />
1F 00 00 00 - payload is 31 bytes long<br />
ED 52 39 9B - checksum of payload<br />
<br />
Payload:<br />
01 - 1 address in this message<br />
<br />
Address:<br />
E2 15 10 4D - Mon Dec 20 21:50:10 EST 2010 (only when version is >= 31402)<br />
01 00 00 00 00 00 00 00 - 1 (NODE_NETWORK service - see version message)<br />
00 00 00 00 00 00 00 00 00 00 FF FF 0A 00 00 01 - IPv4: 10.0.0.1, IPv6: ::ffff:10.0.0.1 (IPv4-mapped IPv6 address)<br />
20 8D - port 8333<br />
</pre><br />
<br />
=== inv ===<br />
<br />
Allows a node to advertise its knowledge of one or more objects. It can be received unsolicited, or in reply to ''getblocks''.<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getdata ===<br />
<br />
getdata is used in response to inv, to retrieve the content of a specific object, and is usually sent after receiving an ''inv'' packet, after filtering known elements. It can be used to retrieve transactions, but only if they are in the memory pool or relay set - arbitrary access to transactions in the chain is not allowed to avoid having clients start to depend on nodes having full transaction indexes (which modern nodes do not).<br />
<br />
Payload (maximum payload length: 1.8 Megabytes or 50000 entries):<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== notfound ===<br />
<br />
notfound is a response to a getdata, sent if any requested data items could not be relayed, for example, because the requested transaction was not in the memory pool or relay set.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of inventory entries<br />
|-<br />
| 36x? || inventory || [[Protocol specification#Inventory Vectors|inv_vect]][] || Inventory vectors<br />
|}<br />
<br />
=== getblocks ===<br />
<br />
Return an ''inv'' packet containing the list of blocks starting right after the last known hash in the block locator object, up to hash_stop or 500 blocks, whichever comes first. To receive the next blocks hashes, one needs to issue getblocks again with a new block locator object. Keep in mind that some clients (specifically the Satoshi client) will gladly provide blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block; set to zero to get as many blocks as possible (500)<br />
|}<br />
<br />
To create the block locator hashes, keep pushing hashes until you go back to the genesis block. After pushing 10 hashes back, the step backwards doubles every loop:<br />
<br />
<pre><br />
// From libbitcoin which is under AGPL<br />
std::vector<size_t> block_locator_indices(int top_depth)<br />
{<br />
// Start at max_depth<br />
std::vector<size_t> indices;<br />
// Push last 10 indices first<br />
size_t step = 1, start = 0;<br />
for (int i = top_depth; i > 0; i -= step, ++start)<br />
{<br />
if (start >= 10)<br />
step *= 2;<br />
indices.push_back(i);<br />
}<br />
indices.push_back(0);<br />
return indices;<br />
}<br />
</pre><br />
<br />
Note that it is allowed to send in fewer known hashes down to a minimum of just one hash. However, the purpose of the block locator object is to detect a wrong branch in the caller's main chain. If the peer detects that you are off the main chain, it will send in block hashes which are earlier than your last known block. So if you just send in your last known hash and it is off the main chain, the peer starts over at block #1.<br />
<br />
=== getheaders ===<br />
<br />
Return a ''headers'' packet containing the headers of blocks starting right after the last known hash in the block locator object, up to hash_stop or 2000 blocks, whichever comes first. To receive the next block headers, one needs to issue getheaders again with a new block locator object. The ''getheaders'' command is used by thin clients to quickly download the blockchain where the contents of the transactions would be irrelevant (because they are not ours). Keep in mind that some clients (specifically the Satoshi client) will gladly provide headers of blocks which are invalid if the block locator object contains a hash on the invalid branch.<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || the protocol version<br />
|-<br />
| 1+ || hash count || [[Protocol_specification#Variable_length_integer|var_int]] || number of block locator hash entries<br />
|-<br />
| 32+ || block locator hashes || char[32] || block locator object; newest back to genesis block (dense to start, but then sparse)<br />
|-<br />
| 32 || hash_stop || char[32] || hash of the last desired block header; set to zero to get as many blocks as possible (2000)<br />
|}<br />
<br />
For the block locator object in this packet, the same rules apply as for the [[Protocol_specification#getblocks|getblocks]] packet.<br />
<br />
=== tx ===<br />
<br />
''tx'' describes a bitcoin transaction, in reply to ''getdata''<br />
<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Transaction data format version<br />
|-<br />
| 1+ || tx_in count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction inputs<br />
|-<br />
| 41+ || tx_in || tx_in[] || A list of 1 or more transaction inputs or sources for coins<br />
|-<br />
| 1+ || tx_out count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of Transaction outputs<br />
|-<br />
| 8+ || tx_out || tx_out[] || A list of 1 or more transaction outputs or destinations for coins<br />
|-<br />
| 4 || lock_time || uint32_t || The block number or timestamp at which this transaction is locked:<br />
{|class="wikitable"<br />
! Value !! Description<br />
|-<br />
| 0 || Always locked<br />
|-<br />
| < 500000000 || Block number at which this transaction is locked<br />
|-<br />
| >= 500000000 || UNIX timestamp at which this transaction is locked<br />
|}<br />
If all TxIn inputs have final (0xffffffff) sequence numbers then lock_time is irrelevant. Otherwise, the transaction may not be added to a block until after lock_time.<br />
<br />
|}<br />
<br />
TxIn consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 36 || previous_output || outpoint || The previous output transaction reference, as an OutPoint structure<br />
|-<br />
| 1+ || script length || [[Protocol_specification#Variable_length_integer|var_int]] || The length of the signature script<br />
|-<br />
| ? || signature script || uchar[] || Computational Script for confirming transaction authorization<br />
|-<br />
| 4 || [http://bitcoin.stackexchange.com/q/2025/323 sequence] || uint32_t || Transaction version as defined by the sender. Intended for "replacement" of transactions when information is updated before inclusion into a block.<br />
|}<br />
<br />
The OutPoint structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || The hash of the referenced transaction.<br />
|-<br />
| 4 || index || uint32_t || The index of the specific output in the transaction. The first output is 0, etc.<br />
|}<br />
<br />
The Script structure consists of a series of pieces of information and operations related to the value of the transaction.<br />
<br />
(Structure to be expanded in the future… see script.h and script.cpp and [[Script]] for more information)<br />
<br />
The TxOut structure consists of the following fields:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 8 || value || int64_t || Transaction Value<br />
|-<br />
| 1+ || pk_script length || [[Protocol_specification#Variable_length_integer|var_int]] || Length of the pk_script<br />
|-<br />
| ? || pk_script || uchar[] || Usually contains the public key as a Bitcoin script setting up conditions to claim this output.<br />
|}<br />
<br />
Example ''tx'' message:<br />
<pre><br />
000000 F9 BE B4 D9 74 78 00 00 00 00 00 00 00 00 00 00 ....tx..........<br />
000010 02 01 00 00 E2 93 CD BE 01 00 00 00 01 6D BD DB .............m..<br />
000020 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D 12 66 E9 .[...Q........f.<br />
000030 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29 00 00 00 .;P......j.6)...<br />
000040 00 8B 48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 ..H0E.!..X..r...<br />
000050 C7 36 7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A .6zz%;..R#...h.:<br />
000060 59 23 3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 Y#?E.W... Y.....<br />
000070 0E 41 83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D .A.z.X.z...XN...<br />
000080 35 BD 96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF 5...6..;...A....<br />
000090 C9 7E F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 .~.6.m...@..!...<br />
0000A0 2A CD 2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC *.+..].}Y... ...<br />
0000B0 4E 02 53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F N.S..=7.o...Q...<br />
0000C0 14 04 2F 46 61 4A 4C 70 C0 F1 4B EF F5 FF FF FF ../FaJLp..K.....<br />
0000D0 FF 02 40 4B 4C 00 00 00 00 00 19 76 A9 14 1A A0 ..@KL......v....<br />
0000E0 CD 1C BE A6 E7 45 8A 7A BA D5 12 A9 D9 EA 1A FB .....E.z........<br />
0000F0 22 5E 88 AC 80 FA E9 C7 00 00 00 00 19 76 A9 14 "^...........v..<br />
000100 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E FD A0 B7 ..[.Cj.....H^...<br />
000110 8B 4E CC 52 88 AC 00 00 00 00 .N.R......<br />
<br />
<br />
Message header:<br />
F9 BE B4 D9 - main network magic bytes<br />
74 78 00 00 00 00 00 00 00 00 00 00 - "tx" command<br />
02 01 00 00 - payload is 258 bytes long<br />
E2 93 CD BE - checksum of payload<br />
<br />
Transaction:<br />
01 00 00 00 - version<br />
<br />
Inputs:<br />
01 - number of transaction inputs<br />
<br />
Input 1:<br />
6D BD DB 08 5B 1D 8A F7 51 84 F0 BC 01 FA D5 8D - previous output (outpoint)<br />
12 66 E9 B6 3B 50 88 19 90 E4 B4 0D 6A EE 36 29<br />
00 00 00 00<br />
<br />
8B - script is 139 bytes long<br />
<br />
48 30 45 02 21 00 F3 58 1E 19 72 AE 8A C7 C7 36 - signature script (scriptSig)<br />
7A 7A 25 3B C1 13 52 23 AD B9 A4 68 BB 3A 59 23<br />
3F 45 BC 57 83 80 02 20 59 AF 01 CA 17 D0 0E 41<br />
83 7A 1D 58 E9 7A A3 1B AE 58 4E DE C2 8D 35 BD<br />
96 92 36 90 91 3B AE 9A 01 41 04 9C 02 BF C9 7E<br />
F2 36 CE 6D 8F E5 D9 40 13 C7 21 E9 15 98 2A CD<br />
2B 12 B6 5D 9B 7D 59 E2 0A 84 20 05 F8 FC 4E 02<br />
53 2E 87 3D 37 B9 6F 09 D6 D4 51 1A DA 8F 14 04<br />
2F 46 61 4A 4C 70 C0 F1 4B EF F5<br />
<br />
FF FF FF FF - sequence<br />
<br />
Outputs:<br />
02 - 2 Output Transactions<br />
<br />
Output 1:<br />
40 4B 4C 00 00 00 00 00 - 0.05 BTC (5000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 1A A0 CD 1C BE A6 E7 45 8A 7A BA D5 12 - pk_script<br />
A9 D9 EA 1A FB 22 5E 88 AC<br />
<br />
Output 2:<br />
80 FA E9 C7 00 00 00 00 - 33.54 BTC (3354000000)<br />
19 - pk_script is 25 bytes long<br />
<br />
76 A9 14 0E AB 5B EA 43 6A 04 84 CF AB 12 48 5E - pk_script<br />
FD A0 B7 8B 4E CC 52 88 AC<br />
<br />
Locktime:<br />
00 00 00 00 - lock time<br />
</pre><br />
<br />
=== block ===<br />
<br />
The '''block''' message is sent in response to a getdata message which requests transaction information from a block hash.<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A unix timestamp recording when this block was created (Currently limited to dates before the year 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated [[Difficulty|difficulty target]] being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| ? || txn_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of transaction entries<br />
|-<br />
| ? || txns || tx[] || Block transactions, in format of "tx" command<br />
|}<br />
<br />
The SHA256 hash that identifies each block (and which must have a run of 0 bits) is calculated from the first 6 fields of this structure (version, prev_block, merkle_root, timestamp, bits, nonce, and standard SHA256 padding, making two 64-byte chunks in all) and ''not'' from the complete block. To calculate the hash, only two chunks need to be processed by the SHA256 algorithm. Since the ''nonce'' field is in the second chunk, the first chunk stays constant during mining and therefore only the second chunk needs to be processed. However, a Bitcoin hash is the hash of the hash, so two SHA256 rounds are needed for each mining iteration.<br />
See [[Block hashing algorithm]] for details and an example.<br />
<br />
=== headers ===<br />
<br />
The ''headers'' packet returns block headers in response to a ''getheaders'' packet. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of block headers<br />
|-<br />
| 81x? || headers || [[Protocol_specification#Block_Headers|block_header]][] || [[Protocol_specification#Block_Headers|Block headers]]<br />
|}<br />
<br />
Note that the block headers in this packet include a transaction count (a var_int, so there can be more than 81 bytes per header) as opposed to the block headers which are sent to miners.<br />
<br />
=== getaddr ===<br />
<br />
The getaddr message sends a request to a node asking for information about known active peers to help with identifying potential nodes in the network. The response to receiving this message is to transmit an addr message with one or more peers from a database of known active peers. The typical presumption is that a node is likely to be active if it has been sending a message within the last three hours.<br />
<br />
No additional data is transmitted with this message.<br />
<br />
=== checkorder ===<br />
<br />
This message is used for [[IP Transactions]], to ask the peer if it accepts such transactions and allow it to look at the content of the order.<br />
<br />
It contains a CWalletTx object<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
|colspan="4"| Fields from CMerkleTx<br />
|-<br />
| ? || hashBlock<br />
|-<br />
| ? || vMerkleBranch<br />
|-<br />
| ? || nIndex<br />
|-<br />
|colspan="4"| Fields from CWalletTx<br />
|-<br />
| ? || vtxPrev<br />
|-<br />
| ? || mapValue<br />
|-<br />
| ? || vOrderForm<br />
|-<br />
| ? || fTimeReceivedIsTxTime<br />
|-<br />
| ? || nTimeReceived<br />
|-<br />
| ? || fFromMe<br />
|-<br />
| ? || fSpent<br />
|}<br />
<br />
=== submitorder ===<br />
<br />
Confirms an order has been submitted. <br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 32 || hash || char[32] || Hash of the transaction<br />
|-<br />
| ? || wallet_entry || CWalletTx || Same payload as checkorder<br />
|}<br />
<br />
=== reply ===<br />
<br />
Generic reply for [[IP Transactions]]<br />
<br />
Payload:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || reply || uint32_t || reply code<br />
|}<br />
<br />
Possible values:<br />
<br />
{|class="wikitable"<br />
! Value !! Name !! Description<br />
|-<br />
| 0 || SUCCESS || The IP Transaction can proceed (''checkorder''), or has been accepted (''submitorder'')<br />
|-<br />
| 1 || WALLET_ERROR || AcceptWalletTransaction() failed<br />
|-<br />
| 2 || DENIED || IP Transactions are not accepted by this node<br />
|}<br />
<br />
=== ping ===<br />
<br />
The ''ping'' message is sent primarily to confirm that the TCP/IP connection is still valid. An error in transmission is presumed to be a closed connection and the address is removed as a current peer. No reply is expected as a result of this message being sent nor any sort of action expected on the part of a client when it is used.<br />
<br />
=== alert ===<br />
<br />
An '''alert''' is sent between nodes to send a general notification message throughout the network. If the alert can be confirmed with the signature as having come from the the core development group of the Bitcoin software, the message is suggested to be displayed for end-users. Attempts to perform transactions, particularly automated transactions through the client, are suggested to be halted. The text in the Message string should be relayed to log files and any user interfaces.<br />
<br />
Alert format:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || payload || var_str || Serialized alert payload<br />
|-<br />
| ? || signature || var_str || An ECDSA signature of the message<br />
|}<br />
<br />
The developers of Satoshi's client use this public key for signing alerts:<br />
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284<br />
(hash) 1AGRxqDa5WjUKBwHB9XYEjmkv1ucoUUy1s<br />
<br />
The payload is serialized into a var_str to ensure that versions using incompatible alert formats can still relay alerts among one another. The current alert payload format is:<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || Version || int32_t || Alert format version<br />
|-<br />
| 8 || RelayUntil || int64_t || The timestamp beyond which nodes should stop relaying this alert<br />
|-<br />
| 8 || Expiration || int64_t || The timestamp beyond which this alert is no longer in effect and should be ignored<br />
|-<br />
| 4 || ID || int32_t || A unique ID number for this alert<br />
|-<br />
| 4 || Cancel || int32_t || All alerts with an ID number less than or equal to this number should be canceled: deleted and not accepted in the future<br />
|-<br />
| ? || setCancel || set<int> || All alert IDs contained in this set should be canceled as above<br />
|-<br />
| 4 || MinVer || int32_t || This alert only applies to versions greater than or equal to this version. Other versions should still relay it.<br />
|-<br />
| 4 || MaxVer || int32_t || This alert only applies to versions less than or equal to this version. Other versions should still relay it.<br />
|-<br />
| ? || setSubVer || set<string> || If this set contains any elements, then only nodes that have their subVer contained in this set are affected by the alert. Other versions should still relay it.<br />
|-<br />
| 4 || Priority || int32_t || Relative priority compared to other alerts<br />
|-<br />
| ? || Comment || string || A comment on the alert that is not displayed<br />
|-<br />
| ? || StatusBar || string || The alert message that is displayed to the user<br />
|-<br />
| ? || Reserved || string || Reserved<br />
|}<br />
<br />
Sample alert (no message header):<br />
73010000003766404f00000000b305434f00000000f2030000f1030000001027000048ee0000<br />
0064000000004653656520626974636f696e2e6f72672f666562323020696620796f75206861<br />
76652074726f75626c6520636f6e6e656374696e672061667465722032302046656272756172<br />
79004730450221008389df45f0703f39ec8c1cc42c13810ffcae14995bb648340219e353b63b<br />
53eb022009ec65e1c1aaeec1fd334c6b684bde2b3f573060d5b70c3a46723326e4e8a4f1<br />
<br />
Version: 1<br />
RelayUntil: 1329620535<br />
Expiration: 1329792435<br />
ID: 1010<br />
Cancel: 1009<br />
setCancel: <empty><br />
MinVer: 10000<br />
MaxVer: 61000<br />
setSubVer: <empty><br />
Priority: 100<br />
Comment: <empty><br />
StatusBar: "See bitcoin.org/feb20 if you have trouble connecting after 20 February"<br />
Reserved: <empty><br />
<br />
== Scripting ==<br />
<br />
See [[script]].<br />
<br />
== Wireshark dissector ==<br />
A dissector for wireshark is being developed at https://github.com/blueCommand/bitcoin-dissector<br />
<br />
==See Also==<br />
<br />
* [[Network]]<br />
* [[Protocol rules]]<br />
* [[Hardfork Wishlist]]<br />
<br />
==References==<br />
<references /><br />
<br />
[[zh-cn:协议说明]]<br />
[[Category:Technical]]<br />
[[Category:Developer]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Bitcoin_Improvement_Proposals&diff=35652Bitcoin Improvement Proposals2013-02-20T12:44:14Z<p>Mike: BIP 37 is accepted.</p>
<hr />
<div>People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.<br />
<br />
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.<br />
<br />
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.<br />
<br />
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: [[economic majority]]).<br />
<br />
{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"<br />
!Number<br />
!Title<br />
!Owner<br />
!Status<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0001|1]]<br />
| BIP Purpose and Guidelines<br />
| Amir Taaki<br />
| Active<br />
|-<br />
| [[BIP 0010|10]]<br />
| Multi-Sig Transaction Distribution<br />
| Alan Reiner<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0011|11]]<br />
| M-of-N Standard Transactions<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0012|12]]<br />
| OP_EVAL<br />
| Gavin Andresen<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0013|13]]<br />
| Address Format for pay-to-script-hash<br />
| Gavin Andresen<br />
| Final<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0014|14]]<br />
| Protocol Version and User Agent<br />
| Amir Taaki, Patrick Strateman<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0015|15]]<br />
| Aliases<br />
| Amir Taaki<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0016|16]]<br />
| Pay To Script Hash<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0017|17]]<br />
| OP_CHECKHASHVERIFY (CHV)<br />
| Luke Dashjr<br />
| Withdrawn<br />
|-<br />
| [[BIP 0018|18]]<br />
| hashScriptCheck<br />
| Luke Dashjr<br />
| Draft<br />
|-<br />
| [[BIP 0019|19]]<br />
| M-of-N Standard Transactions (Low SigOp)<br />
| Luke Dashjr<br />
| Draft<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0020|20]]<br />
| URI Scheme<br />
| Luke Dashjr<br />
| Replaced<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0021|21]]<br />
| URI Scheme<br />
| Nils Schneider, Matt Corallo<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0022|22]]<br />
| getblocktemplate - Fundamentals<br />
| Luke Dashjr<br />
| Accepted<br />
|-<br />
| [[BIP 0023|23]]<br />
| getblocktemplate - Pooled Mining<br />
| Luke Dashjr<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0030|30]]<br />
| Duplicate transactions<br />
| Pieter Wuille<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0031|31]]<br />
| Pong message<br />
| Mike Hearn<br />
| Accepted<br />
|-<br />
| [[BIP 0032|32]]<br />
| Hierarchical Deterministic Wallets<br />
| Pieter Wuille<br />
| Draft<br />
|-<br />
| [[BIP 0033|33]]<br />
| Stratized Nodes<br />
| Amir Taaki<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0034|34]]<br />
| Block v2, Height in coinbase<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0035|35]]<br />
| mempool message<br />
| Jeff Garzik<br />
| Accepted<br />
|-<br />
| [[BIP 0036|36]]<br />
| Custom Services<br />
| Stefan Thomas<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0037|37]]<br />
| Bloom filtering<br />
| Mike Hearn and Matt Corallo<br />
| Accepted<br />
|- <br />
| [[BIP 0039|39]]<br />
| Deterministic key mnemonics<br />
| Slush<br />
| BIP number allocated<br />
|}<br />
<br />
[[Hardfork Wishlist]]<br />
<br />
[[Category:BIP|Z]]<br />
<br />
[[es:Propuestas de mejora de Bitcoin]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=BIP_0037&diff=35651BIP 00372013-02-20T12:43:46Z<p>Mike: Update to the latest version of the protocol.</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 37<br />
Title: Connection Bloom filtering<br />
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me><br />
Status: Accepted<br />
Type: Standards Track<br />
Created: 24-10-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.<br />
<br />
This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.<br />
<br />
==Motivation==<br />
<br />
As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.<br />
<br />
Today, [[Simplified_Payment_Verification|SPV]] clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.<br />
<br />
==Design rationale==<br />
<br />
The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:<br />
<br />
* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).<br />
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.<br />
<br />
==Specification==<br />
<br />
===New messages===<br />
<br />
We start by adding three new messages to the protocol:<br />
<br />
* <code>filterload</code>, which sets the current Bloom filter on the connection<br />
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set<br />
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.<br />
<br />
Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.<br />
<br />
The <code>filterload</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.<br />
|-<br />
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.<br />
|-<br />
| 4 || nTweak || uint32_t || A random value to add to the seed value in the hash function used by the bloom filter.<br />
|-<br />
| 1 || nFlags || uint8_t || A set of flags that control how matched items are added to the filter.<br />
|}<br />
<br />
See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.<br />
<br />
Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below. The flags control the update behaviour of the matching algorithm.<br />
<br />
The <code>filteradd</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || data || uint8_t[] || The data element to add to the current filter.<br />
|}<br />
<br />
The data field must be smaller than or equal to 520 bytes in size (the maximum size of any potentially matched object).<br />
<br />
The given data element will be added to the Bloom filter. A filter must have been previously provided using <code>filterload</code>. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer (though doing so is usually advisable to maintain anonymity).<br />
<br />
The <code>filterclear</code> command has no arguments at all.<br />
<br />
After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 4 || total_transactions || uint32_t || Number of transactions in the block (including unmatched ones)<br />
|-<br />
| ? || hashes || uint256[] || hashes in depth-first order (including standard varint size prefix)<br />
|-<br />
| ? || flags || byte[] || flag bits, packed per 8 in a byte, least significant bit first (including standard varint size prefix)<br />
|}<br />
<br />
See below for the format of the partial merkle tree hashes and flags.<br />
<br />
Thus, a <code>merkleblock</code> message is a block header, plus a part of a merkle tree which can be used to extract identifying information for transactions that matched the filter and prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.<br />
<br />
===Extensions to existing messages===<br />
<br />
The <code>version</code> command is extended with a new field:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.<br />
|}<br />
<br />
SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.<br />
<br />
The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, transactions matching the filter should also be sent in separate tx messages after the merkleblock is sent. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them). Note that because there is currently no way to request transactions which are already in a block from a node (aside from requesting the full block), the set of matching transactions that the requesting node hasn't either received or announced with an inv must be sent and any additional transactions which match the filter may also be sent. This allows for clients (such as the reference client) to limit the number of invs it must remember a given node to have announced while still providing nodes with, at a minimum, all the transactions it needs.<br />
<br />
===Filter matching algorithm===<br />
<br />
The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.<br />
<br />
To determine if a transaction matches the filter, the following algorithm is used. Once a match is found the algorithm aborts.<br />
<br />
# Test the hash of the transaction itself.<br />
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node might need to update the filter by inserting the serialized COutPoint structure. See below for more details.<br />
# For each input, test the serialized COutPoint structure.<br />
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).<br />
# Otherwise there is no match.<br />
<br />
In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].<br />
<br />
The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:<br />
<br />
# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.<br />
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.<br />
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.<br />
<br />
By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.<br />
<br />
The nFlags field of the filter controls the nodes precise update behaviour and is a bit field.<br />
<br />
* <code>BLOOM_UPDATE_NONE (0)</code> means the filter is not adjusted when a match is found.<br />
* <code>BLOOM_UPDATE_ALL (1)</code> means if the filter matches any data element in a scriptPubKey the outpoint is serialized and inserted into the filter.<br />
* <code>BLOOM_UPDATE_P2PUBKEY_ONLY (2)</code> means the outpoint is inserted into the filter only if a data element in the scriptPubKey is matched, and that script is of the standard "pay to pubkey" or "pay to multisig" forms.<br />
<br />
These distinctions are useful to avoid too-rapid degradation of the filter due to an increasing false positive rate. We can observe that a wallet which expects to receive only payments of the standard pay-to-address form doesn't need automatic filter updates because any transaction that spends one of its own outputs has a predictable data element in the input (the pubkey that hashes to the address). If a wallet might receive pay-to-address outputs and also pay-to-pubkey or pay-to-multisig outputs then BLOOM_UPDATE_P2PUBKEY_ONLY is appropriate, as it avoids unnecessary expansions of the filter for the most common types of output but still ensures correct behaviour with payments that explicitly specify keys.<br />
<br />
Obviously, nFlags == 1 or nFlags == 2 mean that the filter will get dirtier as more of the chain is scanned. Clients should monitor the observed false positive rate and periodically refresh the filter with a clean one.<br />
<br />
===Partial Merkle branch format===<br />
<br />
A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.<br />
<br />
The encoding works as follows: we traverse the tree in depth-first order, storing a bit for each traversed node, signifying whether the node is the parent of at least one matched leaf txid (or a matched txid itself). In case we are at the leaf level, or this bit is 0, its merkle node hash is stored, and its children are not explored further. Otherwise, no hash is stored, but we recurse into both (or the only) child branch. During decoding, the same depth-first traversal is performed, consuming bits and hashes as they written during encoding.<br />
<br />
===Bloom filter format===<br />
<br />
A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:<br />
<br />
<code>nHashNum * 0xFBA4C795 + nTweak</code><br />
<br />
i.e. if the filter is initialized with 4 hash functions and a tweak of 0x00000005, when the second function (index 1) is needed h1 would be equal to 4221880218.<br />
<br />
When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:<br />
<br />
Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.<br />
<br />
The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000: selected as it represents a filter of 20,000 items with false positive rate of < 0.1% or 10,000 items and a false positive rate of < 0.0001%).<br />
<br />
The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.<br />
<br />
==Copyright==<br />
<br />
This document is placed in the public domain.<br />
<br />
[[Category:Developer]]<br />
[[Category:Technical]]<br />
[[Category:BIP|D]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=33240Contract2012-12-01T12:43:12Z<p>Mike: </p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products can be created:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared that funds network security. Instead of a single announced address for everyone to contribute to, the entrepreneur provides a set of outputs that are signed by each party in their pledge. The entrepreneur also prepares a number of transactions equivalent to the number of outputs, each one spending a single contract output to a null output of zero value and an OP_FALSE script, i.e., the entire value is consumed as fees. The lock time of each transaction is set to N+M, where N is a pre-agreed time at which the contract becomes valid (measured in block numbers) and M is the index of a contract output. In this way, an array of transactions is prepared that do nothing other than incentivize mining in a series of blocks. <br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other without trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
Because the protocol is trust-free, it would be feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, a protocol similar to one proposed by hashcoin can be used:<br />
<br />
# Request a public key from the access point.<br />
# Create, but do not sign, a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the access point's public key and one of your own to be used. The value to be used is chosen as an efficiency tradeoff.<br />
# Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).<br />
# Send both unsigned transactions to the access point. It sees that T1 and T2 are of the expected form and signs T2. It hands T2 back to you.<br />
# Check that T2 is signed correctly, sign T1 and T2. Send them to the access point, which broadcasts them, thus locking in the agreement. Note that T2 won't get included into a block for at least one day, unless it's replaced by a newer transaction, as determined by the sequence numbers.<br />
# Each time you want 10kb of data quota, sign a new version of T2 with a higher sequence number, the same lock time, and adjust the outputs so more value is allocated to the access point, and send it. The AP sees that the output sizes are correct, signs it, and keeps it (does not broadcast).<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP broadcasts the last transaction it saw, replacing the original that was pending. Once the lock time passes, the value transfer is committed. Alternatively, if the session end is negotiated cleanly, the user can sign a transaction that's final (sequence number of UINT_MAX), which signals that no more data quota will be purchased, allowing instant commitment of the transaction.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Distributed_markets&diff=32999Distributed markets2012-11-24T18:44:27Z<p>Mike: /* Pay to policy outputs */</p>
<hr />
<div>Bitcoin allows us to create '''distributed markets''' for the trading of securities, like stocks and bonds. Such markets have no central clearing house and can support securities of a size too small to be practical with todays techniques. It's also possible to build a P2P replacement for ''investment funds''.<br />
<br />
This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have any questions. Jeff Garzik has started implementing some of these ideas in his [https://github.com/jgarzik/smartcoin smartcoin] project. <br />
<br />
== Introduction ==<br />
<br />
Let's start by defining some terms.<br />
<br />
A ''bond'' is a securitized loan. That means somebody who wants a loan can sell some bonds and whoever owns that bond receives the re-payments and any interest that accrues. The bond, being an asset like any other, is transferable - if you get tired of receiving the repayments you can sell the bond to somebody else. Once the full amount of the bond has been repaid, we say it has reached maturity. Some bonds never mature and yield interest payments in perpetuity.<br />
<br />
A ''stock'' is somewhat similar to a bond, except it never matures, yields irregular dividend payments instead of regular interest payments and confers voting rights upon the owner. In this document we will talk mostly about bonds, but the same ideas can be applied to build a stock market too.<br />
<br />
A ''ratings agency'' evaluates the creditworthiness of bond sellers and assigns bonds a consistent score (AAA, AA, junk, etc).<br />
<br />
''Sahai-Waters CP-ABE'' is a recent advance based on pairing-based encryption. Standard Bitcoin payments are point-to-point: I must know the target of my payment by knowing their key/address, and then I can send value to that target alone. Bitcoin script allows some flexibility, eg, by allowing threshold signatures or password based coins. But we lack the ability to pay to anyone who satisfies an arbitrary policy. Ciphertext-policy attribute based encryption (CP-ABE) allows you to encrypt some data such that anyone in possession of a key with attributes that match a formula can decrypt it.<br />
<br />
== Detour: a financial distributed hashmap ==<br />
<br />
A common problem encountered when designing advanced financial markets on top of Bitcoin is the need for a place to temporarily store small pieces of data, keyed by hash. This is because the block chain is not always the right place to put non-trivial amounts of data. The Kademlia protocol and similar designs have solved this problem, albiet in a way that is vulnerable to a variety of DoS and Sybil attacks. But there is no network designed specifically for use in Bitcoin related systems. Today, their most common usage is in file sharing networks that are typically used for copyright infringement.<br />
<br />
A separate Kademlia network can be built that is optimized solely for financial usage. Nodes would restrict the size of the stored data and artificially throttle the serving of it, thus discouraging storage of movies, games, MP3s and other such things. This means users who are interested in the financial applications but don't wish to assist file sharing can donate their resources to the network without issue.<br />
<br />
== A P2P bond network ==<br />
<br />
We start with the familiar structure of an independent P2P broadcast network that connects to the financial hashmap. There is no need for an alternative block chain. Bonds can be modeled as if they were [[Smart Property]].<br />
<br />
<nowiki><br />
message OutPoint {<br />
required bytes tx_hash = 1;<br />
required int index = 2;<br />
}<br />
<br />
message Issuer {<br />
enum AuthType {<br />
PUBLIC_KEY,<br />
EMAIL_ADDRESS,<br />
// Could add more in future, like EV SSL.<br />
}<br />
required AuthType auth_type = 1;<br />
<br />
// Only one of the following should be set, according to authtype.<br />
optional bytes pubkey = 2;<br />
optional string email = 3;<br />
<br />
// Name of the issuer as it will appear in the software, eg, a real name or company name.<br />
required string display_name = 4;<br />
// The script the issuer wants to receive the payments on.<br />
required bytes pay_to_script = 5;<br />
}<br />
<br />
message Bond {<br />
required OutPoint start_point = 1;<br />
required Issuer issuer = 3;<br />
required int value = 2;<br />
required int coupon_value = 3;<br />
<br />
// You could model more complex repayment schedules in future.<br />
required int repayment_value = 4;<br />
<br />
// UNIX time of when the bond was issued.<br />
required int timestamp = 5;<br />
<br />
// URL of the peer issuing the bond. This can be http://<home ip>:12345/ or <br />
// perhaps a Tor onion address.<br />
required string peer_url = 6;<br />
}<br />
</nowiki><br />
<br />
The issuer, timestamp and value fields should be self explanatory. The bond message would be inserted into the hashmap so others who know its hash can find it.<br />
<br />
The start point identifies an output on the Bitcoin network that is created by the bond issuer. That output has a special form: it is of zero value and contains a script like this:<br />
<br />
"BOND" <hash of bond message> 2DROP <issuer pubkey> CHECKSIG<br />
<br />
This output tracks the current owner of the bond. The owner receives the repayments and any accrued interest. Of course a newly issued bond is special, it starts out being owned by the issuer.<br />
<br />
The bond market client app that runs on your desktop follows the block chain, looking for Bitcoin transactions of that form. When it finds one, it downloads the bond message from the hashmap and shows the details in the UI.<br />
<br />
If the bond owner wishes to sell the bond, a sale message is broadcast on the exchange p2p network:<br />
<br />
<nowiki><br />
message ProposedBondSale {<br />
required bytes bond_hash = 1;<br />
required int requested_value = 2;<br />
required bytes pay_to_script = 3;<br />
required string peer_url = 4;<br />
}<br />
</nowiki><br />
<br />
If somebody wishes to buy that bond and sees the broadcast, they construct a transaction that spends requested_value of their own money to the pay_to_script, and add an input that connects to the zero-valued output of the current bondholder, and adds an output of the same BOND form to their own key. They pass it to the selling peer who checks that it looks valid and if so, signs for it then broadcasts thus atomically transferring the bond and the money.<br />
<br />
By scanning the block chain for payments to the current owner of the bond, and checking them against the repayment schedule, the software can automatically calculate which bonds are delinquent and which are mature. Issuers of delinquent bonds would show up in the UI as in debt until sufficient sums were paid to the owners pubkey.<br />
<br />
== Pay to policy outputs ==<br />
<br />
Creating a decentralized bond market is a good start, but real financial markets are more complex. Often there is a layer of abstraction between buyer and seller: an investment fund. The funds encapsulate general instructions from the clients, such as "buy low risk municipal bonds" or "invest in energy stocks" and translates that into a stream of purchases and sales of specific assets. Funds compete on how they choose the specific assets and therefore what return they get.<br />
<br />
Bitcoin payments today must be to a specific, concrete owner. By combining Bitcoin with CP-ABE we can instead make payments to a '''policy'''. A policy is a formula over a set of attributes. Attributes are arbitrary strings or string=integer pairs. Example policies include:<br />
<br />
# ''ceo or (accounts_department AND manager)'' - a policy that allows the CEO of the company access, or a manager in the accounts department, but not any other kind of manager or member of accounting.<br />
# ''master_key OR (3 OF (a, b, c, d, e))'' - a threshold policy that is overridable by a master key. Your key must have at least 3 of the 5 lettered attributes to be usable.<br />
# ''verification_class=MtGoxBasicKYC AND common_name=MikeHearn AND access_level > 5'' - a policy that requires a key with a basic identity assertion of a specific name, verified according to the MtGox basic class, and which has an "access level" above a certain number.<br />
# ''debt_rating(bobs_rating_agency) > 3 AND mining_bond AND interest_rate > 2300 AND interest_rate < 5000 AND repayment_months < 6'' - a policy stating that it can be unlocked by anyone in posession of a key that asserts it was issued for a mining bond with better than a rating of "3" (imagine an AAA like rating system), that will repay fully within 6 months and with an interest rate between 2.3 and 5%.<br />
<br />
The policy is encoded into the ciphertext at encryption time, and the result can only be unlocked by a key that matches the policy. Keys attributes are assigned by an issuing authority.<br />
<br />
It may at first appear that some of the policies expressed above are also expressable with script. For instance, if each attribute is considered to be a separate private key, you could try expressing the first example as a script that uses some CHECKSIGs along with boolean operators. But there are some problems with that approach.<br />
<br />
The first problem is that people can collude to give themselves "superkeys". The Sahai-Waters scheme is collusion-resistant. In the first example, a manager who is not in accounting could team up with somebody who's not a manager but in the right department, and combine their keys to be able to spend the companies money. With CP-ABE the keys cannot be combined to merge attributes like that.<br />
<br />
The second problem is that script cannot contain signatures over anything other than transactions, and only limited forms at that. So you cannot have numeric assertions in outputs because you have no way to verify the inputs are legitimate.<br />
<br />
The third problem is that script rapidly becomes inefficient if you want complex policies over hundreds or thousands of attributes. CP-ABE policies can be quite large whilst remaining feasible.<br />
<br />
There is a final reason to explore CP-ABE: whilst keys cannot be merged together to elevate privilege, you ''can'' remove attributes and thus delegated weakened power to others. In the first example, the manager of the accounts department does not need to get a new key issued from the key authority when a new employee joins: he can just remove the "manager" attribute from his key and generate a new key for the employee himself.<br />
<br />
In the straightforward CP-ABE scheme, there must be exactly one key issuing authority that verifies the client deserves the attributes they're about to be given and then mints the keys. It is possible to decentralize the scheme to become [http://eprint.iacr.org/2010/351.pdf multi-authority CP-ABE] using the Lewko-Waters design.<br />
<br />
Whilst some ABE schemes allow for hiding of the policy, the most expressive types make the policy public as part of the ciphertext. Fortunately this constraint is not a problem for us, indeed, it is an advantage.<br />
<br />
An implementation of single-authority CP-ABE (as well as KP-ABE where keys contain policies and ciphertexts contain attributes) is available in [http://code.google.com/p/libfenc/ libfenc]. Multi-authority CP-ABE is available in a Python library called Charm. There are obviously many applications of this technique. Here we will explore only one.<br />
<br />
== Investment funds ==<br />
<br />
Rather than wait for specific bonds to become available and then manually evaluate each one by hand, we can construct a kind of distributed investment fund by sending money to a Bitcoin private key that is then encrypted under a policy and uploaded into the financial hashmap:<br />
<br />
"POLICY" <hash of InvestmentFundAdvertisement message> 2DROP <pubkey> CHECKSIG<br />
<br />
Policy-locked ciphertexts are potentially quite large, depending on the size of the policy (a comparison against a large number like a date can use over a kilobyte), so it makes sense to use the same hash disassociation used in the bond protocol above in order to minimize block chain size.<br />
<br />
The hash would actually identify a data structure containing the ciphered private key:<br />
<br />
<nowiki><br />
message InvestmentFundAdvertisement {<br />
required bytes owner_pubkey = 1; // The key that will control the bond once sold.<br />
required bytes ciphertext = 2; // Policy is embedded within this.<br />
}<br />
</nowiki><br />
<br />
As the bond market client crawls the block chain, it may encounter policy locked coins. By downloading the ciphertext from the hashmap, it can identify what conditions would unlock the coins and advertise that in the client. Somebody who is looking for business opportunities may see a message like this in their GUI:<br />
<br />
There are ''200 BTC'' available to any bond issuer meeting the following criteria:<br />
# Must be a mining bond.<br />
# Must be repaid entirely within 6 months.<br />
# Must yield an interest rate between 2.3% and 5%<br />
# Debt must be rated as AA or better by one of {MtGox Ratings, Moodys, Standard&Poors}.<br />
# These assertions must have been issued within the last month<br />
<br />
Therefore demand is communicated to suppliers. By submitting such policy-locked coins, investors can send a message to the markets indicating that more mining capacity should be built.<br />
<br />
To be able to find the private key and take the coins, you must obtain a key that matches these attributes by talking to the various issuing authorities. Once you have such a key, any coins sent to such a policy can be taken by yourself. By requiring attributes such as "issued_in=2012/06" the policies can be expired when needed (at the cost of an additional block chain transaction to update the hash).</div>Mikehttps://en.bitcoin.it/w/index.php?title=Smart_Property&diff=32284Smart Property2012-11-02T11:26:31Z<p>Mike: link to contracts page</p>
<hr />
<div>'''Smart property''' is property whose ownership is controlled via the Bitcoin block chain, using [[Contracts|contracts]]. Examples could include physical property such as cars, phones or houses. Smart property also includes non-physical property like shares in a company or access rights to a remote computer. Making property smart allows it to be traded with radically less trust. This reduces fraud, mediation fees and allows trades to take place that otherwise would never have happened. For example, it allows strangers to loan you money over the internet taking your smart property as collateral, which should make lending more competitive and thus credit cheaper.<br />
<br />
Smart property was first proposed by Nick Szabo in his 1997 paper, [http://szabo.best.vwh.net/idea.html "The idea of smart contracts"]. There are currently no implementations of this idea. This page was written by [mailto:mike@plan99.net Mike Hearn], contact him with any questions or ask on the forums.<br />
<br />
==Background==<br />
<br />
Primitive forms of smart property are already common - if you own a car, it probably comes with an immobilizer. Immobilizers augment the physical key with a protocol exchange ensuring only the holders of the correct cryptographic token can activate the engine. They have dramatically reduced car theft, for example, immobilisers are fitted to around 45% of all cars in Australia, but account for only 7% of the cars that are stolen.<br />
<br />
Many other forms of modern property are protected against theft using cryptography, for example, some smartphones will refuse to release certain keys if the correct PIN unlock isn't entered, and cryptography not only renders a stolen device fairly useless but makes it impossible to steal somebodies phone number as well.<br />
<br />
Although these are victories for cryptography, the potential of cryptographically activated property has not been fully explored. The private key is usually itself held in a physical container (like a key or SIM card) and can't be easily transferred or manipulated. Smart property changes this, allowing ownership to be intermediated by Bitcoin miners.<br />
<br />
==Theory==<br />
<br />
This section assumes you are familiar with the Bitcoin protocol, and have a good understanding of [[contracts]].<br />
<br />
Let's start with the example of a car. The cars computer requires authentication using an ''ownership key''. The ownership key is a regular Bitcoin ECDSA-256 key. The car starts its life at the factory gate with the public part of a newly created ownership key. A small token amount of Bitcoins are deposited on that key, call the amount T (it could be 0.0001 BTC for example). Additionally the car has a digital certificate from its manufacturer, and an ''identification key'' which has the public part in the certificate. This allows the car to prove things like its existence, age or mileage to third parties.<br />
<br />
When the car is sold, the following protocol is used:<br />
<br />
# The buyer generates a nonce (random number) and asks the seller to send them the car data.<br />
# The seller gives the car that nonce, and the car returns a data structure signed with its identification key. The data contains the nonce, the cars public cert, data about the car, the public key of the current owner, and the transaction+merkle branch which transferred ownership last time. This ensures the buyer knows what they are getting and that it came from the real seller (it's not a replay).<br />
# The seller selects a key to receive the payment, k1, and names their price P.<br />
# The buyer generates a new ownership key, k2.<br />
# The buyer creates a transaction with two inputs and two outputs. The first input signs for P coins. The second input is connected to the output holding T coins for the ownership address. The first output sends P coins to k1 and the second output sends T coins to k2. This transaction is not valid because only the first input can be signed. The buyer passes this partially complete transaction to the seller, who then signs the second input with the cars current ownership key and broadcasts the transaction.<br />
# They wait for some confirmations.<br />
# The buyer presents the car with the Bitcoin transaction, a merkle branch linking it to the block header and then enough block headers to fill in the gap from the cars current ownership transaction. The car sees that the new transaction re-assigns ownership and is further along in the chain than its current one, plus it has enough work piled on top to be sure the tx won't be reversed. It then updates its ownership information. The car does not need to keep a full record of the chain nor all headers, but rather just enough data to be able to connect future block headers to the one it was previously presented with.<br />
<br />
In practice this process would likely be handled using smartphones with NFC hardware - the act of touching the phone containing the ownership key to the dashboard would start your wallet app in a special mode that knows how to do smart property trades, after inputting the price the buyer and seller would then touch their phones together to finalize the deal. Although the cryptography is complex they would never need to know anything about it. The phone could double as a way to start the car as well.<br />
<br />
==Loans and collateral==<br />
<br />
Being able to trade physical property without fraud risk is useful, but we can add an extra layer to allow for secured low-trust loans. Consider a loan with which to start a small business. Rather than deal with a bank, you decide to allow people from around the world bid on your debt so you can get the best rates. For this to work, the strangers need some assurance that if the loan is not repaid, they get to keep the collateral - yet you still need to be able to use the car to set up the business.<br />
<br />
We can do this by adding ''access keys'' to the ownership key. By signing a message with the ownership key, access keys can be added or removed. Access keys can be temporary in nature. This means that for the duration of the loan, you can re-assign ownership of the vehicle to the creditor whilst keeping an access key for yourself.<br />
<br />
It would be best if the debtor had an assurance that, on repaying his debt, the cars ownership would indeed revert to his control. We can implement this as follows:<br />
<br />
# The creditor generates k1, which is used to receive the loan repayments. The loan size is L.<br />
# The creditor signs Tx1 that has an input/output re-assigning ownership of the car back to the debtor which is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY, and an output for L coins to k1. This transaction is not valid because the loan has not yet been repaid, so the output sums to more value than the inputs. The creditor sends this transaction to the debtor who keeps it.<br />
# As the debtor re-earns the money they spent, they add inputs to Tx1 to increase its value. This doesn't break the signature on the ownership key input/output pair because it was signed with SIGHASH_ANYONECANPAY so is independent of other inputs. They can't adjust the outputs or anything else about the transaction because that would invalidate the ownership input/output (SIGHASH_ALL).<br />
# Once the transaction has enough inputs to sum to L, the debtor broadcasts the transaction, thus repaying their debt and simultaneously retaking ownership of the vehicle.<br />
<br />
Because access keys can be given time limits, if the debtor does not repay the loan by its maturity period his access key expires and the car will no longer start for him. The new owner can now either come and pick it up himself, or if he doesn't want to (eg he is in another country), he can sell it using the low-trust sales protocol described above and collect the money that way.<br />
<br />
Most loans are repaid in multiple installments. The same protocol as above can work in this case by embedding some control data in the extra input/output pair, the ownership key would not change but the signature would cover a command that extends the lifetime of the access key for another month. The vehicle would know how to parse the data out of the transaction.<br />
<br />
==Implementation details==<br />
<br />
For expiring access keys, the device must have a trustable source of time. Some devices like cars and phones keep time by themselves. In other cases where that's not practical for some reason, a secure timestamping service can be used. This is a service that signs a message containing the current time and a nonce. The device generates a nonce, and as part of the activation/switch-on protocol, a network connected device like a smartphone sends the nonce to the timestamping service then hands back the signed message. The block chain itself cannot be used as a source of time because there's no challenge/response aspect - the device has no way of knowing if you've handed it the latest blocks or not. Signing the time with a nonce solves this.<br />
<br />
Smart phones play a key role in smart property because they have the ability to bridge devices without network access to the network, using Bluetooth or NFC radio. For instance, requiring internet access for a smart lock on a house door is too expensive and impractical. However, a lock with an NFC touchpoint that understands how to check block header progression is quite feasible. The only operations needed to implement Bitcoin-linked smart property is hashing, ECDSA and a small amount of storage. Smartcard chips that implement everything required are common and cheap.<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=32283Contract2012-11-02T11:25:06Z<p>Mike: Re-organize the page a bit</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
By building low trust protocols that interact with Bitcoin, entirely new products become possible:<br />
<br />
* [[Smart Property|Smart property]] is property that can be atomically traded and loaned via the block chain.<br />
* [[Agents]] are autonomous programs that maintain their own wallet, which they use to buy server time. Money is obtained by the agent selling services. If demand exceeds supply the agents can spawn children that either survive or die depending on whether they can get enough business.<br />
* [[Distributed markets]] are a way to implement peer to peer bond and stock trading, allowing Bitcoin to be evolve into a full competitor to the international financial system.<br />
* The [[Ripple currency exchange]] is a way to implement a distributed currency exchange based on social networks.<br />
<br />
This page also lists some smaller examples.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks]. These pages were written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contract. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared that funds network security. Instead of a single announced address for everyone to contribute to, the entrepreneur provides a set of outputs that are signed by each party in their pledge. The entrepreneur also prepares a number of transactions equivalent to the number of outputs, each one spending a single contract output to a null output of zero value and an OP_FALSE script, i.e., the entire value is consumed as fees. The lock time of each transaction is set to N+M, where N is a pre-agreed time at which the contract becomes valid (measured in block numbers) and M is the index of a contract output. In this way, an array of transactions is prepared that do nothing other than incentivize mining in a series of blocks. <br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other without trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
Because the protocol is trust-free, it would be feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, a protocol similar to one proposed by hashcoin can be used:<br />
<br />
# Request a public key from the access point.<br />
# Create, but do not sign, a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the access point's public key and one of your own to be used. The value to be used is chosen as an efficiency tradeoff.<br />
# Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).<br />
# Send both unsigned transactions to the access point. It sees that T1 and T2 are of the expected form and signs T2. It hands T2 back to you.<br />
# Check that T2 is signed correctly, sign T1 and T2. Send them to the access point, which broadcasts them, thus locking in the agreement. Note that T2 won't get included into a block for at least one day, unless it's replaced by a newer transaction, as determined by the sequence numbers.<br />
# Each time you want 10kb of data quota, sign a new version of T2 with a higher sequence number, the same lock time, and adjust the outputs so more value is allocated to the access point, and send it. The AP sees that the output sizes are correct, signs it, and keeps it (does not broadcast).<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP broadcasts the last transaction it saw, replacing the original that was pending. Once the lock time passes, the value transfer is committed. Alternatively, if the session end is negotiated cleanly, the user can sign a transaction that's final (sequence number of UINT_MAX), which signals that no more data quota will be purchased, allowing instant commitment of the transaction.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Contract&diff=32282Contract2012-11-02T11:20:09Z<p>Mike: note about distributed markets.</p>
<hr />
<div>A '''distributed contract''' is a method of using Bitcoin to form agreements with people via the block chain. Contracts don't make anything possible that was previously impossible, but rather, they allow you to solve common problems in a way that minimizes trust. Minimal trust often makes things more convenient by allowing human judgements to be taken out of the loop, thus allowing complete automation.<br />
<br />
Many of the ideas underlying Bitcoin contracts were first described by Nick Szabó in his seminal paper, <br />
[http://szabo.best.vwh.net/formalize.html Formalizing and Securing Relationships on Public Networks].<br />
<br />
This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have an idea for a new type of contact. You can watch '''[https://www.youtube.com/watch?feature=player_embedded&v=mD4L7xDNCmA a video of a talk on contracts]''' that was presented at the Bitcoin 2012 conference in London.<br />
<br />
==Theory==<br />
<br />
Every [[transaction]] in Bitcoin has one or more inputs and outputs. Each input/output has a small, pure function associated with it called a [[script]]. Scripts can contain signatures over simplified forms of the transaction itself.<br />
<br />
Every transaction can have a lock time associated with it. This allows the transaction to be pending and replaceable until an agreed-upon future time, specified either as a block index or as a timestamp (the same field is used for both, but values less than 500 million are interpreted as a block index). If a transaction's lock time has been reached, we say it is final.<br />
<br />
Each transaction input has a sequence number. In a normal transaction that just moves value around, the sequence numbers are all UINT_MAX and the lock time is zero. If the lock time has not yet been reached, but all the sequence numbers are UINT_MAX, the transaction is also considered final. Sequence numbers can be used to issue new versions of a transaction without invalidating other inputs signatures, e.g., in the case where each input on a transaction comes from a different party, each input may start with a sequence number of zero, and those numbers can be incremented independently.<br />
<br />
Signature checking is flexible because the form of transaction that is signed can be controlled through the use of SIGHASH flags, which are stuck on the end of a signature. In this way, contracts can be constructed in which each party signs only a part of it, allowing other parts to be changed without their involvement. The SIGHASH flags have two parts, a mode and the ANYONECANPAY modifier:<br />
<br />
# SIGHASH_ALL: This is the default. It indicates that everything about the transaction is signed, except for the input scripts. Signing the input scripts as well would obviously make it impossible to construct a transaction, so they are always blanked out. Note, though, that other properties of the input, like the connected output and sequence numbers, ''are'' signed; it's only the scripts that are not. Intuitively, it means "I agree to put my money in, if everyone puts their money in and the outputs are this".<br />
# SIGHASH_NONE: The outputs are not signed and can be anything. Use this to indicate "I agree to put my money in, as long as everyone puts their money in, but I don't care what's done with the output". This mode allows others to update the transaction by changing their inputs sequence numbers.<br />
# SIGHASH_SINGLE: Like SIGHASH_NONE, the inputs are signed, but the sequence numbers are blanked, so others can create new versions of the transaction. However, the only output that is signed is the one at the same position as the input. Use this to indicate "I agree, as long as my output is what I want; I don't care about the others".<br />
<br />
The SIGHASH_ANYONECANPAY modifier can be combined with the above three modes. When set, only that input is signed and the other inputs can be anything.<br />
<br />
Scripts can contain the CHECKMULTISIG opcode. This opcode provides n-of-m checking: you provide multiple public keys, and specify the number of valid signatures that must be present. The number of signatures can be less than the number of public keys. An output can require two signatures to be spent by setting it to something like this:<br />
<br />
2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY<br />
<br />
There are two general patterns for safely creating contracts:<br />
<br />
# Transactions are passed around outside of the P2P network, in partially-complete or invalid forms.<br />
# Two transactions are used: one (the contract) is created and signed but not broadcast right away. Instead, the other transaction (the payment) is broadcast after the contract is agreed to lock in the money, and then the contract is broadcast.<br />
<br />
This is to ensure that people always know what they are agreeing to.<br />
<br />
Together, these features let us build interesting new financial tools on top of the block chain.<br />
<br />
==Example 1: Providing a deposit==<br />
<br />
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day. <br />
<br />
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.<br />
<br />
We can solve this problem with a contract:<br />
<br />
# The user and website send each other a newly-generated public key.<br />
# The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.<br />
# User sends the hash of Tx1 to the website.<br />
# The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.<br />
# Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.<br />
# The user broadcasts Tx1, then broadcasts Tx2.<br />
<br />
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.<br />
<br />
What if the user wishes to close his account early? The website creates a new version of Tx2 with nLockTime set to zero and the input sequence number set to UINT_MAX, then he re-signs it. The site hands the tx back to the user, who signs it as well. The user then broadcasts the transaction, terminating the contract early and releasing the coins.<br />
<br />
What if the six months is nearly up and the user wishes to keep his account? The same thing applies: the contract can be resigned with a newer nLockTime, a sequence number 1 higher than the previous and rebroadcast 2^32 times. No matter what happens, both parties must agree for the contract to change.<br />
<br />
Obviously, if the user turns out to be abusive (i.e., a spammer), the website will not allow an early close of the contract. If too much abuse is getting through, the size of the deposit can be raised or the length of the contract can be increased.<br />
<br />
==Example 2: Escrow and dispute mediation==<br />
<br />
A buyer wants to trade with somebody he doesn't know or trust. In the common case where the transaction goes well, the client doesn't want any third parties involved. If something goes wrong though, he'd like a third party to decide who gets the money - perhaps a professional dispute mediation service. Note that this concept can apply to either buyer or seller. The mediator might request proof of postage from the merchant, for example.<br />
<br />
In other words, one wants to lock up some coins so a third party has to agree in order for them to be spent:<br />
<br />
# Agree with the merchant on a dispute mediator (e.g., ClearCoin).<br />
# Ask the merchant for a public key (K1). Ask the mediator for a public key (K2). Create a new key for yourself (K3).<br />
# Send the merchant K2. The merchant challenges the mediator with a random nonce. The mediator signs the nonce with the private form of K2, thus proving it really belongs to merchant.<br />
# Create a transaction (Tx1) with an output script as follows and broadcast it:<br />
<br />
2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY<br />
<br />
Now the coins are locked in such a way that they can only be spent by the following methods:<br />
<br />
# Client and the merchant agree (either a successful trade, or merchant agrees to reimburse client without mediation)<br />
# Client and the mediator agree (failed trade, mediator sides with client, like a charge-back)<br />
# The mediator and the merchant agree (goods delivered, merchant gets client's coins despite the dispute)<br />
<br />
When signing an input, the contents are set to the connected output. Thus, to redeem this transaction, the client creates a scriptSig containing zeros where the other signature should be, signs it, and then sets one of the slots to his new signature. The partially-complete transaction can then be sent to the merchant or mediator for the second signature.<br />
<br />
==Example 3: Assurance contracts==<br />
<br />
An [http://en.wikipedia.org/wiki/Assurance_contract assurance contract] is a way of funding the creation of a [http://www.auburn.edu/~johnspm/gloss/public_goods public good], that is, a good that, once created, anyone can benefit from for free. The standard example is a lighthouse: whilst everyone may agree that one should be built, it’s too expensive for an individual sailor to justify building one, given that it will also benefit all his competitors. <br />
<br />
One solution is for everyone to pledge money towards the creation of the public good, such that the pledges are only committed if the total value of all pledges is above the cost of creation. If not enough people contribute, nobody has to pay anything.<br />
<br />
Examples where Bitcoin is superior to traditional payment methods for assurance contract fundraising include applications where frequent, small pledges need to be made automatically, for instance internet radio station funding and [https://bitcointalk.org/index.php?topic=67255.msg788110#msg788110 web page translation]. Consider a browser extension that you send a bit of money to. It detects the current language of the page and broadcasts a pledge for a translation into your language to be prepared. If enough users with the extension land on the same page at the same time (eg, it was linked to from somewhere high traffic), then enough pledges are broadcast to trigger a payment to a company who prepares a high quality translation. When complete it automatically loads in your browser.<br />
<br />
We can model this in Bitcoin as follows:<br />
<br />
# An entrepreneur creates a new address and announces that the good will be created if at least 1000 BTC is raised. Anyone can contribute.<br />
# Each party wishing to pledge creates a new transaction spending some of their coins to the announced address, but they do not broadcast it. The transaction is similar to a regular transaction except for three differences: Firstly, there cannot be any change. If you don’t have any outputs of the right size, you must create one first by spending to one of your own addresses. Secondly, the input script signature is signed with SIGHASH_ALL | SIGHASH_ANYONECANPAY. Finally, the output value is set to 1000 BTC. Note that this is not a valid transaction because the output value is larger than the input value.<br />
# The transaction is uploaded to the entrepreneur's server, which saves it to disk and updates its count of how many coins have been pledged.<br />
# Once the server has enough coins, it merges the separate transactions together into a new transaction. The new transaction has a single output that simply spends to the announced address - it is the same as the outputs on each contributed transaction. The inputs to the transaction are collected from the contributed pledges.<br />
# The finished transaction is broadcast, sending the pledged coins to the announced address.<br />
<br />
This scheme relies on several aspects of the protocol. The first is the SIGHASH flags used. SIGHASH_ALL is the default and means the entire contents of the transaction are signed, except for the input scripts. SIGHASH_ANYONECANPAY is an additional modifier that means the signature only covers the input it’s found in - the other inputs are not signed and thus can be anything.<br />
<br />
By combining these flags together, we are able to create a signature that is valid even when other inputs are added, but breaks if the outputs or other properties of the transaction are changed.<br />
<br />
The second aspect we exploit is the fact that a transaction in which the output values are larger than the input values is invalid (for obvious reasons). This means it’s safe to send the entrepreneur a transaction that spends such coins - it’s impossible for him to claim the coins unless he has other inputs that sum to the output value or more.<br />
<br />
It's possible to create assurance contracts without using SIGHASH_ANYONECANPAY. Instead, a two step process is used in which pledges are collected without transactions, and once the total value is reached, a transaction with an input for each pledger is created and passed around until all signatures are collected. However, using SIGHASH_ANYONECANPAY and then merging is probably more convenient.<br />
<br />
An assurance contract can be prepared that funds network security. Instead of a single announced address for everyone to contribute to, the entrepreneur provides a set of outputs that are signed by each party in their pledge. The entrepreneur also prepares a number of transactions equivalent to the number of outputs, each one spending a single contract output to a null output of zero value and an OP_FALSE script, i.e., the entire value is consumed as fees. The lock time of each transaction is set to N+M, where N is a pre-agreed time at which the contract becomes valid (measured in block numbers) and M is the index of a contract output. In this way, an array of transactions is prepared that do nothing other than incentivize mining in a series of blocks. <br />
<br />
An elaboration of this concept is described by Tabarrok in his paper, [http://mason.gmu.edu/~atabarro/PrivateProvision.pdf “The private provision of public goods via dominant assurance contracts”]. In a dominant assurance contract, if a contract fails (not enough pledges within a set time window) the entrepreneur pays a fee to those who pledged so far. This type of contract attempts to arrange incentives such that taking part is always the right strategy. [[Dominant Assurance Contracts|A scheme for dominant assurance contracts]] in Bitcoin has been proposed.<br />
<br />
==Example 4: Using external state==<br />
<br />
Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. But we can make transactions connected to the world in other ways.<br />
<br />
Consider the example of an old man who wishes to give an inheritance to his grandson, either on the grandson's 18th birthday or when the man dies, whichever comes first. <br />
<br />
To solve this, the man first sends the amount of the inheritance to himself so there is a single output of the right amount. Then he creates a transaction with a lock time of the grandson's 18th birthday that pays the coins to another key owned by the grandson, signs it, and gives it to him - but does not broadcast it. This takes care of the 18th birthday condition. If the date passes, the grandson broadcasts the transaction and claims the coins. He could do it before then, but it doesn't let him get the coins any earlier, and some nodes may choose to drop transactions in the memory pool with lock times far in the future.<br />
<br />
The death condition is harder. As Bitcoin nodes cannot measure arbitrary conditions, we must rely on an ''oracle''. An oracle is a server that has a keypair, and signs transactions on request when a user-provided expression evaluates to true.<br />
<br />
Here is an example. The man creates a transaction spending his output, and sets the output to:<br />
<br />
<sons pubkey> CHECKSIGVERIFY <oracle pubkey> CHECKSIGVERIFY <hash> OP_TRUE<br />
<br />
This is the oracle script. It has an unusual form - after signature checking it pushes data to the stack then does not use it. The pubkey is published on the oracle's website and is well-known. The hash is set to be the hash of the user-provided expression stating that he has died, written in a form the oracle knows how to evaluate. For example, it could be the hash of the string:<br />
<br />
if (has_died('john smith', born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
This little language is hypothetical, it'd be defined by the oracle and could be anything. The return value is an address owned by the grandson.<br />
<br />
Once more, the man creates this transaction but gives it directly to his grandson instead of broadcasting it. He also provides the expression that is hashed into the transaction and the name of the oracle that can unlock it.<br />
<br />
It is used in the following algorithm:<br />
<br />
# The oracle accepts a measurement request. The request contains the user-provided expression, a copy of the output script, and a partially complete transaction provided by the user. Everything in this transaction is finished except for the scriptSig, which contains just one signature (the grandson's) - not enough to unlock the output.<br />
# The oracle checks the user-provided expression hashes to the value in the provided output script. If it doesn't, it returns an error.<br />
# The oracle evaluates the expression. If the result is not the destination address of the output, it returns an error.<br />
# Otherwise the oracle signs the transaction and inserts the signature into the scriptSig. Note that when signing a Bitcoin transaction, the input script is set to the connected output script. The reason is that when OP_CHECKSIG runs, the script containing the opcode is put in the input being evaluated, _not_ the script containing the signature itself. The oracle has never seen the full output it is being asked to sign, but it doesn't have to. It knows the output script, its own public key, and the hash of the user-provided expression, which is everything it needs to check the output script and finish the transaction.<br />
# The oracle returns the newly signed, unbroadcast transaction to the user.<br />
<br />
If, and only if, the oracle agrees that the man is dead, the grandson can broadcast the two transactions (the contract and the claim) and take the coins.<br />
<br />
The oracle does not need to be highly trusted. It has not seen the transaction the grandson is trying to unlock, as it was never broadcast, thus, the oracle cannot hold the grandson to ransom because it does not know whether the transaction it's signing for even exists. People can, and should, regularly challenge the oracle in an automated fashion to ensure it always outputs what is expected. The challenges can be done without spending any coins because the tx to be signed can be invalid (ie, connected to transactions that don't exist). The oracle has no way to know whether a request to be signed is random or real. CHECKSIGVERIFY can be replaced with CHECKMULTISIGVERIFY to allow for n-of-m oracles if need be.<br />
<br />
Oracles can potentially evaluate anything, yet the output script form in the block chain can always be the same. Consider the following possibilities:<br />
<br />
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5<br />
Require exchange rate to be between two values on a given date<br />
<br />
google_results_count(site:www.google.com/hostednews 'Mike Hearn' olympic gold medal) > 0<br />
A bet on me doing something that I will never actually do<br />
<br />
// Choose between one of two winners of a bet on the outcome of the Eurovision song contest.<br />
if (eurovision_winner() == 'Azerbaijan') <br />
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD; <br />
else <br />
return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;<br />
<br />
The conditions that control whether the oracle signs can be arbitrarily complex, but the block chain never needs to contain more than a single hash.<br />
<br />
==Example 5: Trading across chains==<br />
<br />
The Bitcoin technology can be adapted to create [[Alternative chain|multiple, independent currencies]]. NameCoin is an example of one such currency that operates under a slightly different set of rules, and can also be used to rent names in a namespace. Currencies that implement the same ideas as Bitcoin can be traded freely against each other without trust. <br />
<br />
For example, imagine a consortium of companies that issue EURcoins, a crypto-currency that is backed 1:1 by deposits in the consortium's bank accounts. Such a currency would have a different set of tradeoffs to Bitcoin: more centralized, but without FX risk. People might wish to trade Bitcoins for EURcoins back and forth, with the companies only getting involved when cashing in/out of the regular banking system.<br />
<br />
To implement this, a protocol proposed by luxgladius can be used:<br />
<br />
# Both parties generate a new key and some random data (the secret).<br />
# Party 'B' sends a hash of his secret to 'A' along with his public key.<br />
# Party 'A' generates Tx1 (the payment) containing an output with the chain-trade script in it. See below for this script and a discussion of it. It allows coin release either by signing with the two keys (key 'A' and key 'B') or with (secret 'A', secret 'B', key 'B'). This transaction is not broadcast. The chain release script contains hashes, not the actual secrets themselves.<br />
# Party 'A' generates Tx2 (the contract), which spends Tx1 and has an output going back to key 'A'. It has a lock time in the future and the input has a sequence number of zero, so it can be replaced. 'A' signs Tx2 and sends it to 'B', who also signs it and sends it back. Alternatively, they can simply agree on what form the contract takes, e.g., by using the same software, and then 'A' can simply send 'B' the hash of Tx1 and receive back a signature.<br />
# 'A' broadcasts Tx1 and Tx2. Party 'B' can now see the coins but cannot spend them because it does not have an output going to him, and the tx is not finalized anyway.<br />
# 'B' performs the same scheme in reverse on the alternative chain. Both sides of the trade are now pending but incomplete.<br />
# 'A' sends his secret (random data) to 'B', who then uses it to re-issue the now-finalized contract using (secret 'A', secret 'B', key 'B') and an output of his choice. 'B' now owns the coins, but in the process of claiming them, revealed his secret, allowing 'A' to claim the other side of the trade.<br />
<br />
Because the protocol is trust-free, it would be feasible to do trades automatically in an entirely peer-to-peer manner, which should ensure good liquidity.<br />
<br />
The chain-trade script could look like this:<br />
<br />
IF <br />
2 <key A> <key B> 2 CHECKMULTISIGVERIFY<br />
ELSE<br />
<key B> CHECKSIGVERIFY SHA256 <hash of secret A> EQUALVERIFY <hash of secret B> EQUALVERIFY<br />
ENDIF<br />
<br />
The contract input script looks like either:<br />
<br />
<sig A> <sig B> 1<br />
<br />
or<br />
<br />
<secret B> <secret A> <sig B> 0<br />
<br />
i.e., the first data element selects which phase is being used.<br />
<br />
Note that whilst EURcoins is a natural idea, there are other ways to implement peer-to-peer currency exchange (Bitcoin to fiat and vice versa), see the [[Ripple currency exchange]] article for more information.<br />
<br />
==Example 6: Smart property==<br />
<br />
It's possible to make physical property, like houses, cars or phones, be atomically tradeable and lendable via the block chain. This topic has its own article: learn more about [[Smart Property|smart property]].<br />
<br />
==Example 7: Rapidly-adjusted (micro)payments to a pre-determined party==<br />
<br />
Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.<br />
<br />
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.<br />
<br />
To do this, a protocol similar to one proposed by hashcoin can be used:<br />
<br />
# Request a public key from the access point.<br />
# Create, but do not sign, a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the access point's public key and one of your own to be used. The value to be used is chosen as an efficiency tradeoff.<br />
# Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).<br />
# Send both unsigned transactions to the access point. It sees that T1 and T2 are of the expected form and signs T2. It hands T2 back to you.<br />
# Check that T2 is signed correctly, sign T1 and T2. Send them to the access point, which broadcasts them, thus locking in the agreement. Note that T2 won't get included into a block for at least one day, unless it's replaced by a newer transaction, as determined by the sequence numbers.<br />
# Each time you want 10kb of data quota, sign a new version of T2 with a higher sequence number, the same lock time, and adjust the outputs so more value is allocated to the access point, and send it. The AP sees that the output sizes are correct, signs it, and keeps it (does not broadcast).<br />
<br />
This continues until the session ends, or the 1-day period is getting close to expiry. The AP broadcasts the last transaction it saw, replacing the original that was pending. Once the lock time passes, the value transfer is committed. Alternatively, if the session end is negotiated cleanly, the user can sign a transaction that's final (sequence number of UINT_MAX), which signals that no more data quota will be purchased, allowing instant commitment of the transaction.<br />
<br />
The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user [[double-spending|double-spends]] the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.<br />
<br />
==Example 8: Agents==<br />
<br />
[[Agents]] are autonomous programs that maintain their own wallets and act in the economy. Because an agent is a program and has no recourse to the law courts if something goes wrong, it must be entirely reliant on low trust protocols. Agents have a dedicated wiki page that discusses how they would use some of the contracts on this page, along with trusted computing/remote attestation protocols to ensure they do not get scammed by humans or other programs.<br />
<br />
==Example 9: Distributed investment and securities markets==<br />
<br />
[[Smart Property|Smart property]] allows for collateralized lending of physical property. But we can extend the concept to build distributed, peer to peer markets for the trading of bonds and other similar securities like stocks. In this way credit and lending can be brought to the Bitcoin world. Read more about [[Distributed markets|distributed markets]].<br />
<br />
==See Also==<br />
<br />
* [[Script]]<br />
<br />
[[Category:Technical]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=Distributed_markets&diff=32281Distributed markets2012-11-02T11:16:40Z<p>Mike: Port distributed bonds post from forum to wiki</p>
<hr />
<div>Bitcoin allows us to create '''distributed markets''' for the trading of securities, like stocks and bonds. Such markets have no central clearing house and can support securities of a size too small to be practical with todays techniques. It's also possible to build a P2P replacement for ''investment funds''.<br />
<br />
This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have any questions. Jeff Garzik has started implementing some of these ideas in his [https://github.com/jgarzik/smartcoin smartcoin] project. <br />
<br />
== Introduction ==<br />
<br />
Let's start by defining some terms.<br />
<br />
A ''bond'' is a securitized loan. That means somebody who wants a loan can sell some bonds and whoever owns that bond receives the re-payments and any interest that accrues. The bond, being an asset like any other, is transferable - if you get tired of receiving the repayments you can sell the bond to somebody else. Once the full amount of the bond has been repaid, we say it has reached maturity. Some bonds never mature and yield interest payments in perpetuity.<br />
<br />
A ''stock'' is somewhat similar to a bond, except it never matures, yields irregular dividend payments instead of regular interest payments and confers voting rights upon the owner. In this document we will talk mostly about bonds, but the same ideas can be applied to build a stock market too.<br />
<br />
A ''ratings agency'' evaluates the creditworthiness of bond sellers and assigns bonds a consistent score (AAA, AA, junk, etc).<br />
<br />
''Sahai-Waters CP-ABE'' is a recent advance based on pairing-based encryption. Standard Bitcoin payments are point-to-point: I must know the target of my payment by knowing their key/address, and then I can send value to that target alone. Bitcoin script allows some flexibility, eg, by allowing threshold signatures or password based coins. But we lack the ability to pay to anyone who satisfies an arbitrary policy. Ciphertext-policy attribute based encryption (CP-ABE) allows you to encrypt some data such that anyone in possession of a key with attributes that match a formula can decrypt it.<br />
<br />
== Detour: a financial distributed hashmap ==<br />
<br />
A common problem encountered when designing advanced financial markets on top of Bitcoin is the need for a place to temporarily store small pieces of data, keyed by hash. This is because the block chain is not always the right place to put non-trivial amounts of data. The Kademlia protocol and similar designs have solved this problem, albiet in a way that is vulnerable to a variety of DoS and Sybil attacks. But there is no network designed specifically for use in Bitcoin related systems. Today, their most common usage is in file sharing networks that are typically used for copyright infringement.<br />
<br />
A separate Kademlia network can be built that is optimized solely for financial usage. Nodes would restrict the size of the stored data and artificially throttle the serving of it, thus discouraging storage of movies, games, MP3s and other such things. This means users who are interested in the financial applications but don't wish to assist file sharing can donate their resources to the network without issue.<br />
<br />
== A P2P bond network ==<br />
<br />
We start with the familiar structure of an independent P2P broadcast network that connects to the financial hashmap. There is no need for an alternative block chain. Bonds can be modeled as if they were [[Smart Property]].<br />
<br />
<nowiki><br />
message OutPoint {<br />
required bytes tx_hash = 1;<br />
required int index = 2;<br />
}<br />
<br />
message Issuer {<br />
enum AuthType {<br />
PUBLIC_KEY,<br />
EMAIL_ADDRESS,<br />
// Could add more in future, like EV SSL.<br />
}<br />
required AuthType auth_type = 1;<br />
<br />
// Only one of the following should be set, according to authtype.<br />
optional bytes pubkey = 2;<br />
optional string email = 3;<br />
<br />
// Name of the issuer as it will appear in the software, eg, a real name or company name.<br />
required string display_name = 4;<br />
// The script the issuer wants to receive the payments on.<br />
required bytes pay_to_script = 5;<br />
}<br />
<br />
message Bond {<br />
required OutPoint start_point = 1;<br />
required Issuer issuer = 3;<br />
required int value = 2;<br />
required int coupon_value = 3;<br />
<br />
// You could model more complex repayment schedules in future.<br />
required int repayment_value = 4;<br />
<br />
// UNIX time of when the bond was issued.<br />
required int timestamp = 5;<br />
<br />
// URL of the peer issuing the bond. This can be http://<home ip>:12345/ or <br />
// perhaps a Tor onion address.<br />
required string peer_url = 6;<br />
}<br />
</nowiki><br />
<br />
The issuer, timestamp and value fields should be self explanatory. The bond message would be inserted into the hashmap so others who know its hash can find it.<br />
<br />
The start point identifies an output on the Bitcoin network that is created by the bond issuer. That output has a special form: it is of zero value and contains a script like this:<br />
<br />
"BOND" <hash of bond message> 2DROP <issuer pubkey> CHECKSIG<br />
<br />
This output tracks the current owner of the bond. The owner receives the repayments and any accrued interest. Of course a newly issued bond is special, it starts out being owned by the issuer.<br />
<br />
The bond market client app that runs on your desktop follows the block chain, looking for Bitcoin transactions of that form. When it finds one, it downloads the bond message from the hashmap and shows the details in the UI.<br />
<br />
If the bond owner wishes to sell the bond, a sale message is broadcast on the exchange p2p network:<br />
<br />
<nowiki><br />
message ProposedBondSale {<br />
required bytes bond_hash = 1;<br />
required int requested_value = 2;<br />
required bytes pay_to_script = 3;<br />
required string peer_url = 4;<br />
}<br />
</nowiki><br />
<br />
If somebody wishes to buy that bond and sees the broadcast, they construct a transaction that spends requested_value of their own money to the pay_to_script, and add an input that connects to the zero-valued output of the current bondholder, and adds an output of the same BOND form to their own key. They pass it to the selling peer who checks that it looks valid and if so, signs for it then broadcasts thus atomically transferring the bond and the money.<br />
<br />
By scanning the block chain for payments to the current owner of the bond, and checking them against the repayment schedule, the software can automatically calculate which bonds are delinquent and which are mature. Issuers of delinquent bonds would show up in the UI as in debt until sufficient sums were paid to the owners pubkey.<br />
<br />
== Pay to policy outputs ==<br />
<br />
Creating a decentralized bond market is a good start, but real financial markets are more complex. Often there is a layer of abstraction between buyer and seller: an investment fund. The funds encapsulate general instructions from the clients, such as "buy low risk municipal bonds" or "invest in energy stocks" and translates that into a stream of purchases and sales of specific assets. Funds compete on how they choose the specific assets and therefore what return they get.<br />
<br />
Bitcoin payments today must be to a specific, concrete owner. By combining Bitcoin with CP-ABE we can instead make payments to a [i]policy[/i]. A policy is a formula over a set of attributes. Attributes are arbitrary strings or string=integer pairs. Example policies include:<br />
<br />
# ''ceo or (accounts_department AND manager)'' - a policy that allows the CEO of the company access, or a manager in the accounts department, but not any other kind of manager or member of accounting.<br />
# ''master_key OR (3 OF (a, b, c, d, e))'' - a threshold policy that is overridable by a master key. Your key must have at least 3 of the 5 lettered attributes to be usable.<br />
# ''verification_class=MtGoxBasicKYC AND common_name=MikeHearn AND access_level > 5'' - a policy that requires a key with a basic identity assertion of a specific name, verified according to the MtGox basic class, and which has an "access level" above a certain number.<br />
# ''debt_rating(bobs_rating_agency) > 3 AND mining_bond AND interest_rate > 2300 AND interest_rate < 5000 AND repayment_months < 6'' - a policy stating that it can be unlocked by anyone in posession of a key that asserts it was issued for a mining bond with better than a rating of "3" (imagine an AAA like rating system), that will repay fully within 6 months and with an interest rate between 2.3 and 5%.<br />
<br />
The policy is encoded into the ciphertext at encryption time, and the result can only be unlocked by a key that matches the policy. Keys attributes are assigned by an issuing authority.<br />
<br />
It may at first appear that some of the policies expressed above are also expressable with script. For instance, if each attribute is considered to be a separate private key, you could try expressing the first example as a script that uses some CHECKSIGs along with boolean operators. But there are some problems with that approach.<br />
<br />
The first problem is that people can collude to give themselves "superkeys". The Sahai-Waters scheme is collusion-resistant. In the first example, a manager who is not in accounting could team up with somebody who's not a manager but in the right department, and combine their keys to be able to spend the companies money. With CP-ABE the keys cannot be combined to merge attributes like that.<br />
<br />
The second problem is that script cannot contain signatures over anything other than transactions, and only limited forms at that. So you cannot have numeric assertions in outputs because you have no way to verify the inputs are legitimate.<br />
<br />
The third problem is that script rapidly becomes inefficient if you want complex policies over hundreds or thousands of attributes. CP-ABE policies can be quite large whilst remaining feasible.<br />
<br />
There is a final reason to explore CP-ABE: whilst keys cannot be merged together to elevate privilege, you ''can'' remove attributes and thus delegated weakened power to others. In the first example, the manager of the accounts department does not need to get a new key issued from the key authority when a new employee joins: he can just remove the "manager" attribute from his key and generate a new key for the employee himself.<br />
<br />
In the straightforward CP-ABE scheme, there must be exactly one key issuing authority that verifies the client deserves the attributes they're about to be given and then mints the keys. It is possible to decentralize the scheme to become [http://eprint.iacr.org/2010/351.pdf multi-authority CP-ABE] using the Lewko-Waters design.<br />
<br />
Whilst some ABE schemes allow for hiding of the policy, the most expressive types make the policy public as part of the ciphertext. Fortunately this constraint is not a problem for us, indeed, it is an advantage.<br />
<br />
An implementation of single-authority CP-ABE (as well as KP-ABE where keys contain policies and ciphertexts contain attributes) is available in [http://code.google.com/p/libfenc/ libfenc]. Multi-authority CP-ABE is available in a Python library called Charm. There are obviously many applications of this technique. Here we will explore only one.<br />
<br />
== Investment funds ==<br />
<br />
Rather than wait for specific bonds to become available and then manually evaluate each one by hand, we can construct a kind of distributed investment fund by sending money to a Bitcoin private key that is then encrypted under a policy and uploaded into the financial hashmap:<br />
<br />
"POLICY" <hash of InvestmentFundAdvertisement message> 2DROP <pubkey> CHECKSIG<br />
<br />
Policy-locked ciphertexts are potentially quite large, depending on the size of the policy (a comparison against a large number like a date can use over a kilobyte), so it makes sense to use the same hash disassociation used in the bond protocol above in order to minimize block chain size.<br />
<br />
The hash would actually identify a data structure containing the ciphered private key:<br />
<br />
<nowiki><br />
message InvestmentFundAdvertisement {<br />
required bytes owner_pubkey = 1; // The key that will control the bond once sold.<br />
required bytes ciphertext = 2; // Policy is embedded within this.<br />
}<br />
</nowiki><br />
<br />
As the bond market client crawls the block chain, it may encounter policy locked coins. By downloading the ciphertext from the hashmap, it can identify what conditions would unlock the coins and advertise that in the client. Somebody who is looking for business opportunities may see a message like this in their GUI:<br />
<br />
There are ''200 BTC'' available to any bond issuer meeting the following criteria:<br />
# Must be a mining bond.<br />
# Must be repaid entirely within 6 months.<br />
# Must yield an interest rate between 2.3% and 5%<br />
# Debt must be rated as AA or better by one of {MtGox Ratings, Moodys, Standard&Poors}.<br />
# These assertions must have been issued within the last month<br />
<br />
Therefore demand is communicated to suppliers. By submitting such policy-locked coins, investors can send a message to the markets indicating that more mining capacity should be built.<br />
<br />
To be able to find the private key and take the coins, you must obtain a key that matches these attributes by talking to the various issuing authorities. Once you have such a key, any coins sent to such a policy can be taken by yourself. By requiring attributes such as "issued_in=2012/06" the policies can be expired when needed (at the cost of an additional block chain transaction to update the hash).</div>Mikehttps://en.bitcoin.it/w/index.php?title=Bitcoin_Improvement_Proposals&diff=32176Bitcoin Improvement Proposals2012-10-29T14:14:29Z<p>Mike: link to bip 37</p>
<hr />
<div>People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.<br />
<br />
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.<br />
<br />
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.<br />
<br />
Those proposing changes should consider that ultimately consent may rest with the [[economic majority]].<br />
<br />
{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"<br />
!Number<br />
!Title<br />
!Owner<br />
!Status<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0001|1]]<br />
| BIP Purpose and Guidelines<br />
| Amir Taaki<br />
| Active<br />
|-<br />
| [[BIP 0010|10]]<br />
| Multi-Sig Transaction Distribution<br />
| Alan Reiner<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0011|11]]<br />
| M-of-N Standard Transactions<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0012|12]]<br />
| OP_EVAL<br />
| Gavin Andresen<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0013|13]]<br />
| Address Format for pay-to-script-hash<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0014|14]]<br />
| Protocol Version and User Agent<br />
| Amir Taaki, Patrick Strateman<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0015|15]]<br />
| Aliases<br />
| Amir Taaki<br />
| Withdrawn<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0016|16]]<br />
| Pay To Script Hash<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0017|17]]<br />
| OP_CHECKHASHVERIFY (CHV)<br />
| Luke Dashjr<br />
| Withdrawn<br />
|-<br />
| [[BIP 0018|18]]<br />
| hashScriptCheck<br />
| Luke Dashjr<br />
| Draft<br />
|-<br />
| [[BIP 0019|19]]<br />
| M-of-N Standard Transactions (Low SigOp)<br />
| Luke Dashjr<br />
| Draft<br />
|- style="background-color: #ffcfcf"<br />
| [[BIP 0020|20]]<br />
| URI Scheme<br />
| Luke Dashjr<br />
| Replaced<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0021|21]]<br />
| URI Scheme<br />
| Nils Schneider, Matt Corallo<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0022|22]]<br />
| getblocktemplate - Fundamentals<br />
| Luke Dashjr<br />
| Accepted<br />
|-<br />
| [[BIP 0023|23]]<br />
| getblocktemplate - Pooled Mining<br />
| Luke Dashjr<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0030|30]]<br />
| Duplicate transactions<br />
| Pieter Wuille<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0031|31]]<br />
| Pong message<br />
| Mike Hearn<br />
| Accepted<br />
|-<br />
| [[BIP 0032|32]]<br />
| Hierarchical Deterministic Wallets<br />
| Pieter Wuille<br />
| Draft<br />
|-<br />
| [[BIP 0033|33]]<br />
| Stratized Nodes<br />
| Amir Taaki<br />
| Draft<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0034|34]]<br />
| Block v2, Height in coinbase<br />
| Gavin Andresen<br />
| Accepted<br />
|- style="background-color: #cfffcf"<br />
| [[BIP 0035|35]]<br />
| mempool message<br />
| Jeff Garzik<br />
| Accepted<br />
|-<br />
| [[BIP 0036|36]]<br />
| Custom Services<br />
| Stefan Thomas<br />
| Draft<br />
|-<br />
| [[BIP 0037|37]]<br />
| Bloom filtering<br />
| Mike Hearn and Matt Corallo<br />
| Draft<br />
|}<br />
<br />
[[Hardfork Wishlist]]<br />
<br />
[[Category:BIP|Z]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=BIP_0037&diff=32005BIP 00372012-10-24T16:49:21Z<p>Mike: </p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 37<br />
Title: Connection Bloom filtering<br />
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me><br />
Status: Draft<br />
Type: Standards Track<br />
Created: 24-10-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.<br />
<br />
This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.<br />
<br />
==Motivation==<br />
<br />
As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.<br />
<br />
Today, SPV clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.<br />
<br />
==Design rationale==<br />
<br />
The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:<br />
<br />
* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).<br />
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.<br />
<br />
==Specification==<br />
<br />
===New messages===<br />
<br />
We start by adding three new messages to the protocol:<br />
<br />
* <code>filterload</code>, which sets the current Bloom filter on the connection<br />
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set<br />
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.<br />
<br />
Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.<br />
<br />
The <code>filterload</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.<br />
|-<br />
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.<br />
|}<br />
<br />
See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.<br />
<br />
Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.<br />
<br />
The <code>filteradd</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || data || uint8_t[] || The data element to add to the current filter.<br />
|}<br />
<br />
The data field can be of any size up to the maximum message size limit.<br />
<br />
The given data element will be added to the Bloom filter. If no filter has been previously provided using <code>filterload</code>, a new one will be initialized that would have a false positive rate of 0.1% with 1000 inserted elements. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer.<br />
<br />
The <code>filterclear</code> command has no arguments at all.<br />
<br />
After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint32_t || Number of transactions that matched the filter<br />
|-<br />
| ? || transactions || merkle_tx[] || A series of merkle_tx messages, defined below, for each transaction in the block that matched the filter.<br />
|}<br />
<br />
The <code>merkle_tx</code> message is defined below:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || index || uint32_t || The index in the original block that the transaction appeared at.<br />
|-<br />
| 32 || hash || uint256_t || The hash of the matching transaction.<br />
|-<br />
| ? || merkle_branch || uint256_t[] || A vector of hashes defining the Merkle branch linking this transaction to the merkle root in the block header<br />
|}<br />
<br />
See below for the format of the merkle branch.<br />
<br />
As you can see a <code>merkleblock</code> message is a block header, plus identifying information for transactions that matched the filter, plus the Merkle branch which can be used to prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.<br />
<br />
===Extensions to existing messages===<br />
<br />
The <code>version</code> command is extended with a new field:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.<br />
|}<br />
<br />
SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.<br />
<br />
The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, any transactions that the requesting node hasn't either received or announced with an inv will be automatically sent as well. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them).<br />
<br />
===Filter matching algorithm===<br />
<br />
The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.<br />
<br />
To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.<br />
<br />
# Test the hash of the transaction itself.<br />
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.<br />
# For each input, test the serialized COutPoint structure.<br />
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).<br />
# Otherwise there is no match.<br />
<br />
In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].<br />
<br />
The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:<br />
<br />
# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.<br />
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.<br />
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.<br />
<br />
By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.<br />
<br />
===Merkle branch format===<br />
<br />
A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.<br />
<br />
The branch is a list of hashes that can be used with the following algorithm.<br />
<br />
# Let H = the hash of the transaction being checked for block inclusion.<br />
# Let I = the index in the original block of the transaction being checked.<br />
# For each element E in the branch:<br />
## If I is even, H = SHA256(SHA256(concatenation of E and H))<br />
## If I is odd, H = SHA256(SHA256(concatenation of H and E))<br />
## Divide I by 2 (right-shift)<br />
# If H is equal to the merkle root in the block header, the transaction was included<br />
<br />
===Bloom filter format===<br />
<br />
A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:<br />
<br />
<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code><br />
<br />
i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.<br />
<br />
When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:<br />
<br />
Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.<br />
<br />
The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).<br />
<br />
The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.<br />
<br />
==Copyright==<br />
<br />
This document is placed in the public domain.<br />
<br />
[[Category:Developer]]<br />
[[Category:Technical]]<br />
[[Category:BIP|D]]</div>Mikehttps://en.bitcoin.it/w/index.php?title=BIP_0037&diff=32004BIP 00372012-10-24T15:53:49Z<p>Mike: Initial draft of a BIP for Bloom filters</p>
<hr />
<div>{{bip}}<br />
<br />
<pre><br />
BIP: 37<br />
Title: Connection Bloom filtering<br />
Author: Mike Hearn <hearn@google.com>, Matt Corallo <bip@bluematt.me><br />
Status: Draft<br />
Type: Standards Track<br />
Created: 24-10-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives.<br />
<br />
This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic.<br />
<br />
==Motivation==<br />
<br />
As Bitcoin grows in usage the amount of bandwidth needed to download blocks and transaction broadcasts increases. Clients implementing ''simplified payment verification'' do not attempt to fully verify the block chain, instead just checking that block headers connect together correctly and trusting that the transactions in a chain of high difficulty are in fact valid. See the Bitcoin paper for more detail on this mode.<br />
<br />
Today, SPV clients have to download the entire contents of blocks and all broadcast transactions, only to throw away the vast majority of the transactions that are not relevant to their wallets. This slows down their synchronization process, wastes users bandwidth (which on phones is often metered) and increases memory usage. All three problems are triggering real user complaints for the Android "Bitcoin Wallet" app which implements SPV mode. In order to make chain synchronization fast, cheap and able to run on older phones with limited memory we want to have remote peers throw away irrelevant transactions before sending them across the network.<br />
<br />
==Design rationale==<br />
<br />
The most obvious way to implement the stated goal would be for clients to upload lists of their keys to the remote node. We take a more complex approach for the following reasons:<br />
<br />
* Privacy: Because Bloom filters are probabilistic, with the false positive rate chosen by the client, nodes can trade off precision vs bandwidth usage. A node with access to lots of bandwidth may choose to have a high FP rate, meaning the remote peer cannot accurately know which transactions belong to the client and which don't. A node with very little bandwidth may choose to use a very accurate filter meaning that they only get sent transactions actually relevant to their wallet, but remote peers may be able to correlate transactions with IP addresses (and each other).<br />
* Bloom filters are compact and testing membership in them is fast. This results in satisfying performance characteristics with minimal risk of opening up potential for DoS attacks.<br />
<br />
==Specification==<br />
<br />
===New messages===<br />
<br />
We start by adding three new messages to the protocol:<br />
<br />
* <code>filterload</code>, which sets the current Bloom filter on the connection<br />
* <code>filteradd</code>, which adds the given data element to the connections current filter without requiring a completely new one to be set<br />
* <code>filterclear</code>, which deletes the current filter and goes back to regular pre-BIP37 usage.<br />
<br />
Note that there is no filterremove command because by their nature, Bloom filters are append-only data structures. Once an element is added it cannot be removed again without rebuilding the entire structure from scratch.<br />
<br />
The <code>filterload</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || filter || uint8_t[] || The filter itself is simply a bit field of arbitrary byte-aligned size. The maximum size is 36,000 bytes.<br />
|-<br />
| 4 || nHashFuncs || uint32_t || The number of hash functions to use in this filter. The maximum value allowed in this field is 50.<br />
|}<br />
<br />
See below for a description of the Bloom filter algorithm and how to select nHashFuncs and filter size for a desired false positive rate.<br />
<br />
Upon receiving a <code>filterload</code> command, the remote peer will immediately restrict the broadcast transactions it announces (in inv packets) to transactions matching the filter, where the matching algorithm is specified below.<br />
<br />
The <code>filteradd</code> command is defined as follows:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| ? || data || uint8_t[] || The data element to add to the current filter.<br />
|}<br />
<br />
The data field can be of any size up to the maximum message size limit.<br />
<br />
The given data element will be added to the Bloom filter. If no filter has been previously provided using <code>filterload</code>, a new one will be initialized that would have a false positive rate of 0.1% with 1000 inserted elements. This command is useful if a new key or script is added to a clients wallet whilst it has connections to the network open, it avoids the need to re-calculate and send an entirely new filter to every peer.<br />
<br />
The <code>filterclear</code> command has no arguments at all.<br />
<br />
After a filter has been set, nodes don't merely stop announcing non-matching transactions, they can also serve filtered blocks. A filtered block is defined by the <code>merkleblock</code> message and is defined like this:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || version || uint32_t || Block version information, based upon the software version creating this block<br />
|-<br />
| 32 || prev_block || char[32] || The hash value of the previous block this particular block references<br />
|-<br />
| 32 || merkle_root || char[32] || The reference to a Merkle tree collection which is a hash of all transactions related to this block<br />
|-<br />
| 4 || timestamp || uint32_t || A timestamp recording when this block was created (Limited to 2106!)<br />
|-<br />
| 4 || bits || uint32_t || The calculated difficulty target being used for this block<br />
|-<br />
| 4 || nonce || uint32_t || The nonce used to generate this block… to allow variations of the header and compute different hashes<br />
|-<br />
| 1 || txn_count || uint8_t || Number of transactions that matched the filter<br />
|-<br />
| ? || transactions || merkle_tx[] || A series of merkle_tx messages, defined below, for each transaction in the block that matched the filter.<br />
|}<br />
<br />
The <code>merkle_tx</code> message is defined below:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 4 || index || uint32_t || The index in the original block that the transaction appeared at.<br />
|-<br />
| 32 || hash || uint256_t || The hash of the matching transaction.<br />
|-<br />
| ? || merkle_branch || uint256_t[] || A vector of hashes defining the Merkle branch linking this transaction to the merkle root in the block header<br />
|}<br />
<br />
See below for the format of the merkle branch.<br />
<br />
As you can see a <code>merkleblock</code> message is a block header, plus identifying information for transactions that matched the filter, plus the Merkle branch which can be used to prove that the matching transaction data really did appear in the solved block. Clients can use this data to be sure that the remote node is not feeding them fake transactions that never appeared in a real block, although lying through omission is still possible.<br />
<br />
===Extensions to existing messages===<br />
<br />
The <code>version</code> command is extended with a new field:<br />
<br />
{|class="wikitable"<br />
! Field Size !! Description !! Data type !! Comments<br />
|-<br />
| 1 byte || fRelay || bool || If false then broadcast transactions will not be announced until a filter{load,add,clear} command is received. If missing or true, no change in protocol behaviour occurs.<br />
|}<br />
<br />
SPV clients that wish to use Bloom filtering would normally set fRelay to false in the version message, then set a filter based on their wallet (or a subset of it, if they are overlapping different peers). Being able to opt-out of inv messages until the filter is set prevents a client being flooded with traffic in the brief window of time between finishing version handshaking and setting the filter.<br />
<br />
The <code>getdata</code> command is extended to allow a new type in the <code>inv</code> submessage. The type field can now be <code>MSG_FILTERED_BLOCK (== 3)</code> rather than <code>MSG_BLOCK</code>. If no filter has been set on the connection, a request for filtered blocks is ignored. If a filter has been set, a <code>merkleblock</code> message is returned for the requested block hash. In addition, because a <code>merkleblock</code> message contains only a list of transaction hashes, any transactions that the requesting node hasn't either received or announced with an inv will be automatically sent as well. This avoids a slow roundtrip that would otherwise be required (receive hashes, didn't see some of these transactions yet, ask for them).<br />
<br />
===Filter matching algorithm===<br />
<br />
The filter can be tested against arbitrary pieces of data, to see if that data was inserted by the client. Therefore the question arises of what pieces of data should be inserted/tested.<br />
<br />
To determine if a transaction matches the filter, the following algorithm MUST be used. Once a match is found the algorithm aborts.<br />
<br />
# Test the hash of the transaction itself.<br />
# For each output, test each data element of the output script. This means each hash and key in the output script is tested independently. '''Important:''' if an output matches whilst testing a transaction, the node MUST update the filter by inserting the serialized COutPoint structure. See below for more details.<br />
# For each input, test the serialized COutPoint structure.<br />
# For each input, test each data element of the input script (note: input scripts only ever contain data elements).<br />
# Otherwise there is no match.<br />
<br />
In this way addresses, keys and script hashes (for P2SH outputs) can all be added to the filter. You can also match against classes of transactions that are marked with well known data elements in either inputs or outputs, for example, to implement various forms of [[Smart property]].<br />
<br />
The test for outpoints is there to ensure you can find transactions spending outputs in your wallet, even though you don't know anything about their form. As you can see, once set on a connection the filter is '''not static''' and can change throughout the connections lifetime. This is done to avoid the following race condition:<br />
<br />
# A client sets a filter matching a key in their wallet. They then start downloading the block chain. The part of the chain that the client is missing is requested using getblocks.<br />
# The first block is read from disk by the serving peer. It contains TX 1 which sends money to the clients key. It matches the filter and is thus sent to the client.<br />
# The second block is read from disk by the serving peer. It contains TX 2 which spends TX 1. However TX 2 does not contain any of the clients keys and is thus not sent. The client does not know the money they received was already spent.<br />
<br />
By updating the bloom filter atomically in step 2 with the discovered outpoint, the filter will match against TX 2 in step 3 and the client will learn about all relevant transactions, despite that there is no pause between the node processing the first and second blocks.<br />
<br />
===Merkle branch format===<br />
<br />
A ''Merkle tree'' is a way of arranging a set of items as leaf nodes of tree in which the interior nodes are hashes of the concatenations of their child hashes. The root node is called the ''Merkle root''. Every Bitcoin block contains a Merkle root of the tree formed from the blocks transactions. By providing some elements of the trees interior nodes (called a ''Merkle branch'') a proof is formed that the given transaction was indeed in the block when it was being mined, but the size of the proof is much smaller than the size of the original block.<br />
<br />
The branch is a list of hashes that can be used with the following algorithm.<br />
<br />
# Let H = the hash of the transaction being checked for block inclusion.<br />
# Let I = the index in the original block of the transaction being checked.<br />
# For each element E in the branch:<br />
## If I is even, H = SHA256(SHA256(concatenation of E and H))<br />
## If I is odd, H = SHA256(SHA256(concatenation of H and E))<br />
## Divide I by 2 (right-shift)<br />
# If H is equal to the merkle root in the block header, the transaction was included<br />
<br />
===Bloom filter format===<br />
<br />
A Bloom filter is a bit-field in which bits are set based on feeding the data element to a set of different hash functions. The number of hash functions used is a parameter of the filter. In Bitcoin we use version 3 of the 32-bit Murmur hash function. To get N "different" hash functions we simply initialize the Murmur algorithm with the following formula:<br />
<br />
<code>nHashNum * (MAX_UINT32 / (nHashFuncs - 1))</code><br />
<br />
i.e. if the filter is initialized with 4 hash functions, when the second function is needed h1 would be equal to 1431655765.<br />
<br />
When loading a filter with the <code>filterload</code> command, there are two parameters that can be chosen. One is the size of the filter in bytes. The other is the number of hash functions to use. To select the parameters you can use the following formulas:<br />
<br />
Let N be the number of elements you wish to insert into the set and P be the probability of a false positive, where 1.0 is "match everything" and zero is unachievable.<br />
<br />
The size S of the filter in bytes is given by <code>(-1 / pow(log(2), 2) * N * log(P)) / 8</code>. Of course you must ensure it does not go over the maximum size (36,000).<br />
<br />
The number of hash functions required is given by <code>S * 8 / N * log(2)</code>.<br />
<br />
==Copyright==<br />
<br />
This document is placed in the public domain.<br />
<br />
[[Category:Developer]]<br />
[[Category:Technical]]<br />
[[Category:BIP|D]]</div>Mike