<p>Here is a basic sketch of how I understand the theoretical working of bitcoin of as explained in the whitepaper. Keep in mind, I have not looked closely at the implementations, so this is (1) a high-level sketch, and (2) might differ a bit from the implementation.</p>

<p>Everything in the bitcoin world is done in terms of things called 'blocks'. Blocks are basically long lists of transactions with specific coin. Coins are created at a constant rate in the network (by solving a proof-of-work problem) by creating an initial block. The creation of an initial block creates 50 units of bitcoin (this number decreases for newer and newer blocks for economic reasons and is included in the header of the block, but lets say it is always 50 for now). When the initial block of a coin is created, it basically says something like "this coin is created by account X" plus the proper crypto stuff for security.</p>

<p>After the initial block of a coin is created, account X has gained 50 units of bitcoin. It can now use these to pay other users. Paying amounts to adding a transaction saying something like "0.1337 bitcoins can be claimed by user Y" as part of a new block to this coin. The block is then distributed to the whole network, and they do a proof-of-work computation to verify it, and make it cannon. Thus, no actual stuff is transferred from user X to user Y, just a transactionis added to an appropriate block. User Y notices new coins they can claim.  The denomination transferred can be arbitrarily low (up to the limit of the precision of the datastructure used to represent value; float or double or whatever). Thus, to know how much money an account has, you have to look at every single unclaimed coin in the network, see which can be claimed by that account, and sum them.</p>

<p>For instance, if users Y wants to give user Z 2011 units of bitcoins, then they will usually need to use more than one coin (since in each coin, there is a max of 50 units of bitcoins available to Y, and probably her funds are distributed over many many coins). Thus, user Y would create a transaction that claims funds from many transactions to form a a transaction that transfers funds user Z. Only whole transaction outputs can be claimed, so the transaction may claim a bit more than the 2011 bitcoins user Y needs to give to user Z. So the transaction can have another output sending the 'change' back to user Y.</p>

<p>To validate a transaction, all the coins pulled into that transaction are verified all the way back to when they were first created as the 50 bitcoin award for mining a block. Oversimplifying slightly, every bitcoin ever mined must currently exist as one and only one claimable transaction output.</p>

CC BY-SA 3.0
2011-07-11T16:26:38.590Z
Thanks for the detailed answer! I agree with you that each node has to check the entire history, but I didn't understand why does the concept of "coin" that contains "bitcoins" help. Why isn't better to check for each user, that she doesn't spend more than she accumulated?
ihadanny
CC BY-SA 3.0
2011-07-10T08:47:24.873Z
2011-08-24T15:39:37.870Z
2011-08-24T15:39:37.870Z
Artem Kaznatcheev
<p>The correct answer was given to me here: <a href="http://forum.bitcoin.org/index.php?topic=27979.msg352498#msg352498" rel="nofollow">http://forum.bitcoin.org/index.php?topic=27979.msg352498#msg352498</a>.</p>

<p>The gist: The entire value of the output contributes to the subsequent transaction, so if you wish to transfer smaller amount, you must add an additional output on the second transaction to send the remainder back to yourself.</p>

<p>Note that the accounting is done for transactions outputs and inputs. The block concept is not necessary for the verification process and is only used for technical convenience.</p>

CC BY-SA 3.0
2011-07-13T11:17:24.813Z
2011-07-18T17:29:45.967Z
2011-07-18T17:29:45.967Z
ihadanny
<p>Note: much more basic than: <a href="https://cstheory.stackexchange.com/questions/7145/bitcoin-and-preventing-double-spending-in-decentralized-digital-currencies">Bitcoin and preventing double spending in decentralized digital currencies</a></p>

