Questions about bitcoin implementation

[joecascio]

As far as I can tell by reading Nakamoto's original paper and various other semi-technical materials, individual bitcoins are not identifiable by any kind of key or serial number. It seems that the blockchain merely records the amount of bitcoin in any one wallet. It doesn't really care "which" bitcoins they are, much the same as dollars in a checking account. In other words, the ledger just contains balances and records of transactions.

Is this correct, or did I miss something?

Thx,
Joe C

[Pieter Wuille]

Bitcoin internally does not use balances or wallets.

Each transaction explicitly refers to the previous transactions whose outputs it consumes. Think of it as coins: each unredeemed transaction output is a coin from the view of the system, and transactions consume coins, melt them together, and produce new coins from them.

On top of this, there is an authentication system: coins may be assigned to a particular address (or more generally, a script), whose owner is allowed to spend them. Consuming coins requires presenting proof of ownership of a private key associated with the address (which is a hash of the corresponding public key).

It is only client software that manages things like balances, which is just the sum of available coins to the private keys you have.

[casascius]

Coins ARE distinctly identifiable, except when the proceeds of more than one transaction are combined to make a larger amount.  This happens automatically any time you send a single transaction that is larger than any single received unspent transaction in your wallet (but less than or equal to your total wallet balance, of course).

When coins are combined, they lose distinction with respect to the individual prior transactions, but not with the group of those transactions as a whole.  If I combine 1BTC X + 3BTC Y to make 4BTC, then each of those 4BTC could be determined to consist of "25% of X and 75% of Y" but none of those individual 4 BTC will maintain any distinction beyond that.

[BkkCoins]

If you wan to explore this - look up an address on blockchain.info and click the "taint analysis" button. This shows you how "clean" your coins are. Not in the sense of theft/legality but in the sense of how much they are derived from other coins or not.

If find the reverse taint (sent) more interesting as it shows me how many addresses have received coins that were once in my address. And it's pretty astounding how quick they spread out.

Like, I've only sent a 3 payments from one address I have but it has already passed thru SatoshiDice 26 times (out of hundreds of addresses holding bits of my coins)

[niko]

Strictly speaking, there are no coins. There are only differential transactions recorded in the ledger. You can trace what previous transactions are involved in any given transaction, back to the "generation" of the block reward (again, a special kind of transaction). We are too used to physical representations of money, so we think of "bitcoins" - but this is really just inertia.

[joecascio]

Thanks for all the responses.

So, is it the case then that in order to determine what the balance of spendable coins is for any bitcoin address, you must run a total over all the transactions it was involved in?

[unclescrooge]

Thanks for all the responses.

So, is it the case then that in order to determine what the balance of spendable coins is for any bitcoin address, you must run a total over all the transactions it was involved in?

Exactely ²

[casascius]

Thanks for all the responses.

So, is it the case then that in order to determine what the balance of spendable coins is for any bitcoin address, you must run a total over all the transactions it was involved in?

Yes, though this isn't as difficult as it sounds: blockchain.info does this for you automatically.

One must remember that the balance available to a certain address isn't necessarily (and usually isn't) the balance available to any given person.  Bitcoin clients encourage users to have multiple addresses, and the Satoshi client sends change from transactions back to addresses that are invisible to the user but that the user nevertheless owns.

[joecascio]

Thanks for all the responses.

So, is it the case then that in order to determine what the balance of spendable coins is for any bitcoin address, you must run a total over all the transactions it was involved in?

Exactely ²

In Nakamoto's original paper, he suggested that the block chain can be pruned using Merkle trees, I think. But wouldn't that destroy the data necessary to reconstruct the balances of addresses?

[casascius]

In Nakamoto's original paper, he suggested that the block chain can be pruned using Merkle trees, I think. But wouldn't that destroy the data necessary to reconstruct the balances of addresses?

There's been other threads on the forums discussing this.

Yes, your estimation is correct.  The most current consensus (afaik) on what ought to be done to decrease the per-client burden is to have nodes construct and/or maintain a new Merkle(-like) tree of all of the unspent outputs, and put a hash commitment to the most current version of the tree in the block header.  As the scheme evolves, the requirement to provide a good hash commitment would transition from being a nice thing to do to being a requirement to get a block accepted.  Then, except for those desiring to help be historians on behalf of the whole network, the block chain history is abandoned (or just not collected by default) at some point in the past where it is deemed impossible that the block chain will ever legitimately be rolled back to (some sort of checkpoint).  Nodes need only the most recent blocks to validate a tree being presented to them as valid, the continuity of those recent blocks are validated just by the chain of 80-byte headers and the proof of work.

This tree scheme has been referred to in the forums as a "meta tree".

[joecascio]

Ok, I've done some reading here about transactions, inputs and outputs, but I'm still a bit confused and I'm pretty sure it has to do with what the client does vs what the servers do.

Right now my wallet has approx. 3.6 bitcoins in it, which are the summation of a lot of smaller payments in to different addresses, plus a few smaller ones out.

