https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Mckoss&feedformat=atomBitcoin Wiki - User contributions [en]2024-03-28T23:16:35ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Protocol_rules&diff=25977Protocol rules2012-05-01T23:49:22Z<p>Mckoss: Add concrete value for COINBASE_MATURITY - source bitcoind/main.h</p>
<hr />
<div>'''Rules''' for [[:Category:Clients|clients]].<br />
<br />
The wiki substantially documents the [[Protocol_specification|Bitcoin protocol]], but equally important are the rules used by the client to process messages. It's crucial that clients follow certain rules in order to maintain consistency across the network, and to protect the Bitcoin security guarantees.<br />
<br />
Here, the focus is on handling tx and block messages, because that is the tricky logic. This will skip over the method of requesting and forwarding these messages for now, and describe what to do when they are received. Also, this will describe the minimal data structures in rather abstract terms, ignoring the client's various indexes, maps and hash tables used for efficiency. This will be a conceptual description. This is all based on a fairly literal reading of the source code.<br />
<br />
Mining (block generation) rules are not yet presented.<br />
<br />
== Data structures ==<br />
<br />
The main data structures are [[transactions]] and [[blocks]]. Blocks are composed of the ''block header'' followed by transactions in the block. Transactions are identified by their hash; blocks by the hash of their header. Blocks have prev pointers that link them into a graph.<br />
<br />
Conceptually, the client has the following data structures:<br />
<br />
=== Transactions ===<br />
<br />
There are two collections of transactions:<br />
<br />
;transaction pool<br />
: an unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions<br />
<br />
;orphan transactions<br />
: transactions that can't go into the pool due to one or more missing input transactions<br />
<br />
=== Blocks ===<br />
<br />
There are 3 categories of blocks:<br />
<br />
;blocks in the main branch<br />
: the transactions in these blocks are considered at least tentatively confirmed<br />
<br />
;blocks on side branches off the main branch<br />
: these blocks have at least tentatively lost the race to be in the main branch<br />
<br />
;orphan blocks<br />
: these are blocks which don't link into the main branch, normally because of a missing predecessor or nth-level predecessor<br />
<br />
Blocks in the first two categories form a tree rooted at the [[genesis block]], linked by the prev pointer, which points toward the root. (It is a very linear tree with few and short branches off the main branch.) The main branch is defined as the branch with highest total difficulty, summing the difficulties for each block in the branch.<br />
<br />
See also [[Block Status]].<br />
<br />
== Difficulty change ==<br />
<br />
The difficulty changes every 2016 blocks. This choice is designed to occur approximately every two weeks.<br />
<br />
: 2 weeks / 10 minutes = 14 * 24 * 60 / 10 = 2016<br />
<br />
Once 2016 blocks has been reached we loop back until we hit the 2016th block before the current one. We find the difference in time between the current block and that one. This difference (called the actual timespan) is limited in bounds between [2 weeks/4, 2 weeks*4].<br />
<br />
Then we get the last target for this old 2 week window and multiply it by the ratio of the actual timespan / the target timespan (2 weeks in secs).<br />
<br />
: new target = old target * time for 2016 blocks / 2 weeks.<br />
<br />
If the old set of blocks completed too fast then the target is lowered (difficulty goes up) ensuring it takes longer to solve these new blocks... and vice versa. This way the difficulty oscillates around the ideal of 2 weeks (and 10 mins per block).<br />
<br />
== [[Protocol_specification#tx|"tx"]] messages ==<br />
<br />
These messages hold a single transaction.<br />
<br />
# Check syntactic correctness<br />
# Make sure neither in or out lists are empty<br />
# Size in bytes < MAX_BLOCK_SIZE<br />
# Each output value, as well as the total, must be in legal money range<br />
# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)<br />
# Check that nLockTime <= INT_MAX<ref>nLockTime must not exceed 31 bits, as some clients will interpret it incorrectly</ref>, size in bytes >= 100<ref>A valid transaction requires at least 100 bytes. If it's any less, the transaction is not valid</ref>, and sig opcount <= 2<ref>The number of signature operands in the signature (no, that is not redundant) for standard transactions will never exceed two</ref><br />
# Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms<ref>Note that this is not a hard requirement on clients.</ref><br />
# Reject if we already have matching tx in the pool, or in a block in the main branch<br />
# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref><br />
# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.<br />
# For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject this transaction<br />
# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction<br />
# Verify crypto signatures for each input; reject if any are bad<br />
# For each input, if the referenced output has already been spent by a transaction in the main branch, reject this transaction<ref>This is the protection against double-spending</ref><br />
# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
# Reject if the sum of input values < sum of output values<br />
# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block<br />
# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (50BTC as of this writing).</ref><br />
# "Add to wallet if mine"<br />
# Relay transaction to peers<br />
# For each orphan transaction that uses this one as one of its inputs, run all these steps (including this one) recursively on that orphan<br />
<br />
===Explanation of Some Rules===<br />
Most rules are self-explanatory. This section explains why some of the less obvious rules are in place.<br />
<references/><br />
<br />
== [[Protocol_specification#block|"block"]] messages ==<br />
<br />
These messages hold a single block.<br />
<br />
# Check syntactic correctness<br />
# Reject if duplicate of block we have in any of the three categories<br />
# Transaction list must be non-empty<br />
# Block hash must satisfy claimed ''nBits'' proof of work<br />
# Block timestamp must not be more than two hours in the future<br />
# First transaction must be coinbase (i.e. only 1 input, with hash=0, n=-1), the rest must not be<br />
# For each transaction, apply "tx" checks 2-4<br />
# For the coinbase (first) transaction, scriptSig length must be 2-100<br />
# Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS<br />
# Verify Merkle hash<br />
# Check if prev block (matching ''prev'' hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in ''prev'' chain; done with block<br />
# Check that ''nBits'' value matches the difficulty rules<br />
# Reject if timestamp is before the median time of the last 11 blocks<br />
# For certain old blocks (i.e. on initial block download) check that hash matches known values<br />
# Add block into the tree. There are three cases: 1. block further extends the main branch; 2. block extends a side branch but does not add enough difficulty to make it become the new main branch; 3. block extends a side branch and makes it the new main branch.<br />
# For case 1, adding to main branch:<br />
## For all but the coinbase transaction, apply the following:<br />
### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.<br />
### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.<br />
### For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject.<br />
### Verify crypto signatures for each input; reject if any are bad<br />
### For each input, if the referenced output has already been spent by a transaction in the main branch, reject<br />
### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
### Reject if the sum of input values < sum of output values<br />
## Reject if coinbase value > sum of block creation fee and transaction fees<br />
## (If we have not rejected):<br />
## For each transaction, "Add to wallet if mine"<br />
## For each transaction in the block, delete any matching transaction from the transaction pool<br />
## Relay block to our peers<br />
## If we rejected, the block is not counted as part of the main branch<br />
# For case 2, adding to a side branch, we don't do anything.<br />
# For case 3, a side branch becoming the main branch:<br />
## Find the ''fork'' block on the main branch which this side branch forks off of<br />
## Redefine the main branch to only go up to this ''fork'' block<br />
## For each block on the side branch, from the child of the ''fork'' block to the leaf, add to the main branch:<br />
### Do "branch" checks 3-11<br />
### For all but the coinbase transaction, apply the following:<br />
#### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.<br />
#### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.<br />
#### For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject.<br />
#### Verify crypto signatures for each input; reject if any are bad<br />
#### For each input, if the referenced output has already been spent by a transaction in the main branch, reject<br />
#### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
#### Reject if the sum of input values < sum of output values<br />
### Reject if coinbase value > sum of block creation fee and transaction fees<br />
### (If we have not rejected):<br />
### For each transaction, "Add to wallet if mine"<br />
## If we reject at any point, leave the main branch as what it was originally, done with block<br />
## For each block in the old main branch, from the leaf down to the child of the ''fork'' block:<br />
### For each non-coinbase transaction in the block:<br />
#### Apply "tx" checks 2-9, except in step 8, only look in the transaction pool for duplicates, not the main branch<br />
#### Add to transaction pool if accepted, else go on to next transaction<br />
## For each block in the new main branch, from the child of the ''fork'' node to the leaf:<br />
### For each transaction in the block, delete any matching transaction from the transaction pool<br />
## Relay block to our peers<br />
# For each orphan block for which this block is its ''prev'', run all these steps (including this one) recursively on that orphan<br />
<br />
== See Also ==<br />
<br />
* [[Protocol specification]]<br />
<br />
[[Category:Technical]][[Category:Developer]]</div>Mckosshttps://tests.bitcoin.it/w/index.php?title=Protocol_rules&diff=19995Protocol rules2011-11-26T21:41:12Z<p>Mckoss: /* Difficulty change */ indent equation</p>
<hr />
<div>'''Rules''' for [[:Category:Clients|clients]].<br />
<br />
The wiki substantially documents the [[Protocol_specification|Bitcoin protocol]], but equally important are the rules used by the client to process messages. It's crucial that clients follow certain rules in order to maintain consistency across the network, and to protect the Bitcoin security guarantees.<br />
<br />
Here, the focus is on handling tx and block messages, because that is the tricky logic. This will skip over the method of requesting and forwarding these messages for now, and describe what to do when they are received. Also, this will describe the minimal data structures in rather abstract terms, ignoring the client's various indexes, maps and hash tables used for efficiency. This will be a conceptual description. This is all based on a fairly literal reading of the source code.<br />
<br />
Mining (block generation) rules are not yet presented.<br />
<br />
== Data structures ==<br />
<br />
The main data structures are [[transactions]] and [[blocks]]. Blocks are composed of the ''block header'' followed by transactions in the block. Transactions are identified by their hash; blocks by the hash of their header. Blocks have prev pointers that link them into a graph.<br />
<br />
Conceptually, the client has the following data structures:<br />
<br />
=== Transactions ===<br />
<br />
There are two collections of transactions:<br />
<br />
;transaction pool<br />
: an unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions<br />
<br />
;orphan transactions<br />
: transactions that can't go into the pool due to one or more missing input transactions<br />
<br />
=== Blocks ===<br />
<br />
There are 3 categories of blocks:<br />
<br />
;blocks in the main branch<br />
: the transactions in these blocks are considered at least tentatively confirmed<br />
<br />
;blocks on side branches off the main branch<br />
: these blocks have at least tentatively lost the race to be in the main branch<br />
<br />
;orphan blocks<br />
: these are blocks which don't link into the main branch, normally because of a missing predecessor or nth-level predecessor<br />
<br />
Blocks in the first two categories form a tree rooted at the [[genesis block]], linked by the prev pointer, which points toward the root. (It is a very linear tree with few and short branches off the main branch.) The main branch is defined as the branch with highest total difficulty, summing the difficulties for each block in the branch.<br />
<br />
== Difficulty change ==<br />
<br />
The difficulty changes every 2016 blocks. This choice is designed to occur approximately every two weeks.<br />
<br />
: 2 weeks / 10 minutes = 14 * 24 * 60 / 10 = 2016<br />
<br />
Once 2016 blocks has been reached we loop back until we hit the 2016th block before the current one. We find the difference in time between the current block and that one. This difference (called the actual timespan) is limited in bounds between [2 weeks/4, 2 weeks*4].<br />
<br />
Then we get the last target for this old 2 week window and multiply it by the ratio of the actual timespan / the target timespan (2 weeks in secs).<br />
<br />
: new target = old target * time for 2016 blocks / 2 weeks.<br />
<br />
If the old set of blocks completed too fast then the target is lowered (difficulty goes up) ensuring it takes longer to solve these new blocks... and vice versa. This way the difficulty oscillates around the ideal of 2 weeks (and 10 mins per block).<br />
<br />
== [[Protocol_specification#tx|"tx"]] messages ==<br />
<br />
These messages hold a single transaction.<br />
<br />
# Check syntactic correctness<br />
# Make sure neither in or out lists are empty<br />
# Size in bytes < MAX_BLOCK_SIZE<br />
# Each output value, as well as the total, must be in legal money range<br />
# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)<br />
# Check that nLockTime <= INT_MAX<ref>nLockTime must not exceed 31 bits, as some clients will interpret it incorrectly</ref>, size in bytes >= 100<ref>A valid transaction requires at least 100 bytes. If it's any less, the transaction is not valid</ref>, and sig opcount <= 2<ref>The number of signature operands in the signature (no, that is not redundant) for standard transactions will never exceed two</ref><br />
# Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms<ref>Note that this is not a hard requirement on clients.</ref><br />
# Reject if we already have matching tx in the pool, or in a block in the main branch<br />
# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref><br />
# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.<br />
# For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject this transaction<br />
# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY confirmations; else reject this transaction<br />
# Verify crypto signatures for each input; reject if any are bad<br />
# For each input, if the referenced output has already been spent by a transaction in the main branch, reject this transaction<ref>This is the protection against double-spending</ref><br />
# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
# Reject if the sum of input values < sum of output values<br />
# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block<br />
# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (50BTC as of this writing).</ref><br />
# "Add to wallet if mine"<br />
# Relay transaction to peers<br />
# For each orphan transaction that uses this one as one of its inputs, run all these steps (including this one) recursively on that orphan<br />
<br />
===Explanation of Some Rules===<br />
Most rules are self-explanatory. This section explains why some of the less obvious rules are in place.<br />
<references/><br />
<br />
== [[Protocol_specification#block|"block"]] messages ==<br />
<br />
These messages hold a single block.<br />
<br />
# Check syntactic correctness<br />
# Reject if duplicate of block we have in any of the three categories<br />
# Transaction list must be non-empty<br />
# Block hash must satisfy claimed ''nBits'' proof of work<br />
# Block timestamp must not be more than two hours in the future<br />
# First transaction must be coinbase (i.e. only 1 input, with hash=0, n=-1), the rest must not be<br />
# For each transaction, apply "tx" checks 2-4<br />
# For the coinbase (first) transaction, scriptSig length must be 2-100<br />
# Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS<br />
# Verify Merkle hash<br />
# Check if prev block (matching ''prev'' hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in ''prev'' chain; done with block<br />
# Check that ''nBits'' value matches the difficulty rules<br />
# Reject if timestamp is before the median time of the last 11 blocks<br />
# For certain old blocks (i.e. on initial block download) check that hash matches known values<br />
# Add block into the tree. There are three cases: 1. block further extends the main branch; 2. block extends a side branch but does not add enough difficulty to make it become the new main branch; 3. block extends a side branch and makes it the new main branch.<br />
# For case 1, adding to main branch:<br />
## For all but the coinbase transaction, apply the following:<br />
### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.<br />
### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.<br />
### For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY confirmations; else reject.<br />
### Verify crypto signatures for each input; reject if any are bad<br />
### For each input, if the referenced output has already been spent by a transaction in the main branch, reject<br />
### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
### Reject if the sum of input values < sum of output values<br />
## Reject if coinbase value > sum of block creation fee and transaction fees<br />
## (If we have not rejected):<br />
## For each transaction, "Add to wallet if mine"<br />
## For each transaction in the block, delete any matching transaction from the transaction pool<br />
## Relay block to our peers<br />
## If we rejected, the block is not counted as part of the main branch<br />
# For case 2, adding to a side branch, we don't do anything.<br />
# For case 3, a side branch becoming the main branch:<br />
## Find the ''fork'' block on the main branch which this side branch forks off of<br />
## Redefine the main branch to only go up to this ''fork'' block<br />
## For each block on the side branch, from the child of the ''fork'' block to the leaf, add to the main branch:<br />
### Do "branch" checks 3-11<br />
### For all but the coinbase transaction, apply the following:<br />
#### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.<br />
#### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.<br />
#### For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY confirmations; else reject.<br />
#### Verify crypto signatures for each input; reject if any are bad<br />
#### For each input, if the referenced output has already been spent by a transaction in the main branch, reject<br />
#### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
#### Reject if the sum of input values < sum of output values<br />
### Reject if coinbase value > sum of block creation fee and transaction fees<br />
### (If we have not rejected):<br />
### For each transaction, "Add to wallet if mine"<br />
## If we reject at any point, leave the main branch as what it was originally, done with block<br />
## For each block in the old main branch, from the leaf down to the child of the ''fork'' block:<br />
### For each non-coinbase transaction in the block:<br />
#### Apply "tx" checks 2-9, except in step 8, only look in the transaction pool for duplicates, not the main branch<br />
#### Add to transaction pool if accepted, else go on to next transaction<br />
## For each block in the new main branch, from the child of the ''fork'' node to the leaf:<br />
### For each transaction in the block, delete any matching transaction from the transaction pool<br />
## Relay block to our peers<br />
# For each orphan block for which this block is its ''prev'', run all these steps (including this one) recursively on that orphan<br />
<br />
== See Also ==<br />
<br />
* [[Protocol specification]]<br />
<br />
[[Category:Technical]][[Category:Developer]]</div>Mckosshttps://tests.bitcoin.it/w/index.php?title=Protocol_rules&diff=19994Protocol rules2011-11-26T21:40:11Z<p>Mckoss: Simplify difficulty block count explanation</p>
<hr />
<div>'''Rules''' for [[:Category:Clients|clients]].<br />
<br />
The wiki substantially documents the [[Protocol_specification|Bitcoin protocol]], but equally important are the rules used by the client to process messages. It's crucial that clients follow certain rules in order to maintain consistency across the network, and to protect the Bitcoin security guarantees.<br />
<br />
Here, the focus is on handling tx and block messages, because that is the tricky logic. This will skip over the method of requesting and forwarding these messages for now, and describe what to do when they are received. Also, this will describe the minimal data structures in rather abstract terms, ignoring the client's various indexes, maps and hash tables used for efficiency. This will be a conceptual description. This is all based on a fairly literal reading of the source code.<br />
<br />
Mining (block generation) rules are not yet presented.<br />
<br />
== Data structures ==<br />
<br />
The main data structures are [[transactions]] and [[blocks]]. Blocks are composed of the ''block header'' followed by transactions in the block. Transactions are identified by their hash; blocks by the hash of their header. Blocks have prev pointers that link them into a graph.<br />
<br />
Conceptually, the client has the following data structures:<br />
<br />
=== Transactions ===<br />
<br />
There are two collections of transactions:<br />
<br />
;transaction pool<br />
: an unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions<br />
<br />
;orphan transactions<br />
: transactions that can't go into the pool due to one or more missing input transactions<br />
<br />
=== Blocks ===<br />
<br />
There are 3 categories of blocks:<br />
<br />
;blocks in the main branch<br />
: the transactions in these blocks are considered at least tentatively confirmed<br />
<br />
;blocks on side branches off the main branch<br />
: these blocks have at least tentatively lost the race to be in the main branch<br />
<br />
;orphan blocks<br />
: these are blocks which don't link into the main branch, normally because of a missing predecessor or nth-level predecessor<br />
<br />
Blocks in the first two categories form a tree rooted at the [[genesis block]], linked by the prev pointer, which points toward the root. (It is a very linear tree with few and short branches off the main branch.) The main branch is defined as the branch with highest total difficulty, summing the difficulties for each block in the branch.<br />
<br />
== Difficulty change ==<br />
<br />
The difficulty changes every 2016 blocks. This choice is designed to occur approximately every two weeks.<br />
<br />
: 2 weeks / 10 minutes = 14 * 24 * 60 / 10 = 2016<br />
<br />
Once 2016 blocks has been reached we loop back until we hit the 2016th block before the current one. We find the difference in time between the current block and that one. This difference (called the actual timespan) is limited in bounds between [2 weeks/4, 2 weeks*4].<br />
<br />
Then we get the last target for this old 2 week window and multiply it by the ratio of the actual timespan / the target timespan (2 weeks in secs).<br />
<br />
new target = old target * time for 2016 blocks / 2 weeks.<br />
<br />
If the old set of blocks completed too fast then the target is lowered (difficulty goes up) ensuring it takes longer to solve these new blocks... and vice versa. This way the difficulty oscillates around the ideal of 2 weeks (and 10 mins per block).<br />
<br />
== [[Protocol_specification#tx|"tx"]] messages ==<br />
<br />
These messages hold a single transaction.<br />
<br />
# Check syntactic correctness<br />
# Make sure neither in or out lists are empty<br />
# Size in bytes < MAX_BLOCK_SIZE<br />
# Each output value, as well as the total, must be in legal money range<br />
# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)<br />
# Check that nLockTime <= INT_MAX<ref>nLockTime must not exceed 31 bits, as some clients will interpret it incorrectly</ref>, size in bytes >= 100<ref>A valid transaction requires at least 100 bytes. If it's any less, the transaction is not valid</ref>, and sig opcount <= 2<ref>The number of signature operands in the signature (no, that is not redundant) for standard transactions will never exceed two</ref><br />
# Reject "nonstandard" transactions: scriptSig doing anything other than pushing numbers on the stack, or scriptPubkey not matching the two usual forms<ref>Note that this is not a hard requirement on clients.</ref><br />
# Reject if we already have matching tx in the pool, or in a block in the main branch<br />
# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>Note that this is not a hard requirement on clients. The network-enforced rule is that only <i>one</i> transaction spending a particular output can be in the blockchain, thus preventing double-spending. Technically miners can choose which one they want to put into the block they're working on as long as no other transaction has spent that output either previously in the blockchain, or in the same block. The in-memory transaction pool can technically be managed in whatever way the miner is willing to implement.</ref><br />
# For each input, look in the main branch and the transaction pool to find the referenced output transaction. If the output transaction is missing for any input, this will be an orphan transaction. Add to the orphan transactions, if a matching transaction is not in there already.<br />
# For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject this transaction<br />
# For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY confirmations; else reject this transaction<br />
# Verify crypto signatures for each input; reject if any are bad<br />
# For each input, if the referenced output has already been spent by a transaction in the main branch, reject this transaction<ref>This is the protection against double-spending</ref><br />
# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
# Reject if the sum of input values < sum of output values<br />
# Reject if transaction fee (defined as sum of input values minus sum of output values) would be too low to get into an empty block<br />
# Add to transaction pool<ref>Note that when the transaction is accepted into the memory pool, an additional check is made to ensure that the coinbase value does not exceed the transaction fees plus the expected BTC value (50BTC as of this writing).</ref><br />
# "Add to wallet if mine"<br />
# Relay transaction to peers<br />
# For each orphan transaction that uses this one as one of its inputs, run all these steps (including this one) recursively on that orphan<br />
<br />
===Explanation of Some Rules===<br />
Most rules are self-explanatory. This section explains why some of the less obvious rules are in place.<br />
<references/><br />
<br />
== [[Protocol_specification#block|"block"]] messages ==<br />
<br />
These messages hold a single block.<br />
<br />
# Check syntactic correctness<br />
# Reject if duplicate of block we have in any of the three categories<br />
# Transaction list must be non-empty<br />
# Block hash must satisfy claimed ''nBits'' proof of work<br />
# Block timestamp must not be more than two hours in the future<br />
# First transaction must be coinbase (i.e. only 1 input, with hash=0, n=-1), the rest must not be<br />
# For each transaction, apply "tx" checks 2-4<br />
# For the coinbase (first) transaction, scriptSig length must be 2-100<br />
# Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS<br />
# Verify Merkle hash<br />
# Check if prev block (matching ''prev'' hash) is in main branch or side branches. If not, add this to orphan blocks, then query peer we got this from for 1st missing orphan block in ''prev'' chain; done with block<br />
# Check that ''nBits'' value matches the difficulty rules<br />
# Reject if timestamp is before the median time of the last 11 blocks<br />
# For certain old blocks (i.e. on initial block download) check that hash matches known values<br />
# Add block into the tree. There are three cases: 1. block further extends the main branch; 2. block extends a side branch but does not add enough difficulty to make it become the new main branch; 3. block extends a side branch and makes it the new main branch.<br />
# For case 1, adding to main branch:<br />
## For all but the coinbase transaction, apply the following:<br />
### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.<br />
### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.<br />
### For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY confirmations; else reject.<br />
### Verify crypto signatures for each input; reject if any are bad<br />
### For each input, if the referenced output has already been spent by a transaction in the main branch, reject<br />
### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
### Reject if the sum of input values < sum of output values<br />
## Reject if coinbase value > sum of block creation fee and transaction fees<br />
## (If we have not rejected):<br />
## For each transaction, "Add to wallet if mine"<br />
## For each transaction in the block, delete any matching transaction from the transaction pool<br />
## Relay block to our peers<br />
## If we rejected, the block is not counted as part of the main branch<br />
# For case 2, adding to a side branch, we don't do anything.<br />
# For case 3, a side branch becoming the main branch:<br />
## Find the ''fork'' block on the main branch which this side branch forks off of<br />
## Redefine the main branch to only go up to this ''fork'' block<br />
## For each block on the side branch, from the child of the ''fork'' block to the leaf, add to the main branch:<br />
### Do "branch" checks 3-11<br />
### For all but the coinbase transaction, apply the following:<br />
#### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.<br />
#### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.<br />
#### For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY confirmations; else reject.<br />
#### Verify crypto signatures for each input; reject if any are bad<br />
#### For each input, if the referenced output has already been spent by a transaction in the main branch, reject<br />
#### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range<br />
#### Reject if the sum of input values < sum of output values<br />
### Reject if coinbase value > sum of block creation fee and transaction fees<br />
### (If we have not rejected):<br />
### For each transaction, "Add to wallet if mine"<br />
## If we reject at any point, leave the main branch as what it was originally, done with block<br />
## For each block in the old main branch, from the leaf down to the child of the ''fork'' block:<br />
### For each non-coinbase transaction in the block:<br />
#### Apply "tx" checks 2-9, except in step 8, only look in the transaction pool for duplicates, not the main branch<br />
#### Add to transaction pool if accepted, else go on to next transaction<br />
## For each block in the new main branch, from the child of the ''fork'' node to the leaf:<br />
### For each transaction in the block, delete any matching transaction from the transaction pool<br />
## Relay block to our peers<br />
# For each orphan block for which this block is its ''prev'', run all these steps (including this one) recursively on that orphan<br />
<br />
== See Also ==<br />
<br />
* [[Protocol specification]]<br />
<br />
[[Category:Technical]][[Category:Developer]]</div>Mckosshttps://tests.bitcoin.it/w/index.php?title=Development_process&diff=15487Development process2011-08-24T05:09:06Z<p>Mckoss: Fixed link, and grammar.</p>
<hr />
<div>== Bitcoin Open Source Development Process ==<br />
<br />
The [[Original_Bitcoin_client|Bitcoin client]] project has transitioned from what was essentially a one-person software endeavor, with Satoshi functioning as the primary developer and gatekeeper for all changes, to a more distributed, free software model of development. The Linux Kernel development process is being used as the model for how changes flow into the official Bitcoin application:<br />
# Developers work in their own source code trees, sharing and testing patches with each other. Git, using github, is the preferred source control system for development.<br />
# When a developer thinks a patch is ready, they submit a pull request for the [https://github.com/bitcoin/bitcoin bitcoin github repository] and post a message on the [http://www.bitcoin.org/smf/index.php?board=6.0 Development and Technical Forum].<br />
# Pull requests are discussed on the forums and if there is consensus they're safe, tested, useful, well written, match coding style, etc. then they're merged into the 'master' branch.<br />
# The master github branch is regularly built and tested, and periodically pushed to the [http://sourceforge.net/projects/bitcoin/develop subversion repository] to become a "release candidate" and then the official, stable, released bitcoin.<br />
<br />
Please read and follow [https://raw.github.com/gavinandresen/bitcoin-git/svn/coding.txt coding.txt] for a description of the bitcoin coding style.<br />
<br />
==See Also==<br />
<br />
* [[Original Bitcoin client]]<br />
* [[:Category:Open_Source|Open source]]<br />
<br />
[[Category:Developer]]</div>Mckosshttps://tests.bitcoin.it/w/index.php?title=Merchant_Howto&diff=10974Merchant Howto2011-06-16T16:24:27Z<p>Mckoss: </p>
<hr />
<div>This page is intended as a guide to assist merchants learn how to accept bitcoins for payment.<br />
<br />
==Manual==<br />
# Download a bitcoin client<br />
# When a customer wants to buy something send them a bitcoin address where their payment should be sent.<br />
#* You can do this by clicking "New.." next to your address in the bitcoin client and sending that address to the customer.<br />
# When payment comes in from that address send the goods to your customer. Depending on your risk tolerance and the value of the purchase, you may wish to wait until the payment shows enough confirmations to protect against [[How_bitcoin_works#Double_spending|double spending]].<br />
# To issue a refund, obtain from the customer the [[Address|bitcoin address]] where the refund payment should be sent. The refund address will likely be different from the address used when the customer sent payment, especially if an [[EWallet]] was used by the customer.<br />
<br />
==Automated==<br />
You can use an existing [[:Category:Shopping Cart Interfaces|shopping cart interface]] or utilize the Bitcoin client's [[API tutorial (JSON-RPC)|JSON-RPC API]] to automatically accept payments.<br />
<br />
Setup a system that:<br />
# When a customer orders something on your website it records<br />
#* Bitcoin address that payment should be sent to<br />
#* Order details (delivery address etc.)<br />
#* Customer's refund address (optional - if you wish you can ask for this later, only in cases a refund is required)<br />
#* Payment amount<br />
# When payment arrives, checks that they have paid the correct amount or not, and informs you<br />
#* You dispach the goods to the customer and mark the order as fulfilled<br />
#* If you cannot dispach the goods you mark the order as denied and ask the customer for a refund address (unless you already have it from earlier) to send a refund.<br />
# Forwards the funds to bitcoin address of your choice<br />
<br />
==Common Errors==<br />
<br />
It has been observed several times that businesses try to funnel all orders through the same bitcoin address, and ask people to send some BTC, then send email describing the timing and the amount of the transaction to 'claim' it. This is '''not''' secure, since anyone can see the transaction details using a tool such as [[Block Explorer]], or by inspecting the block chain database directly, and then try to claim someone else's transaction as theirs. Do not do this - give each customer a unique bitcoin address, as suggested in the [[#Manual|manual]] section of this page.<br />
<br />
==Listing your business on the Bitcoin Trade page==<br />
<br />
Anyone can add and update a listing on the [[Trade|trade]] page. Just register if you haven't and add to the appropriate category. If you'ld like assistance, perhaps someone in the [http://webchat.freenode.net/?channels=#bitcoin-marketing #bitcoin-marketing] IRC channel would be willing to assist.<br />
<br />
==See Also==<br />
* [[In-store Transactions]]<br />
* [[:Category:Shopping Cart Interfaces|Shopping Cart Interfaces]]<br />
* [[Converter|Bitcoin Javascript Converter]] displays a price in BTCs after converting from USDs.<br />
* [[How to accept Bitcoin, for small businesses]]<br />
* [[:Category:Marketing|Marketing]]<br />
* [[Promotional graphics]], buttons and logos<br />
<br />
[[Category:ECommerce]]</div>Mckoss