Bitcoin Wiki - User contributions [en]

Help:FAQ

2011-04-10T18:38:40Z

Jhyslop: /* General - added question about lost bitcoins */

Here you will find answers to the most commonly asked questions.

== General ==
=== What are bitcoins? ===
Bitcoins are the unit of currency of the Bitcoin system. A commonly used shorthand for this is “BTC” to refer to a price or amount (eg: “100 BTC”)
A Bitcoin isn't actually a 'thing' you can point at. It is just a number associated with a [[Address|Bitcoin Address]]. See also an [[Introduction|easy intro]] to bitcoin.

=== How are new Bitcoins created? ===

[[File:total_bitcoins_over_time_graph.png|thumb|Number of bitcoins over time, assuming a perfect 10-minute interval.]]
New coins are generated by a network node each time it finds the solution to a certain mathematical problem (i.e. creates a new [[block]]), which is difficult to perform and can demonstrate a [[proof of work]]. The reward for solving a block is [[controlled inflation|automatically adjusted]] so that in the first 4 years of the Bitcoin network, 10,500,000 BTC will be created. The amount is halved each 4 years, so it will be 5,250,000 over years 4-8, 2,625,000 over years 8-12 and so on. Thus the total number of coins will approach 21,000,000 BTC over time.

In addition, built into the network is a system that attempts to allocate new coins in blocks about every 10 minutes, on average, somewhere on the network. As the number of people who attempt to generate these new coins changes, the difficulty of creating new coins changes. This happens in a manner that is agreed upon by the network as a whole, based upon the time taken to generate the previous 2016 blocks. The difficulty is therefore related to the average computing resources devoted to generate these new coins over the time it took to create these previous blocks. The likelihood of somebody "discovering" one of these blocks is based on the computer they are using compared to all of the computers also generating blocks on the network.

=== What's the current total amount of Bitcoins in existence? ===