But now I need to send most of that 3.6 to a friend to pay a monthly bill for server capacity. So what I'm confused about is since the blockchain doesn't hold the balance per se of any of the addresses, how many different "inputs" need to be summed and linked to a new input to make the transaction legit?

Specifically, what's confusing me is that the inputs to a transaction were the outputs from another transaction, which means they're just differences not balances, so how does the system know someone's not spending over their balance?

Thanks for your help in advance!

[FreeMoney]

Ok, I've done some reading here about transactions, inputs and outputs, but I'm still a bit confused and I'm pretty sure it has to do with what the client does vs what the servers do.

Right now my wallet has approx. 3.6 bitcoins in it, which are the summation of a lot of smaller payments in to different addresses, plus a few smaller ones out.

But now I need to send most of that 3.6 to a friend to pay a monthly bill for server capacity. So what I'm confused about is since the blockchain doesn't hold the balance per se of any of the addresses, how many different "inputs" need to be summed and linked to a new input to make the transaction legit?

Specifically, what's confusing me is that the inputs to a transaction were the outputs from another transaction, which means they're just differences not balances, so how does the system know someone's not spending over their balance?

Thanks for your help in advance!

Everyone running the reference client (and some other clients) has a complete history of all spends (the blockchain). Miners also have it or have access to it and won't include your transaction if the addresses you use as inputs don't total as much or more than the output.

[kjj]

Ok, I've done some reading here about transactions, inputs and outputs, but I'm still a bit confused and I'm pretty sure it has to do with what the client does vs what the servers do.

Right now my wallet has approx. 3.6 bitcoins in it, which are the summation of a lot of smaller payments in to different addresses, plus a few smaller ones out.

But now I need to send most of that 3.6 to a friend to pay a monthly bill for server capacity. So what I'm confused about is since the blockchain doesn't hold the balance per se of any of the addresses, how many different "inputs" need to be summed and linked to a new input to make the transaction legit?

Specifically, what's confusing me is that the inputs to a transaction were the outputs from another transaction, which means they're just differences not balances, so how does the system know someone's not spending over their balance?

Thanks for your help in advance!

They aren't differences or balances like you are thinking.

When you spend, you totally redeem one or more inputs, and create one or more outputs.  The network checks to make sure that SUM(outputs)<=SUM(inputs) with the difference (if any) claimable by the miner that includes the transaction in a block as part of their generate transaction.  That's all.  Each output has a value, and the balance of your wallet is just the sum of all of the transaction outputs that you have keys that you could use to redeem.

[BkkCoins]

The network doesn't work with balances at all. It sees only transactions made up of X inputs and Y outputs. It accepts a transaction if the inputs are valid. The outputs become the new result of the transaction.

So let's say you have 3.6 btc made of of 3 outputs from previous trx and you want to pay 3 btc for your hosting.

The client will select enough outputs to cover the amount you want to pay and any extra will be fed back to one of your addresses as an output . It does not ever split or use partial outputs.

So,

Code:

A = 1.4 ---> 
B = 1.0 ---> outputs available become inputs to  --> trx ---> new outputs -->
C = 1.2 --->

   / Y1 = 3.0 to hosting address
--
   \ Y2 = 0.6 to your change address

Since outputs are never split up this is the sense in which they are coins - just coins of odd denominations.

The client doesn't have to re-verify each output you have to create your balance as it has already verified every block as it was received and the hash of the last block ensures that nothing was changed since it was received. If it received a block that did not build on the previous hash it would drop it (or figure out if the chain split and it needs to switch to the longer chain).

[joecascio]

Thanks to all the responders. I think I get this now. So the key realization for me is that several inputs to the same address never lose their identity in a balance sum.

It would be like a bank where you only put in cash and the deposit envelopes are never opened and the money all thrown in the same pile. Your bank statement would be just the series of deposits and withdrawals. When a withdrawal is made, you select enough of the (former) deposit envelopes to cover the payment and send them all, unopened to the payee. The payee accepts all the ones that can be accepted whole, and opens only the last one to make up the last bit, taking the remaining money, stuffing it a new deposit envelope and sending it to you as change.

Is that right? Seems at some point you have to break open an envelope and make a new one or you'd have a series of change request flying back and forth indefinitely.

[kjj]

Thanks to all the responders. I think I get this now. So the key realization for me is that several inputs to the same address never lose their identity in a balance sum.

It would be like a bank where you only put in cash and the deposit envelopes are never opened and the money all thrown in the same pile. Your bank statement would be just the series of deposits and withdrawals. When a withdrawal is made, you select enough of the (former) deposit envelopes to cover the payment and send them all, unopened to the payee. The payee accepts all the ones that can be accepted whole, and opens only the last one to make up the last bit, taking the remaining money, stuffing it a new deposit envelope and sending it to you as change.

Is that right? Seems at some point you have to break open an envelope and make a new one or you'd have a series of change request flying back and forth indefinitely.

Yeah, not bad.  But it isn't the payee opening the envelopes and making change, it is the payer.  And there is no bank, but the whole world is watching you open your envelopes and makes sure that you don't put more in your output envelopes than you took out of your input envelopes.