"balance of accounts" block

[relative]

hi everyone,

I'm probably wrong and/or somebody already thought of this since I'm rather new here, but let me ask you a question:

downloading the blockchain already takes a while and is a couple of 100 MB.
why is there no "balance of accounts" block every X blocks?

let's say one in 10000 blocks has to be a large block that contains the balance of each address.
a balance block is confirmed by other nodes the same way transaction blocks are, so I don't see a way this can be cheated. clients only have to download all blocks since the last balance block instead of the entire block chain in order to be "fully operational". of course the client couldn't display the entire transaction history, but since blocks have a a date/time I don't see a problem here.
"Opening Balance as of xx/yy/zzzz (x Confirmations)".

what am I missing?

[1715379260]

1715379260

[1715379260]

1715379260

[1715379260]

1715379260

[JoelKatz]

How would you know the balance of transactions block was valid?

[casascius]

It's probably something that could and should be implemented into future clients.  This would probably be a necessary step to allow Merkle tree pruning of prior transactions.

[relative]

How would you know the balance of transaction blocks was valid?

it is confirmed by other nodes the same way transaction blocks are. aka a miner would have to generate 6 (or more) blocks in a row to insert his own balance block, which is highly unlikely.

[JoelKatz]

it is confirmed by other nodes the same way transaction blocks are. aka a miner would have to generate 6 (or more) blocks in a row to insert his how balance block, which is highly unlikely.

You start up your client. Someone hands you a balance of transactions block. How does the client know that block is valid? Currently, the client validates a block by checking its history all the way from the genesis block, which is hardcoded into the client.

The only way you can know that chain of blocks is actually part of the valid BitCoin hash chain is by tracing it all the way back to the genesis block. Say I start up my own BitCoin-like currency using the same protocol and client software. How do you know you're connected to the right client network?!

[relative]

it is confirmed by other nodes the same way transaction blocks are. aka a miner would have to generate 6 (or more) blocks in a row to insert his how balance block, which is highly unlikely.

You start up your client. Someone hands you a balance of transactions block. How does the client know that block is valid? Currently, the client validates a block by checking its history all the way from the genesis block, which is hardcoded into the client.

I see. but I don't think this is unsolveable.

a) I'm not entirely sure how this works, but if you can verify blocks back from block nr 5->4->3->2->1->genesis, it would be possible to verify 50000 -> 40000 -> 30000 -> 20000 -> 10000 -> genesis by adding another hash, wouldn't it? downloading 5 blocks vs. 50000.

b) if I'm missing something under a), the client could at least hardcode the hash of the latest "balance of accounts" block at the time the client was published.
that way, a new user doesn't have to download gigabytes of data on first use in the future but still have a confirmed balance.
the client has to be trusted anyway.


I've been downloading the block chain for 2 hours now  and I'm halfway through. I guess my network somehow throttles p2p.

[TierNolan]

They already thought of pruning.  

You ask the other clients to just send you the headers.  This is 80 bytes per block (so about 1MB).

block 1 -> block 2 -> ..... -> block 130000 -> block 130001 -> block 130002 -> block 130003 .....

You can verify the entire chain.  This gives you is proof that they are the chain and also the root hash for each block.

Next you would ask for the actual blocks themselves.  You can verify that they connect properly to the chain.

The current client downloads everything and verifies each block is correct and also that the chain links are correct.

The rule could be that if a balance block is more than 200 blocks in the past, it is considered definitive.

You would then just have to trace back to the last validated balance block.

Also, the balance blocks wouldn't necessarily need to contain all transactions, just ones that changed since the last balance block.

Their proposal is that you just drop transactions that are to far in the past and are no longer needed.

If there were transactions in blocks 1111 and 2222 of

1111: "send 1btc from A to B"
2222:  "send 1btc from B to C"

you could drop the 1111 transaction, since if 2222 was accepted that proves B had the 1btc to send.

[ByteCoin]

I think you'll find that this idea, taken to its logical conclusion is outlined in my post about balance sheets
See the disussion there.

ByteCoin

[zellfaze]

