Thank you theymos for taking the time to criticize the scheme in some detail.
The simplified payment verification system is already in place. The Merkle root required for its functioning is included in all blocks. Blocks do not include the hash of a balance sheet.
After a new block is found the balance sheet is recalculated (possibly incrementally) and the hash of the balance sheet is encoded in a special transaction that serves to encode the data which is then broadcast round the network the same as a normal transaction. This is done by exploiting the broadband subchannel in ECDSA mentioned in another post of mine. There are some details to be fleshed out such as "who generates this balance sheet hash transaction" and "how do you cope with a malicious balance sheet client supplying incorrect data" but I believe there are multiple adequate ways of addressing these problems.
The size difference would not be significant. SPV is ~80 bytes per block plus 32 bytes per transaction, whereas balance sheets would be 20 bytes per unique address. Currently there are 132415 unique addresses in the system and 134267 transactions. SPV: 11.29 MB; balances: 2.65 MB. This is assuming that balance sheets will not have any header-like overhead, which they almost certainly will.
Thanks for supplying some real numbers. I'm afraid that "balance sheet" is not really an accurate description of what is stored. See
We'd probably have to change the name from "balance sheet" to "complete current credits list".
We need to store enough information about all the transactions which credit an address to allow appropriate references to those crediting transactions to be recorded in the transaction when you spend money from that address. It's like the stubbing-off-merkle-tree-branches idea in the white paper except that the stub hashes don't need to be stored and neither do the blocks. I doubt at the moment the "balance sheet" idea would save a significant amount of space but that's because Bitcoin is so thinly exchanged. As the fraction of spent transactions rises, the storage savings of the balance sheet method become more persuasive.
SPV looks through the Merkle tree to get the number of confirmations and prove that transactions and their prev_outs were not double-spent. This is the point of SPV. How would balance sheets solve this? If you're just going to download the most recent 5 blocks or whatever (an insecure method), why even have balance sheets? You can't generate with balance sheets, as you are unable to verify referenced signatures.
I'm not quite sure what you mean. I think this is the same objection that gavinandresen raised earlier in the thread in response to me misunderstanding exactly how transactions worked. After he put me right I changed the scheme. After reading my reply, if you're not satisfied, please explain the problem with my scheme in more detail.
Using balance sheets with the current system would require receiving and processing every transaction ever made, which will become difficult as the block chain grows. SPV requires no such processing, and the amount of data stored on disk is the amount received through the network.
Isn't it true that when you download the block chain you process it all in the current scheme? It seems to be that your criticism is more appropriately leveled at the current scheme because new "balance sheet"-using clients download the current credit list from other similar clients. The client then updates the balance sheet with all the incoming transactions to stay in sync. No processing of spent transactions ever takes place.
A balance sheet system written from scratch would not be any better than the current system. Generators need to know the contents of every non-spent transaction, so a parallel network similar to the current one would have to be kept. Clients would need to download every block header (as in the current system) because the current block with the balance hash can only be verified if you have every block in the chain.
I'm not sure what you mean by a "parallel network" or why it would be necessary. I believe it would use the current network, as a "balance sheet"-using client looks, to the network, (mostly) like the existing client. You can't however download the older portions of block chain from it as that's data it has "forgotten". You are right in thinking that the "balance sheet" scheme becomes unmoored from the root hash. You are correct in thinking that this is a problem which needs to be addressed and I believe that my scheme can offer roughly equivalent security guarantees to the current scheme but the details are complex.
Implementing "balance sheets" without altering the current protocol is rather complex and that makes it unattractive. However I believe that Bitcoin will have little choice but to either change the protocol or to move to a client implementation in which nobody remembers all the transactions, such as "balance sheets". There's nothing stopping a small group of people spamming the network with transactions possibly encoding the latest Lady Gaga video or child pornography etc. As a method of storing data on the internet for free it has the benefit of designed-in complete permanence, distributed reliability and plausible deniability. Before becoming bandwidth or CPU limited I believe that the block chain+transaction data could grow at about 30TB a year with the rate only increasing. This is going to exclude the vast majority of people from running full clients. Either Bitcoin would have to give up the p2p label or it's going to have to start forgetting old transactions. Of all the ways of doing the latter, "balance sheets" is the best.
ByteCoin
