Why a new token every time btc is divided?

[doobadoo]

I'm reading thru the satoshi white paper and i can't figure out a few technical points about how btc transfers value between addresses:

Lets say i start out with 25 mined coins sitting on a address.  That address represents the hash of the public key associated with the private key sitting in my wallet.  Now when i originate a tx to send 10 coins to a new receiving address i take the amount, and the receiving address and attach a signed message of those two and transmit that to a miner.  how can the miner verify that signed message if he can only see the hash of the public key?  Doesn't he need the whole public key, or is there some neat trick of cryptography going on here?

Also, if i send the next 15 coins to the same address later, the blockchain will retain the sig file for that tx as well.  right?


So, when a tx is sent from that receiving address for 20 btc to a yet another new address, both "tokens" are then presented in the next block with a new sig right?  I think they are called unspent outputs right? And 5 btc is then broken into yet another token as being sent back as change.  (to a new address?  or the sending address)

 I don't understand why the blockchain doesn't simply keep track of the unspent balances.  The input sig history should only need to be maintained until the blocks go deep enough that we are certain of the chain we are on (several days).  All the tx's  before these "recent blocks"  can just be referenced by a much smaller table of output address carrying the total balances of all the coins they received.  What's wrong with this?

Where does the need to have a complete history of all the sig files for all the fractional transactions comes from?  

I am approaching this from the perspective of asking, what is the point of all this "extra" information.  Why can't btc just track agreed upon balances on each address?

[kjj]

I'm reading thru the satoshi white paper and i can't figure out a few technical points about how btc transfers value between addresses:

Lets say i start out with 25 mined coins sitting on a address.  That address represents the hash of the public key associated with the private key sitting in my wallet.  Now when i originate a tx to send 10 coins to a new receiving address i take the amount, and the receiving address and attach a signed message of those two and transmit that to a miner.  how can the miner verify that signed message if he can only see the hash of the public key?  Doesn't he need the whole public key, or is there some neat trick of cryptography going on here?

Also, if i send the next 15 coins to the same address later, the blockchain will retain the sig file for that tx as well.  right?


So, when a tx is sent from that receiving address for 20 btc to a yet another new address, both "tokens" are then presented in the next block with a new sig right?  I think they are called unspent outputs right? And 5 btc is then broken into yet another token as being sent back as change.  (to a new address?  or the sending address)

 I don't understand why the blockchain doesn't simply keep track of the unspent balances.  The input sig history should only need to be maintained until the blocks go deep enough that we are certain of the chain we are on (several days).  All the tx's  before these "recent blocks"  can just be referenced by a much smaller table of output address carrying the total balances of all the coins they received.  What's wrong with this?

Where does the need to have a complete history of all the sig files for all the fractional transactions comes from?  

I am approaching this from the perspective of asking, what is the point of all this "extra" information.  Why can't btc just track agreed upon balances on each address?

I highlighted the part where you first go wrong.  There are no addresses, not really.

Bitcoin operates on transactions.  In step 1, you redeem the whole 25 BTC, not part of it.

As for the public key vs. hash part, it works like this.

You sign using your private key, and you include your public key with the signed transaction.  So long as we all believe in ECDSA, we can verify that the public key that you provided matches the private key that we understand you to control, despite having never seen it.  But why do we accept your public key as genuine?  Because we can hash the pubkey and check to make sure that the pubkey provided matches the address (really an encoded pubkey hash) provided.

[DannyHamilton]

I am approaching this from the perspective of asking, what is the point of all this "extra" information.  Why can't btc just track agreed upon balances on each address?

Bitcoin is designed in such a way that you can guarantee the validity of any transaction you receive without needing to trust what anyone else says about the history of the bitcoins being received.

I don't understand why the blockchain doesn't simply keep track of the unspent balances.  The input sig history should only need to be maintained until the blocks go deep enough that we are certain of the chain we are on (several days).  All the tx's  before these "recent blocks"  can just be referenced by a much smaller table of output address carrying the total balances of all the coins they received.  What's wrong with this?