I like this idea and the balance sheets idea.  I think that people are over complicating them both a bit though.

If the balance block contained the following information, I think it would work fine (once we got past the problems with needing the majority of the network to accept the block).

-------------------------
Version
Previous hash
Previous balance block hash
Balances of all addresses with BTC in them.
Timestamp
"Bits"
Nonce
--------------------------


This way it isn't a huge change from the current method of creating blocks. It can still be easily verified by clients that are downloading the entire block chain, as it has the hash of the previous block it can be treated just like a normal block for verification purposes (I think, correct me if I am wrong);  New clients that are just connecting to the network can download and verify each of the balance blocks using the hash of the balance blocks that is stored in them.

As an extra measure of security a paranoid client could even verify the block chain from the second to most recent balance block to the current block.  If all of those blocks (1000-1999 blocks assuming one of these balance blocks is created every 1k blocks) it would be safe to assume that you are caught up to the network properly.

[kjj]

They already thought of pruning. 

You ask the other clients to just send you the headers.  This is 80 bytes per block (so about 1MB).

block 1 -> block 2 -> ..... -> block 130000 -> block 130001 -> block 130002 -> block 130003 .....

You can verify the entire chain.  This gives you is proof that they are the chain and also the root hash for each block.

Next you would ask for the actual blocks themselves.  You can verify that they connect properly to the chain.

You can actually stop here, and you don't need a balance block at all.  A lightweight client only needs to verify all of the headers, and then have a way to fetch full blocks as needed.  All that is really needed is a new message type in the network protocol that will allow a client to ask a node for all blocks that have transaction going to a given address.

[TierNolan]

You can actually stop here, and you don't need a balance block at all.  A lightweight client only needs to verify all of the headers, and then have a way to fetch full blocks as needed.  All that is really needed is a new message type in the network protocol that will allow a client to ask a node for all blocks that have transaction going to a given address.

The problem is a corrupted client could miss a double spend, right?

If there is a validated transaction which pays into a certain address then you can be sure that the address has at least that amount of money.

However, unless you have all blocks since, you can't be sure that it wasn't spent since then.

If lightweight clients only store new(ish) blocks, then it means that once your coin is old, you would have to refresh it anyway before you could send it to a light-weight client.

[relative]

You can actually stop here, and you don't need a balance block at all.  A lightweight client only needs to verify all of the headers, and then have a way to fetch full blocks as needed.  All that is really needed is a new message type in the network protocol that will allow a client to ask a node for all blocks that have transaction going to a given address.

how do you make sure that node doesnt leave out some transaction to misrepresent an  address' balance?

besides, I think with time you have to assume that most clients are lightweight, if lightweight means not downloading gigabytes of blocks, so the node itself doesnt necessarily have an answer.

[kjj]

You can actually stop here, and you don't need a balance block at all.  A lightweight client only needs to verify all of the headers, and then have a way to fetch full blocks as needed.  All that is really needed is a new message type in the network protocol that will allow a client to ask a node for all blocks that have transaction going to a given address.

how do you make sure that node doesnt leave out some transaction to misrepresent an  address' balance?

besides, I think with time you have to assume that most clients are lightweight, if lightweight means not downloading gigabytes of blocks, so the node itself doesnt necessarily have an answer.

You ask more than one.  Maybe even one that you pay for reliable information.

[relative]

if you have to trust the other node it is like a "bitcoin bank", or mybitcoin.com.

[kjj]

You have the option to run your own full node too.  Presumably it wouldn't try to deceive your own lightweight clients.

Oh, and if you keep track of your own spending, which would make sense, you don't have to worry about a node forgetting to tell you about it.  Plus, the client could check them all, either from time to time, or any time a new key is imported.  We could even attach a record to the key in the database indicating the current block number when the key was created, so that only blocks after that need to be checked.  Etc, etc.  The amount of work saved by having balance blocks is pretty low compared to the crapton of data that would necessarily need to be in them for them to be useful.

[casascius]

You have the option to run your own full node too.  Presumably it wouldn't try to deceive your own lightweight clients.