[http://blockexplorer.com/q/totalbc Current count]

The number of blocks times the coin value of a block is the number of coins in existence. The coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on.

=== How divisible are Bitcoins? ===

Technically, a Bitcoin can be divided down to 8 decimals using existing data structures, so 0.00000001 BTC is the smallest amount currently possible. Discussions about and ideas for ways to provide for even smaller quantities of Bitcoins may be created in the future if the need for them ever arises. For convenience, the program currently accepts only 2 decimal places as quantities smaller than 0.01 BTC are considered of trivial value and are usually used only to attack the network.

=== How does the halving work when the number gets really small? ===

The reward will go from 0.00000001 BTC to 0. Then no more coins will likely be created.

The calculation is done as a right bitwise shift of a 64-bit signed integer, which means it is divided by 2 and rounded down. The integer is equal to the value in BTC * 100,000,000. This is how all Bitcoin balances/values are stored internally.

Keep in mind that using current rules this will take nearly 100 years before it becomes an issue and Bitcoins may change considerably before that happens.

=== How long will it take to generate all the coins? ===

The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC.

Even if the allowed precision is expanded from the current 8 decimals, the total BTC in circulation will always be slightly below 21 million (assuming everything else stays the same). For example, with 16 decimals of precision, the end total would be 20999999.999999999496 BTC.

=== If no more coins are going to be generated, will more blocks be created? ===

Absolutely! Even before the creation of coins ends, the use of [[transaction fee|transaction fees]] will likely make creating new blocks more valuable from the fees than the new coins being created. When coin generation ends, what will sustain the ability to use bitcoins will be these fees entirely. There will be blocks generated after block #6,929,999, assuming that people are still using Bitcoins at that time.

=== But if no more coins are generated, what happens when Bitcoins are lost? Won't that be a problem? ===

Not at all. Because of the law of supply and demand, when fewer Bitcoins are available the ones that are left will be in higher demand, and therefore will have a higher value. So when Bitcoins are lost, the the remaining Bitcoins will increase in value to compensate. As the value of Bitcoins increase, the number of Bitcoins required to purchase an item '''de'''creases. This is known as a [[Deflationary spiral|deflationary economic model]]. Eventually, if and when it gets to the point where the largest transaction is less that 1BTC, then it's a simple matter of shifting the decimal place to the right a few places, and the system continues.

==Economy==
=== Where does the value of Bitcoin stem from? What backs up Bitcoin? ===
Bitcoins have value because they are accepted as payment by many. See the [[Trade|list of Bitcoin-accepting sites]].

When we say that a currency is backed up by gold, we mean that there's a promise in place that you can exchange the currency for gold. In a sense, you could say that Bitcoin is "backed up" by the price tags of merchants – a price tag is a promise to exchange goods for a specified amount of currency.

It's a common misconception that Bitcoins gain their value from the cost of electricity required to generate them. Cost doesn't equal value – hiring 1,000 men to shovel a big hole in the ground may be costly, but not valuable. Also, even though scarcity is a critical requirement for a useful currency, it alone doesn't make anything valuable. For example, your fingerprints are scarce, but that doesn't mean they have any exchange value.

=== What if someone bought up all the existing Bitcoins? ===
What if somebody bought up all the gold in the world? Well, by attempting to buy it all, the buyer would just drive the prices up until he runs out of money.

=== Bitcoin's monetary policy causes a deflationary spiral ===
See the article [[Deflationary spiral]].

==Networking==
=== Do I need to configure my firewall to run bitcoin? ===

Bitcoin will connect to other nodes, usually on tcp port 8333. You will need to allow outgoing TCP connections to port 8333 if you want to allow your bitcoin client to connect to many nodes. Bitcoin will also try to connect to IRC (tcp port 6667) to meet other nodes to connect to.

If you want to restrict your firewall rules to a few ips and/or don't want to allow IRC connection, you can find stable nodes in the [[Fallback Nodes|fallback nodes list]]. If your provider blocks the common IRC ports, note that lfnet also listens on port 7777. Connecting to this alternate port currently requires either recompiling Bitcoin, or changing routing rules. For example, on Linux you can evade a port 6667 block by doing something like this:

echo 173.246.103.92 irc.lfnet.org >> /etc/hosts
iptables -t nat -A OUTPUT -p tcp --dest 173.246.103.92 --dport 6667 -j DNAT --to-destination :7777 -m comment --comment "bitcoind irc connection"

=== How does the peer finding mechanism work? ===
Bitcoin finds peers primarily by connecting to an IRC server (channel #bitcoin on irc.lfnet.org). If a connection to the IRC server cannot be established (like when connecting through TOR), an in-built node list will be used and the nodes will be queried for more node addresses.

==Help==
===I'd like to learn more. Where can I get help?===

* Read the [[Introduction|introduction to bitcoin]]
* See the videos, podcasts, and blog posts from the [[Press]]
* Read and post on the [[Bitcoin:Community_portal#Bitcoin_Community_Forums|forums]]
* Chat on one of the [[Bitcoin:Community_portal#IRC_Chat|Bitcoin IRC]] channels
* Listen to [http://omegataupodcast.net/2011/03/59-bitcoin-a-digital-decentralized-currency/ this podcast], which goes into the details of how bitcoin works

==See Also==

* [[Man page]]

[[zh-cn:FAQ]]
[[fr:FAQ]]
{{fromold|bitcoins}}

[[Category:Technical]]
[[Category:Vocabulary]]

Protocol rules

2011-03-17T01:02:32Z

Jhyslop: /* Removed redundant step (old step 9) */

'''Rules''' for [[:Category:Clients|clients]].

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.

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.

Mining (block generation) rules are not yet presented.

== Data structures ==

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.

Conceptually, the client has the following data structures:

=== Transactions ===

There are two collections of transactions:

;transaction pool
: an unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions

;orphan transactions
: transactions that can't go into the pool due to one or more missing input transactions

=== Blocks ===

There are 3 categories of blocks:

;blocks in the main branch
: the transactions in these blocks are considered at least tentatively confirmed

;blocks on side branches off the main branch
: these blocks have at least tentatively lost the race to be in the main branch

;orphan blocks
: these are blocks which don't link into the main branch, normally because of a missing predecessor or nth-level predecessor

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.

== [[Protocol_specification#tx|"tx"]] messages ==

These messages hold a single transaction.

# Check syntactic correctness
# Make sure neither in or out lists are empty
# Size in bytes < MAX_BLOCK_SIZE
# Each output value, as well as the total, must be in legal money range
# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)
# Check that nLockTime <= INT_MAX<ref>nLockTime must not exceed 32 bites, 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>
# 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>
# Reject if we already have matching tx in the pool, or in a block in the main branch
# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>This is the protection against double-spending</ref>
# 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.
# 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
# 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
# Verify crypto signatures for each input; reject if any are bad
# For each input, if the referenced output has already been spent by a transaction in the main branch, reject this transaction
# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
# Reject if the sum of input values < sum of output values
# 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
# 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>
# "Add to wallet if mine"
# Relay transaction to peers
# For each orphan transaction that uses this one as one of its inputs, run all these steps (including this one) recursively on that orphan

===Explanation of Some Rules===
Most rules are self-explanatory. This section explains why some of the less obvious rules are in place.
<references/>

== [[Protocol_specification#block|"block"]] messages ==

These messages hold a single block.

# Check syntactic correctness
# Reject if duplicate of block we have in any of the three categories
# Transaction list must be non-empty
# Block hash must satisfy claimed ''nBits'' proof of work
# Block timestamp must not be more than two hours in the future
# First transaction must be coinbase (i.e. only 1 input, with hash=0, n=-1), the rest must not be
# For each transaction, apply "tx" checks 2-4
# For the coinbase (first) transaction, scriptSig length must be 2-100
# Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS
# Verify Merkle hash
# 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
# Check that ''nBits'' value matches the difficulty rules
# Reject if timestamp is before prev block (for a complicated definition of "before")
# For certain old blocks (i.e. on initial block download) check that hash matches known values
# 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.
# For case 1, adding to main branch:
## For all but the coinbase transaction, apply the following:
### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.
### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.
### 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.
### Verify crypto signatures for each input; reject if any are bad
### For each input, if the referenced output has already been spent by a transaction in the main branch, reject
### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
### Reject if the sum of input values < sum of output values
## Reject if coinbase value > sum of block creation fee and transaction fees
## (If we have not rejected):
## For each transaction, "Add to wallet if mine"
## For each transaction in the block, delete any matching transaction from the transaction pool
## Relay block to our peers
## If we rejected, the block is not counted as part of the main branch
# For case 2, adding to a side branch, we don't do anything.
# For case 3, a side branch becoming the main branch:
## Find the ''fork'' block on the main branch which this side branch forks off of
## Redefine the main branch to only go up to this ''fork'' block
## For each block on the side branch, from the child of the ''fork'' block to the leaf, add to the main branch:
### Do "branch" checks 3-11
### For all but the coinbase transaction, apply the following:
#### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.
#### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.
#### 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.
#### Verify crypto signatures for each input; reject if any are bad
#### For each input, if the referenced output has already been spent by a transaction in the main branch, reject
#### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
#### Reject if the sum of input values < sum of output values
### Reject if coinbase value > sum of block creation fee and transaction fees
### (If we have not rejected):
### For each transaction, "Add to wallet if mine"
## If we reject at any point, leave the main branch as what it was originally, done with block
## For each block in the old main branch, from the leaf down to the child of the ''fork'' block:
### For each non-coinbase transaction in the block:
#### Apply "tx" checks 2-9, except in step 8, only look in the transaction pool for duplicates, not the main branch
#### Add to transaction pool if accepted, else go on to next transaction
## For each block in the new main branch, from the child of the ''fork'' node to the leaf:
### For each transaction in the block, delete any matching transaction from the transaction pool
## Relay block to our peers
# For each orphan block for which this block is its ''prev'', run all these steps (including this one) recursively on that orphan

== See Also ==

* [[Protocol specification]]

[[Category:Technical]][[Category:Developer]]

Protocol rules

2011-03-17T00:57:57Z

Jhyslop: /* Add explanation of why some rules exist */

'''Rules''' for [[:Category:Clients|clients]].

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.

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.

Mining (block generation) rules are not yet presented.

== Data structures ==

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.

Conceptually, the client has the following data structures:

=== Transactions ===

There are two collections of transactions:

;transaction pool
: an unordered collection of transactions that are not in blocks in the main chain, but for which we have input transactions

;orphan transactions
: transactions that can't go into the pool due to one or more missing input transactions

=== Blocks ===

There are 3 categories of blocks:

;blocks in the main branch
: the transactions in these blocks are considered at least tentatively confirmed

;blocks on side branches off the main branch
: these blocks have at least tentatively lost the race to be in the main branch

;orphan blocks
: these are blocks which don't link into the main branch, normally because of a missing predecessor or nth-level predecessor

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.

== [[Protocol_specification#tx|"tx"]] messages ==

These messages hold a single transaction.

# Check syntactic correctness
# Make sure neither in or out lists are empty
# Size in bytes < MAX_BLOCK_SIZE
# Each output value, as well as the total, must be in legal money range
# Make sure none of the inputs have hash=0, n=-1 (''coinbase'' transactions)
# Check that nLockTime <= INT_MAX<ref>nLockTime must not exceed 32 bites, 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>
# 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>
# Reject if we already have matching tx in the pool, or in a block in the main branch
# Reject if any other tx in the pool uses the same transaction output as one used by this tx.<ref>This is the protection against double-spending</ref>
# 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.
# 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
# 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
# Verify crypto signatures for each input; reject if any are bad
# For each input, if the referenced output has already been spent by a transaction in the main branch, reject this transaction
# Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
# Reject if the sum of input values < sum of output values
# 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
# 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>
# "Add to wallet if mine"
# Relay transaction to peers
# For each orphan transaction that uses this one as one of its inputs, run all these steps (including this one) recursively on that orphan

===Explanation of Some Rules===
Most rules are self-explanatory. This section explains why some of the less obvious rules are in place.
<references/>

== [[Protocol_specification#block|"block"]] messages ==

These messages hold a single block.

# Check syntactic correctness
# Reject if duplicate of block we have in any of the three categories
# Transaction list must be non-empty
# Block hash must satisfy claimed ''nBits'' proof of work
# Block timestamp must not be more than two hours in the future
# First transaction must be coinbase (i.e. only 1 input, with hash=0, n=-1), the rest must not be
# For each transaction, apply "tx" checks 2-4
# For the coinbase (first) transaction, scriptSig length must be 2-100
# For the other transactions, reject if any input has hash=0, n=-1
# Reject if sum of transaction sig opcounts > MAX_BLOCK_SIGOPS
# Verify Merkle hash
# 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
# Check that ''nBits'' value matches the difficulty rules
# Reject if timestamp is before prev block (for a complicated definition of "before")
# For certain old blocks (i.e. on initial block download) check that hash matches known values
# 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.
# For case 1, adding to main branch:
## For all but the coinbase transaction, apply the following:
### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.
### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.
### 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.
### Verify crypto signatures for each input; reject if any are bad
### For each input, if the referenced output has already been spent by a transaction in the main branch, reject
### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
### Reject if the sum of input values < sum of output values
## Reject if coinbase value > sum of block creation fee and transaction fees
## (If we have not rejected):
## For each transaction, "Add to wallet if mine"
## For each transaction in the block, delete any matching transaction from the transaction pool
## Relay block to our peers
## If we rejected, the block is not counted as part of the main branch
# For case 2, adding to a side branch, we don't do anything.
# For case 3, a side branch becoming the main branch:
## Find the ''fork'' block on the main branch which this side branch forks off of
## Redefine the main branch to only go up to this ''fork'' block
## For each block on the side branch, from the child of the ''fork'' block to the leaf, add to the main branch:
### Do "branch" checks 3-11
### For all but the coinbase transaction, apply the following:
#### For each input, look in the main branch to find the referenced output transaction. Reject if the output transaction is missing for any input.
#### For each input, if we are using the ''n''th output of the earlier transaction, but it has fewer than n+1 outputs, reject.
#### 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.
#### Verify crypto signatures for each input; reject if any are bad
#### For each input, if the referenced output has already been spent by a transaction in the main branch, reject
#### Using the referenced output transactions to get input values, check that each input value, as well as the sum, are in legal money range
#### Reject if the sum of input values < sum of output values
### Reject if coinbase value > sum of block creation fee and transaction fees
### (If we have not rejected):
### For each transaction, "Add to wallet if mine"
## If we reject at any point, leave the main branch as what it was originally, done with block
## For each block in the old main branch, from the leaf down to the child of the ''fork'' block:
### For each non-coinbase transaction in the block:
#### Apply "tx" checks 2-9, except in step 8, only look in the transaction pool for duplicates, not the main branch
#### Add to transaction pool if accepted, else go on to next transaction
## For each block in the new main branch, from the child of the ''fork'' node to the leaf:
### For each transaction in the block, delete any matching transaction from the transaction pool
## Relay block to our peers
# For each orphan block for which this block is its ''prev'', run all these steps (including this one) recursively on that orphan

== See Also ==

* [[Protocol specification]]

[[Category:Technical]][[Category:Developer]]

Talk:Privacy

2011-03-04T06:14:33Z

Jhyslop: Created page with "I have been looking at the algorithm Bitcoin uses to choose coins. The algorithm does not lend itself to obscuring the trail of coin transfers. In fact, I think it makes it easie..."

I have been looking at the algorithm Bitcoin uses to choose coins. The algorithm does not lend itself to obscuring the trail of coin transfers. In fact, I think it makes it easier for someone analyzing the transactions to figure out things.

Suppose, for example, there is a transaction with two coins in and two coins out (one for the payment, one for the change). The source code randomizes which output is the payment, and which is the change, but in most cases it is trivial to look at the transaction and figure it out. For example, suppose there's a transaction with two inputs, 50 coins and 20 coins; and two outputs, 65 coins and 5 coins. It's pretty clear that the payment is 65 coins, and the change - ''which goes back to the owner'' - is 5 coins. You have now linked two coin transactions to a single person (whether or not you can identify that person is another matter).

Or, suppose Bitcoin creates a transaction with several (or even many) coins on the input side. If an analyst links just one of those coins to you, that person now knows for certain that all the other coins in that transaction also belonged to you. So, for anonymity sake, the fewer the coins on the 'in' side, the better.

And, of course, if a transaction has one input and one output, it's a no-brainer to figure it out.

The program uses what I call a "best fit" algorithm - i.e. it chooses one or more coins that come as close as possible to the exact value requested, giving preference to selecting a single coin with the exact payment value. So you will likely find many transactions that have multiple coins coming in, and one or two transactions out - the payment, and a small amount of change, or with exactly one input and one output. In either case, it's pretty easy to figure out what's going on.

Fortunately, the default behaviour of the program is to choose a new key each time you receive a payment, so that's a plus at least.

I don't know if this is the correct place to make these suggestions, but I would suggest modifying the standard Bitcoin program as follows:

# Eliminate the transaction logging in the wallet. Your wallet should contain only the coins you haven't spent (after having been confirmed, of course).
# Accounting entries should never be linked to specific coins or addresses used to create that entry.
# Automatically "shuffle" the coins. By "shuffling" I mean generating transactions within your own wallet - take one or two coins, and pay them to a Bitcoin address - NOT an IP address - under your control. (Note that for this to work, transaction logging MUST be removed.) This helps strengthen the plausible deniability mentioned in the article: since the program automatically generates these transactions, if someone questions where a particular payment went to you can legitimately say you don't know. Transactions would created at random intervals (but ideally not more frequently than once every 10 minutes or so, to keep them on separate blocks), using coins selected at random, and the transaction would be chosen at random from the following list:
## Combine two coins into a single coin.
## split a single coin into two coins
## Rearrange two coins into two coins of different values, for example 5+2 in, 1+6 out. In order for this to be indistinguishable from an actual transaction, one output must be larger than the larger of the two inputs. In this example, the larger input is 5, so one output must be > 5. If not, then it will be obvious that this is a shuffling transaction. For example, if the outputs are 3+4, then you could obviously have paid with just the 5 BTC coin and there's no reason to include the 2BTC coin.
# Modify the coin selection routine to randomly choose one of the following algorithms:
## Select two coins, the value of each coin being greater than the value of the payment. For example, payment amount is 5. Choose 50+20 in, giving 65+5 out. In this case, the payment is 5 and the change is 65. Randomize which is the payment and which is the change.
## Select two coins, the value of each coin being smaller than the value of the payment. For example, payment amount is 65. Choose 50+20 in, 65+5 out. Randomize which is the payment and which is the change.
## Select two coins which equal exactly the payment amount (this matches the "combine two coins into a single coin" shuffle operation above).
## Select a single coin for payment, with a value much greater than the value of the payment (for some definition of "much greater"). About 2x the payment value is good, because then the payment and the change are about the same, and a snooper won't be able to tell which is which.
## Choose multiple coins such that the value of the payment is greater than the value of the smallest coin, but less than the value of the largest coin. For example, your payment is 7 BTC. Choose coins valued at 5, 8, and 10, giving a payment of 7 and change of 16.
## The existing "best fit" algorithm, modified so that it only selects a single coin with the exact value as a last resort.

Talk:Scalability

2011-03-03T23:51:07Z

Jhyslop: Created page with "There is one major point that the page overlooks: the limitation on block creation. Block creation is limited to an average of one block every ten minutes. Furthermore, block si..."

There is one major point that the page overlooks: the limitation on block
creation.

Block creation is limited to an average of one block every ten minutes.
Furthermore, block size (which includes the transactions in the block) is limited to 1,000,000 bytes.

Each transaction requires 10 bytes, plus approximately 106 bytes for every
input and approximately 69 bytes for every output. The exact size depends
on the size of the public key, which I have not been able to confirm, but
the keys in my wallet.dat seem to be about 65 bytes each.

If we assume that transactions average two inputs and two outputs, then
the average transaction size will be about 350 bytes ''(note that the main page assumes an average of 1KB per transaction)''. If we further assume
that the block size will, in practice, be limited to 500,000 bytes because
the transaction fees increase as the block size increases, then that means
there will be, on average, approximately 1430 transactions per block. That
works out to an average of 2.5 transactions per second - '''well''' below
the stated goal of at least 4,000 transactions per second.

Even if we assume only one input and one output per transaction, and that
each block will contain the full 1,000,000 bytes, that still works out to only 5,405
transactions per block, or 9 transactions per second.

Unfortunately, this is '''not''' a limitation that can be overcome by
simply increasing memory, or switching to a different ISP with more
bandwidth. It is a built-in limitation, designed to '''deliberately'''
slow down block creation. One solution is to somehow allow blocks to be freely created, while still keeping the rate of coin creation constant.

The bottom line is that, ''as it sits'', this system is not scalable.