If the blockchain only had recent totals associated with each address, then you would have to trust that the peer (or peers) that are providing you with your copy of the blockchain are not providing you an altered version that has different totals than the "real" blockchain.  You have no way of tracing the provenance yourself to ensure the validity of the balances.

Lets say i start out with 25 mined coins sitting on a address.  That address represents the hash of the public key associated with the private key sitting in my wallet.  Now when i originate a tx to send 10 coins to a new receiving address i take the amount, and the receiving address and attach a signed message of those two and transmit that to a miner.  how can the miner verify that signed message if he can only see the hash of the public key?  Doesn't he need the whole public key, or is there some neat trick of cryptography going on here?

Also, if i send the next 15 coins to the same address later, the blockchain will retain the sig file for that tx as well.  right?

So, when a tx is sent from that receiving address for 20 btc to a yet another new address, both "tokens" are then presented in the next block with a new sig right?  I think they are called unspent outputs right? And 5 btc is then broken into yet another token as being sent back as change.  (to a new address?  or the sending address)

Lets walk through your example:

A brand new block mined by a solo miner rewards 25 BTC to a single address (lets say address 1AAAaaa, which is a hash of the public key 123456789, which is derived from the private key ABCDEFG) with a transaction that has a transactionID of 2222222.

Address 1AAAaaa has one unspent output valued at 25 BTC.

You create a transaction (transactionID 3333333) sending 10 BTC to address 1BBBbbb.
Your wallet indicates that the input to this transaction is the output of transactionID 2222222.
Your wallet provides in the input the public key 123456789 to prove that the public key hashes to the address 1AAAaaa.
Your wallet provides a signature using private key 987654321 to prove that it has the authorization to spend the input.
Your wallet creates 2 outputs.
The first output indicates that 10 BTC should be assigned to address 1BBBbbb
The second output indicates that 15 BTC should be assigned to some other address
Depending on the wallet that you choose to use, this second output could be assigned back to 1AAAaaa, or it could be assigned to some other new address back in your wallet.

The address 1BBBbbb now has 1 unspent output valued at 10 BTC.
Some address in your wallet now has 1 unspent output valued at 15 BTC.
The 25 BTC output that had previously been associated with 1AAAaaa has now been spent.

Now you create a transaction (transactionID 4444444) sending 15 BTC to address 1BBBbbb.
Your wallet indicates that the input to this transaction is the second output of transactionID 3333333.
Your wallet provides in the input the public key of whatever address received the 15 BTC output in transaction 3333333.
Your wallet provides a signature using the private key of whatever address recevied the 15 BTC output in transaction 3333333.
Your wallet only creates 1 output (since the entire 15 BTC output is being sent, there is no need for "change")
The output indicates that the 15 BTC should be assigned to address 1BBBbbb

The address 1BBBbbb now has 2 unspent outputs.  One from transaction 3333333 for 10 BTC, and the other from transaction 4444444 for 15 BTC.
The 25 BTC output that had previously been associated with 1AAAaaa and the 15 BTC output that had been associated with some address in your wallet have now both been spent.

Now the owner of 1BBBbbb creates a transaction (transactionID 5555555) sending 20 BTC to address 1CCCccc.
Their wallet indicates that there are 2 inputs to this transaction.
The first input to this transaction is the first output of transaction 3333333
The second input to this transaction is the first (only) output of transaction 4444444.
Their wallet provides in each input the public key that hashes to address 1BBBbbb.
Their wallet provides 2 signatures (one in each input) using the private key that the 1BBBbbb address is derived from.
Their wallet creates 2 outputs.
The first output indicates that 20 BTC should be assigned to some other address (lets call it 1CCCccc).
The second output indicates that 5 BTC should be assigned back to some address in the wallet of the person that owns 1BBBbbb.  Depending on the wallet program that they use, this may be the same 1BBBbbb address or it may be some new address in that same wallet.