Oh, and if you keep track of your own spending, which would make sense, you don't have to worry about a node forgetting to tell you about it.  Plus, the client could check them all, either from time to time, or any time a new key is imported.  We could even attach a record to the key in the database indicating the current block number when the key was created, so that only blocks after that need to be checked.  Etc, etc.  The amount of work saved by having balance blocks is pretty low compared to the crapton of data that would necessarily need to be in them for them to be useful.

I disagree. The problem is that you have to trust that the transactions pruned by your connected full node are actually supposed to be discarded. If your full node omits a recent transaction that spends its own coins and then sends you a double spend on those coins, you have no way to know that was a double spend.  So you must trust the node to not prune transactions you need to know about. A balance block would solve that, at worst you would only need the 80 byte block headers leading to that balance block to know it was the correct one, all blocks before it could be completely pruned.

If trusting the node is mandatory, you may as well not bother downloading blocks at all. May as well just trust the node for everything, like a bank.

[kjj]

You have the option to run your own full node too.  Presumably it wouldn't try to deceive your own lightweight clients.

Oh, and if you keep track of your own spending, which would make sense, you don't have to worry about a node forgetting to tell you about it.  Plus, the client could check them all, either from time to time, or any time a new key is imported.  We could even attach a record to the key in the database indicating the current block number when the key was created, so that only blocks after that need to be checked.  Etc, etc.  The amount of work saved by having balance blocks is pretty low compared to the crapton of data that would necessarily need to be in them for them to be useful.

I disagree. The problem is that you have to trust that the transactions pruned by your connected full node are actually supposed to be discarded. If your full node omits a recent transaction that spends its own coins and then sends you a double spend on those coins, you have no way to know that was a double spend.  So you must trust the node to not prune transactions you need to know about. A balance block would solve that, at worst you would only need the 80 byte block headers leading to that balance block to know it was the correct one, all blocks before it could be completely pruned.

And now we are back to "You ask more than one, maybe even one you pay for the service".  If you ask two nodes at random, you have a pretty good chance of getting an honest answer from at least one of them.  To be extra careful, which is entirely reasonable if you are hoping to validate an incoming transaction, you could wait until after you get the transaction, then replace all of your connections with new random ones, and ask all of them.

Also, a balance block wouldn't help in this case at all, unless you want the lightweight client to consider every incoming transaction as unverified until the next balance block.

[TierNolan]

Also, a balance block wouldn't help in this case at all, unless you want the lightweight client to consider every incoming transaction as unverified until the next balance block.

It would still be useful for compressing the block chain for initial download.  Clients should definitely download the headers first and then back fill in all transactions.

Currently, it is around 300MB for 130k blocks.

You could have effective balance blocks by having the client periodically refresh any held coins.

If lightweight clients only download the latest <some size> MB of block data, then there is an incentive to have your coins near the front of the queue for download.  Otherwise, lightweight clients won't be able to verify them.

This could also act as an incentive for people to combine their coins and reduce "dust-spam".  If miners charge per kB to include the updating transactions, then the more value you can cram into a small space the better.

[Pieter Wuille]

You cannot, in general, assign balances to addresses. One transaction output can be usable by different private keys, or a combination of a certain number of keys, or by anyone at all.

If there is a transaction output with can be spent by address X and Y, this amount is shown by the clients of the owners of the private keys corresponding to both X and Y. As soon as one of them spends it, it is removed from both balances. This has very interesting - and unexplored - possibilities for escrows, but has a disadvantage that you really shouldn't think as bitcoin keeping balances for all accounts, it's not true and it's not possible. Bitcoin transactions directly refer to other transactions they consume, and that is fine.

[TierNolan]

You cannot, in general, assign balances to addresses. One transaction output can be usable by different private keys, or a combination of a certain number of keys, or by anyone at all.

Right, it would have been better to refer to them as transaction outputs rather than addresses.

Every transaction output is either spent or unclaimed.  There is no need to send transactions where all their outputs are spent to lightweight clients.

Transferring the transaction output to a newer transaction output effectively refreshes the output.