With "Balance sheets" most of the block chain can be forgotten.

[Quantumplation]

Red: It would still be a breaking change.  While it DOES provide versioning, clients only deal with others of the same version.  They don't automatically stop working or somehow learn to adapt to the new version when they see a client of another version.  Because of this, the old clients would continue on as usual, advancing the block chain.  The new clients, (0.4 for simplicity) would start rejecting the old (0.3.2).  Thus, you'd have a "0.4" blockchain, and a "0.3.2" blockchain that were exactly the same up until 0.4 was released, at which point they would diverge.  Transactions would only occur between clients of the same version, and when people finally switched over to 0.4, this new block wouldn't have the transactions from 0.3.2.  It can be done if absolutely necessary, and we'll just have to warn people that old transactions will be invalid, despite showing up as valid on the old clients.  Thus, we should avoid a breaking-change at all costs.

If, however, the sheet referenced the block chain instead, this information would be "extra", and thus safely ignored by older clients.  The block chain would still be valid when generated on older clients.

Another route to go would be to implement it this way, and then add it to the "todo list" for our first breaking change.  We then keep a list of things that would be breaking that we want to do until it gets sufficiently large/advantageous to risk the bifurcating block chain, and do it all in one version update.  This would still be a breaking change, but it would allow us to mitigate the negative effects.

[1713870986]

1713870986

[1713870986]

1713870986

[1713870986]

1713870986

[1713870986]

1713870986

[Red]

Uniquely identifying each bitcoin is a very good idea.

As I read the code, bitcoins are not serialized or in anyway uniquely identified. There are only transactions listing the value (number of) bitcoins involved.

Someone please correct me if I'm wrong about this.

However, I do see lots of uses for a system that could track serialized digital property. It's just not a feature of bitcoin.

[Quantumplation]

Red: Noone said it was.  I mentioned uniquely identifying them by the hash of the first block they were produced in (granted that would be "unique" to 50 of them, but some kind of seed, or offset, or whatever would also work) and someone said that in general, uniquely identifying them would be a good idea.

[Red]

Red: Noone said it was.  I mentioned uniquely identifying them by the hash of the first block they were produced in (granted that would be "unique" to 50 of them, but some kind of seed, or offset, or whatever would also work) and someone said that in general, uniquely identifying them would be a good idea.

Pardon me please. Just clarifying for my own benefit. Not trying to call anyone out.

I, and from what I've read from other nooks like me in the forum, initially assumed that because of the name, they system tracked coins as individual objects.

Counter intuitively, the system tracks transactions as primary objects, accounts (addresses) as secondary objects, and coins fungibly.

I see risks to privacy from tracking coins too closely. I'm trying to decide for myself whether or not there is too much risk already.

And thank you for clarification on the breaking change.

[Quantumplation]

^.^ Woops, sorry, was just trying to defend a fellow bitcoiner.  And sure thing on the clarification.  It's a huge issue faced by any distributed system like this, ESPECIALLY if you're dealing with money/something of value.

[ByteCoin]

I'd just like to clarify that "balance sheets" as I outlined them were not "lightweight things" designed to augment the existing system. In order to make balance sheets reliable, the balance sheet hash needs to be included in the block chain as explained. This is a breaking change, so there's no incentive to hold back from other beneficial breaking changes.

If I'm dishonest, what stops me from waiting a few months and then spending that first 50 again instead of spending that second 50?  Double-spending that first 50 will look like a perfectly valid transaction to any nodes using the balance sheet method who weren't around to see the first time I spent it.

You start off with 0BTC and one person sends you 50BTC. So there's a transaction in block x which they've signed and your public key is marked as the recipient.
Someone else sends you 50BTC.  So there's another transaction in let's say a different block y which they've signed and your public key is marked as the recipient.
Next you want to send 50BTC to someone else. Now with a bank there's no concept of where the money has come from, it loses all it's identity when it hits your bank account. Not so with BitCoin! A new transaction (apart from coin mining) has to refer to one or more transactions in the block chain which resulted in a credit to you. So when you talk about spending the first lot of 50BTC the new transaction would refer to block x and if you wanted to spend the second it would refer to block y. I presume the choice is made for you by the current software and the user does not have any input.

So to correct my balance sheet idea in one fashion, as well as the balance for each individual public key, the balance sheet would also have to keep enough information about the blocks which contain the transactions crediting the public key to enable references to those crediting transactions to be generated when spending the money. So instead of storing the public key and the balance, the balance sheet would have to store the public key, a list of crediting references and their corresponding credit amounts - the total credit being the balance. Anything more?

We'd probably have to change the name from "balance sheet" to "complete current credits list".