<p>I'm trying to understand the concern that bitcoin's chain of blocks technique tries to solve (see <a href="http://www.bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">http://www.bitcoin.org/bitcoin.pdf</a>). Warning: not a crypto-dude, be tolerant.</p>

<p>I understand that basically we're worried about "double spending". I'm able to grasp this idea when talking about discrete, indivisible coins. E.g. there are only 3 coins in the world, which cant be divided to cents, and we need to track the history of all 3, and to make sure that each payer really had the coin he claimed to have while paying with it.</p>

<p>While I'm able to see how this concept extends to millions of coins, I can't get how does it extend to fractions of coins. How does a "double spending" attack scenario actually looks like? how do the honest nodes scrutinize a nominated new block, after some node proposes it as the new head node? please provide me with some illustrative examples...</p>

<cr.crypto-security>
A basic question about bitcoin's anti double spending mechanism
ihadanny
# A basic question about bitcoin's anti double spending mechanism

(Asked by: username_0 on 2011-07-08)

Note: much more basic than: [Bitcoin and preventing double spending in decentralized digital currencies](https://cstheory.stackexchange.com/questions/7145/bitcoin-and-preventing-double-spending-in-decentralized-digital-currencies)

I'm trying to understand the concern that bitcoin's chain of blocks technique tries to solve (see <http://www.bitcoin.org/bitcoin.pdf>). Warning: not a crypto-dude, be tolerant.

I understand that basically we're worried about "double spending". I'm able to grasp this idea when talking about discrete, indivisible coins. E.g. there are only 3 coins in the world, which cant be divided to cents, and we need to track the history of all 3, and to make sure that each payer really had the coin he claimed to have while paying with it.

While I'm able to see how this concept extends to millions of coins, I can't get how does it extend to fractions of coins. How does a "double spending" attack scenario actually looks like? how do the honest nodes scrutinize a nominated new block, after some node proposes it as the new head node? please provide me with some illustrative examples...

**Tags:** cr.crypto-security


---

## 2 answers

### Answer by username_0 on 2011-07-13. Score: 7 | Accepted answer

The correct answer was given to me here: <http://forum.bitcoin.org/index.php?topic=27979.msg352498#msg352498>.

The gist: The entire value of the output contributes to the subsequent transaction, so if you wish to transfer smaller amount, you must add an additional output on the second transaction to send the remainder back to yourself.

Note that the accounting is done for transactions outputs and inputs. The block concept is not necessary for the verification process and is only used for technical convenience.


---

### Answer by username_1 on 2011-07-10. Score: 6

Here is a basic sketch of how I understand the theoretical working of bitcoin of as explained in the whitepaper. Keep in mind, I have not looked closely at the implementations, so this is (1) a high-level sketch, and (2) might differ a bit from the implementation.

Everything in the bitcoin world is done in terms of things called 'blocks'. Blocks are basically long lists of transactions with specific coin. Coins are created at a constant rate in the network (by solving a proof-of-work problem) by creating an initial block. The creation of an initial block creates 50 units of bitcoin (this number decreases for newer and newer blocks for economic reasons and is included in the header of the block, but lets say it is always 50 for now). When the initial block of a coin is created, it basically says something like "this coin is created by account X" plus the proper crypto stuff for security.

After the initial block of a coin is created, account X has gained 50 units of bitcoin. It can now use these to pay other users. Paying amounts to adding a transaction saying something like "0.1337 bitcoins can be claimed by user Y" as part of a new block to this coin. The block is then distributed to the whole network, and they do a proof-of-work computation to verify it, and make it cannon. Thus, no actual stuff is transferred from user X to user Y, just a transactionis added to an appropriate block. User Y notices new coins they can claim. The denomination transferred can be arbitrarily low (up to the limit of the precision of the datastructure used to represent value; float or double or whatever). Thus, to know how much money an account has, you have to look at every single unclaimed coin in the network, see which can be claimed by that account, and sum them.

For instance, if users Y wants to give user Z 2011 units of bitcoins, then they will usually need to use more than one coin (since in each coin, there is a max of 50 units of bitcoins available to Y, and probably her funds are distributed over many many coins). Thus, user Y would create a transaction that claims funds from many transactions to form a a transaction that transfers funds user Z. Only whole transaction outputs can be claimed, so the transaction may claim a bit more than the 2011 bitcoins user Y needs to give to user Z. So the transaction can have another output sending the 'change' back to user Y.

To validate a transaction, all the coins pulled into that transaction are verified all the way back to when they were first created as the 50 bitcoin award for mining a block. Oversimplifying slightly, every bitcoin ever mined must currently exist as one and only one claimable transaction output.

> **Comments:**
> **username_0**: Thanks for the detailed answer! I agree with you that each node has to check the entire history, but I didn't understand why does the concept of "coin" that contains "bitcoins" help. Why isn't better to check for each user, that she doesn't spend more than she accumulated?  

---