The address 1CCCccc now has one unspent output valued at 20 BTC.
Some address in the wallet owned by the person who owns 1BBBbbb has one unspent output valued at 5 BTC.
All other outputs have been spent at this time.

[doobadoo]

Thanks for your reply, makes some sense now.  

Now can you explain this tx to me:

http://blockexplorer.com/tx/f742aed8d29fbe102c48b0a6107acaf27e95244ca891150b367c0b6b2ac7f808

Clearly when having received coins many times to the same receiving address, when one sends all those coins to a new address, there is a need to reference all the pieces of coins that piled up into that address.  The blockchain repeats the exact same input address like 8 times to show where the whole balance came from in all its pieces.  And why sign each of the 8 inputs (see script sig column on right, same pubkey, dif sigs)

So, why does that sending address need to sound out where its balance came from and in each and every amount added?  Take a look at the first "previous output" who's hash begins 7fba.  That tx, which is the source of the 0.587....  btc was 50k blocks ago.  Why trace it back so deeply?  

Again, couldn't the block chain just keep a running tally of all the output addresses with unredeemed coins on them (unspent outputs, aka "balances").  And only retain the input addresses and amounts for a period of time till they were buried under a few hundred blocks?

Maybe i totally misunderstood all this.  But what i see is extraneous information.  The only need for these records is so that a person can import a wallet.dat on a new machine and d/l the whole block chain and then see all the tx's he sent and received from his addresses from day one.  But we don't need the blockchain to do our bookkeeping, why have all that data and where the coin balances or individual unspent outputs came from?  Doesn't his just inflate blocksize

[kjj]

Thanks for your reply, makes some sense now.  

Now can you explain this tx to me:

http://blockexplorer.com/tx/f742aed8d29fbe102c48b0a6107acaf27e95244ca891150b367c0b6b2ac7f808

Clearly when having received coins many times to the same receiving address, when one sends all those coins to a new address, there is a need to reference all the pieces of coins that piled up into that address.  The blockchain repeats the exact same input address like 8 times to show where the whole balance came from in all its pieces.  And why sign each of the 8 inputs (see script sig column on right, same pubkey, dif sigs)

So, why does that sending address need to sound out where its balance came from and in each and every amount added?  Take a look at the first "previous output" who's hash begins 7fba.  That tx, which is the source of the 0.587....  btc was 50k blocks ago.  Why trace it back so deeply?

Again, couldn't the block chain just keep a running tally of all the output addresses with unredeemed coins on them (unspent outputs, aka "balances").  And only retain the input addresses and amounts for a period of time till they were buried under a few hundred blocks?

Maybe i totally misunderstood all this.  But what i see is extraneous information.  The only need for these records is so that a person can import a wallet.dat on a new machine and d/l the whole block chain and then see all the tx's he sent and received from his addresses from day one.  But we don't need the blockchain to do our bookkeeping, why have all that data and where the coin balances or individual unspent outputs came from?  Doesn't his just inflate blocksize

Again, there are no addresses.  There are no balances.  We make those up so that we can think more easily.  At risk of repeating myself, I'll say again, in answer to all of your questions, bitcoin operates on transactions.

Also, if you think about the idea of passing around lists of keys, consider for a moment that there may be more keys than you care to track or pass around every 10 minutes.  How would you optimize that?  Would your optimized version look like a list of transactions?

[doobadoo]

gee danny that was a great explanation, i totally understand this.

Now hows about this.  To cut down on the size of the block chain couldn't a pruning technique that uses a "check point" hash be added to the headers (as i understand it, its just the headers that are included in the PoW hash).