If we made a client that used the credits list method and we magically crammed the appropriate credits list hash into the block list somehow then the modified software would perform transactions which would reference credit transactions in blocks long since thrown away and the current software would be happy.

There doesn't seem to be much the point of storing references to the crediting transactions in the new transaction. It's easy to see that the money is there and it's not as though we can trace coins forever even if we wanted to. In the example above, if you'd made a transaction to yourself for 100BTC before spending 50BTC then the identity of the original coins is lost. If the requirement of referring to crediting transactions is lifted then the block chain would be considerably smaller, the super light weight balance sheet method is useable and the software's a little less complex.

ByteCoin

[ByteCoin]

I just had a bit of a brainwave as to how we could implement "balance sheets" as a non-breaking change.
Presumably when you generate a new address you have, if you want to exercise it, complete control over what the public key part looks like.

I take the hash of the previous block's balance sheet and split it into chunks. I make new public keys that contain these chunks of hash as parts of the public key values. I make a small transaction of 0.01BTC from a fixed address to each of these new hash-chunk-encoding public keys as soon as I have calculated the hash of the balance sheet. Each of these 0.01BTC accounts has about a month to "live" before I transfer the money back to the fixed address. If I did this earlier then in theory, the information could be at risk from the Merkle tree branch pruning.

Modified, clients using the balance sheet method would of course treat the transactions as valid just like all other valid transactions but they look out for all transactions signed by the fixed address as encoding balance sheet hashes. If, as well as storing the balance sheet hash, the transactions encoded an IP address of a "balance sheet server" then new clients would know where to go to get it.

As an aside, BitCoin is a great way to record arbitrary information permanently. One problem is that it thinks that the marginal value of thousands of people's disk space is zero.

That's a cool feature until it gets popular and somebody decides it would be fun to flood the payment network with millions of transactions to transfer the latest Lady Gaga video to all their friends...

ByteCoin

[Quantumplation]

I don't think that's how public keys work.  You can't arbitrarily choose a public key, it has to be generated in a very specific way, paired in a very specific way with a very carefully chosen private key.

[Red]

I like the balance sheet concept because it allows the network to forget most of the historical transactions. That suits me fine.

It is worth pointing out that the balance sheet associated with a given transaction block, will very likely be much larger than the transaction block itself. It is much smaller than the entire block history, but that is a one time transmission cost. A balance sheet would be recurring.

If you generated one balance sheet a day, or week, then wiped previous blocks that would suit me fine.

[ByteCoin]

I don't think that's how public keys work.  You can't arbitrarily choose a public key, it has to be generated in a very specific way, paired in a very specific way with a very carefully chosen private key.

Ok, I was again thinking of RSA. For this type of public key crypto it's true, you have relatively little control over the public key value. Of course if I generate a large number of public keys I could perhaps end up with about 16M =2^24 keys each with a different 3byte pattern encoded at a certain position. It would take a transaction with 11 receiving accounts to encode a 32byte hash of the balance sheet. 65536 different public keys would need 16 receiving accounts per transaction.

Of course, when you do a transaction you're just sending it to a public key. Nobody checks whether anybody has the private key so if you don't mind wasting 0.01BTC per block then you could encode two hashes in one transaction if you wanted as the public key takes 64 bytes. 50BTC would last you a bit over one month. The money would of course be completely lost. I believe you could encode arbitrary data into the block chain at a cost of 0.16BTC per 1024 bytes. Or about 312k for 50BTC. This data would live forever in servers round the world under the current scheme.

It is worth pointing out that the balance sheet associated with a given transaction block, will very likely be much larger than the transaction block itself. It is much smaller than the entire block history, but that is a one time transmission cost. A balance sheet would be recurring.

The benefit of the balance sheet is that you only have to receive it once when you need to sync back up if the size of the blocks you'd need to process to get back up to speed is larger than the balance sheet. Once you're up-to-date you keep the balance sheet updated in memory as the transactions go through and you just check that the hashes in the block chain agree with the hash of the balance sheet in memory.

So basically the balance sheet is never sent out unless you ask for it. Similarly at the moment the entire block chain is not sent out with every new block but it is sent out if you ask it to be when you start a new client.

ByteCoin

[Insti]

This "Balance Sheet" concept does not need to be separately implemented.
You can already forget as many transactions as you'd like.
It is covered in section 7 of the whitepaper pdf.

(And you actually only need to remember the 'TxOut' portion of any transaction.)

Either way you'll have to store about the same amount of data.

[Red]

Let me clarify...

I'd like it if EVERYBODY forgot the old transactions. It doesn't make much sense from an anonymity perspective for just some people to forget them.

And yes, I understand Merkle trees. It's a nice feature.