The way this would work is that bitcoin would take all of the tx's that occurred from the beginning until under say T-minus 100 blocks. Where t=0 is the most recent solved block. It constructs a simple table listing all the receiving address and the balances each accumulated in total. It then takes a hash of just the unspent outputs of that table, then in block t=1 it includes that hash in a new parameter in the header.  Call this "UTXO Checkpoint hash."  That hash is repeated in each block header (and thus included in the PoW hash) until block t=99.  At that point, the current UTXO table (that contains only the unspent balances on each address) is re-hashed and t=100 includes this and the new UTXO Checkpoint hash.

The default client when installed by a newbie, will simply request the current UTXO and all the full tx's going back say 200 blocks.  Included are all the incremental Check Point hashes.  His client can now take the current UTXO as of t=0 block, work it backward 100 blocks, hash it, and see that the included check point hash is correct, work back another 100 and hash it again and see that it continues to match the other checkpoint hash.  

What has happened here?  Because this checkpoint hash has been included in the block header, the new client sees that the PoW in those 200 blocks was building upon a valid UTXO as of 200 blocks ago.  Now what if the whole construct is bogus?  The client can scoring how difficult it must have been to build this PoW hash chain, by looking at the apparent difficulty of the hash collisions, and selecting the chain with highest apparent difficulty (hash collisions with lowest probabilities).

Wouldn't it be monster hard to forge an entry in the UXTO 200 block ago if its check hash were included in the difficult PoW hash chain exercise?

[DannyHamilton]

Thanks for your reply, makes some sense now.  

Now can you explain this tx to me:

http://blockexplorer.com/tx/f742aed8d29fbe102c48b0a6107acaf27e95244ca891150b367c0b6b2ac7f808

Clearly when having received coins many times to the same receiving address, when one sends all those coins to a new address, there is a need to reference all the pieces of coins that piled up into that address.  The blockchain repeats the exact same input address like 8 times to show where the whole balance came from in all its pieces.
- snip -

No. It doesn't.  The blockchain doesn't have any such concept as an "input address".  This is something that the website you are looking at has done to attempt to provide useful information.  The actual transaction inputs in the blockchain will have (for each input) the transactionID and the offset to the appropriate output from that transactionID to indicate the output being spent.  It will also provide a signature for the input and the public key derived from the private key that will be used for the signature.

[DannyHamilton]

gee danny that was a great explanation, i totally understand this.

Now hows about this.  To cut down on the size of the block chain couldn't a pruning technique that uses a "check point" hash be added to the headers (as i understand it, its just the headers that are included in the PoW hash).

The way this would work is that bitcoin would take all of the tx's that occurred from the beginning until under say T-minus 100 blocks. Where t=0 is the most recent solved block. It constructs a simple table listing all the receiving address and the balances each accumulated in total. It then takes a hash of just the unspent outputs of that table, then in block t=1 it includes that hash in a new parameter in the header.  Call this "UTXO Checkpoint hash."  That hash is repeated in each block header (and thus included in the PoW hash) until block t=99.  At that point, the current UTXO table (that contains only the unspent balances on each address) is re-hashed and t=100 includes this and the new UTXO Checkpoint hash.

The default client when installed by a newbie, will simply request the current UTXO and all the full tx's going back say 200 blocks.  Included are all the incremental Check Point hashes.  His client can now take the current UTXO as of t=0 block, work it backward 100 blocks, hash it, and see that the included check point hash is correct, work back another 100 and hash it again and see that it continues to match the other checkpoint hash.  

What has happened here?  Because this checkpoint hash has been included in the block header, the new client sees that the PoW in those 200 blocks was building upon a valid UTXO as of 200 blocks ago.  Now what if the whole construct is bogus?  The client can scoring how difficult it must have been to build this PoW hash chain, by looking at the apparent difficulty of the hash collisions, and selecting the chain with highest apparent difficulty (hash collisions with lowest probabilities).

Wouldn't it be monster hard to forge an entry in the UXTO 200 block ago if its check hash were included in the difficult PoW hash chain exercise?

I don't have time to review your particular pruning technique at the moment, but there is definitely some consideration being given to pruning the blockchain.