[Insti]

Let me clarify...
I'd like it if EVERYBODY forgot the old transactions. It doesn't make much sense from an anonymity perspective for just some people to forget them.

That is not going to happen though.

Your anonymity is not good if it relies on other people forgetting things.

[grondilu]

Mobile phone application won't have to be a full bitcoin client nor server.  It wouldn't make much sense.

It would be much simpler for mobile phones to use a service such as mybitcoin, or to connect via ssl to a Personnal Desktop.

I don't think the size of the block chain is an issue.  At all.  I don't care if it bothers some users.  Some people will always be unhappy about something.

Please don't touch the protocol.  It is fine as it is right now.

[ByteCoin]

Mobile phone application won't have to be a full bitcoin client nor server.  It wouldn't make much sense.

It would be much simpler for mobile phones to use a service such as mybitcoin, or to connect via ssl to a Personnal Desktop.

I don't think the size of the block chain is an issue.  At all.  I don't care if it bothers some users.  Some people will always be unhappy about something.

Thank you for rejuvenating an old thread! I'm glad you're taking an interest and you have strong opinions but there's no rationale in your post which would cause anyone to take them seriously.

Why would it not make sense for a mobile phone application to have essentially the same functionality as a full client? All the clients being the same simplifies interactions.

You seem to be making a distinction between a Bitcoin 'client' and a 'server'. What's the difference?

There are three resources which could possibly limit Bitcoin's performance: CPU, storage and bandwidth.
Let's say 1MByte per second of uncompressible incoming transaction data which needs to be recorded in the block chain.
This is a high but plausible bandwidth requirement. It might result in 10k per second ECDSA verifications which is again high but plausible in today's multi-core world. However the block chain would grow at a terabyte in under two weeks or over 30 terabytes a year which strikes me as implausibly large. This makes me think that the size of the block chain will be the first hard limit to be reached.

Do you still think it's not an issue?

ByteCoin

[theymos]

This is essentially already done. Bitcoin uses a hash tree structure for transactions that makes it possible for nodes to:
- Do everything except generation by downloading just the block headers and Merkle tree for each block, which is a tiny amount of data.
- Discard outputs that have been spent (referred to by a later transaction), even if you're a generator.

Neither of these are actually implemented yet, but the system of capable of doing it.

You could even generate while running in header-only mode (using getdata messages to get transactions you're missing), though the entire network could not do this.

[ByteCoin]

This is essentially already done.
...
Neither of these are actually implemented yet, but the system of capable of doing it.
...

Using the same definition, "Balance sheets" is essentially done as well! 

ByteCoin


PS

The current Bitcoin client has the undeniable advantage of existing.

Neither the lightweight whitepaper client nor a "balance sheet" based client exist but both are compatible with the current protocol.
They are therefore equal on that basis.

I contend that a "balance sheet" based client is superior in every other practical way to the lightweight whitepaper client or the current client. If it were implemented correctly, it would be superior to the current client. If a new Bitcoin-like protocol were correctly  designed and implemented with "balance sheet" and other improvements in mind then it would be superior to the current protocol.

[joe]

This is essentially already done.
...
Neither of these are actually implemented yet, but the system of capable of doing it.
...

Using the same definition, "Balance sheets" is essentially done as well! 

ByteCoin


PS

The current Bitcoin client has the undeniable advantage of existing.

Neither the lightweight whitepaper client nor a "balance sheet" based client exist but both are compatible with the current protocol.
They are therefore equal on that basis.

I contend that a "balance sheet" based client is superior in every other practical way to the lightweight whitepaper client or the current client. If it were implemented correctly, it would be superior to the current client. If a new Bitcoin-like protocol were correctly  designed and implemented with "balance sheet" and other improvements in mind then it would be superior to the current protocol.

The core bitcoin network should remain how it is. The core network should not be concerned with helping ordinary end users run lightweight clients. The core network should always remain as simple and lean as possible, staying within the theory laid out in the white paper, nothing more, except for fixing real bugs and security holes if they are discovered.

As was said in an earlier post, the balance sheet functionality can be layered on top of the existing core network. Clients in balance sheet mode can connect to each other on a second network to exchange information that relates blocks to the balance sheet. Older, ordinary clients will not need to know that this other network exists.

[ShadowOfHarbringer]

Idea sounds interesting, but I'd like to hear satoshi opinion on this very much.
Satoshi, where R you ?

[grondilu]

Idea sounds interesting, but I'd like to hear satoshi opinion on this very much.
Satoshi, where R you ?

Satoshi already addressed the issue of the size of the block chain in his white paper (http://www.bitcoin.org/bitcoin.pdf).  I'm pretty sure it will never be a real problem.