Not a suggestion

[Red]

What are the desireable properties of a blinded public key which are not achievable by generating a new public key? I'm not clear on what were trying to do.

Both ways solve the problem equivalently. But if my understanding of the operation of blinded public keys is correct, it means the number of public keys each user would have to store in his wallet is minimized.

As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it.  If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it.

Obviously this could be achieved by them all having the same keys but that's presumably unsuitable for some reason. It looks like you're trying to hide some information while trying to make it still available for other people or under certain circumstances but I'm not sure what.

I'm not exactly sure of this particular use case, but it doesn't have any bearing on the proposed solution.

[1714811934]

1714811934

[1714811934]

1714811934

[1714811934]

1714811934

[1714811934]

1714811934

[ByteCoin]

Nope, this is a much different solution.

I quoted the following portion of your post

When you are done parsing the block list, you will have the minimal set of valid and unspent out-points.

That's exactly what a balance sheet is. As long as everyone agrees on this list then transactions work fine. Why store anything else? The block chain is merely a device for ensuring the integrity of this list. Why not just download and store the list, verify its hash in the block chain on startup along with a sufficient history of block chain to be confident it's not falsified?
This provides superior bandwidth, disk space and privacy to your scheme.

The general public doesn't get to see any transactions or balances.

The public has to see the transactions to verify them, the balances can be calculated from them. I'm neglecting your embryonic scheme involving not incompletely broadcasting transactions due to unresolved obvious security problems. 

If you want to provide more privacy you could always change transactions so that nobody can tell who the recipient is and how much until the recipient spends the money.

At the moment the beneficiary of a transaction is a certain bitcoin address. If that address has ever received coins before then everyone knows that all the money is in the same place. Alternatively, that address has been publicized as a receiving address so you know exactly where the money is going.

Instead you specify that the recipient of the money is the address that can decrypt a certain message that you have signed. So your transaction would comprise a load of signed TxIns and a signed public key encrypted message saying how much of the BitCoins goes to the person able to decrypt the message. All the network nodes try to decrypt the message with each of their public keys. The one who succeeds knows that they have received the money and updates their displayed balance accordingly. When the recipient decides to spend the money their transaction includes  the decrypted message. Only when the other network nodes see this do they know who the recipient was and how much the transaction was worth. Any change is ascribed to the signing key and the decrypted message and original are cited when the change is spent in subsequent transactions.

I wonder why transactions weren't designed like this in BitCoin from the start.

ByteCoin

[kiba]

I wonder why transactions weren't designed like this in BitCoin from the start.

ByteCoin

Satoshi is not all knowing and there were probably not anybody who working on cryptocurrency at the time. So there are less ideas for Satoshi to feed on.

[Red]

Again, this is not a suggestion for chaining bitcoin. That is in the title.

Rather it is a question about what could be possible, and what couldn't be possible. The general question is, could the block list be/have been implemented in a way that didn't store the full transactions in the list?

The answer could very well be, no.

But your saying, "The public has to see the transactions to verify them." Does not make that so.

When you are done parsing the block list, you will have the minimal set of valid and unspent out-points.

In this context it means a set of unspent out-point hashes. These hashes do not contain bitcoin quantity information.

I know what a balance sheet is. I was there for that discussion. I supported their possible utility.

This is different. The balance sheet was a way of rolling up known transactions that already exist in the block list. This is an exploration of never putting transactions into the block list at all.

It may still be a FAIL, but the question is not can you think of ways this might fail. It's can we prove that it must fail.

If you want to provide more privacy you could always...

Feel free to make your own suggestions in your own thread, but your suggestion didn't meet any of the stated goals of this exploration.

[ByteCoin]

This is different. The balance sheet was a way of rolling up known transactions that already exist in the block list. This is an exploration of never putting transactions into the block list at all.

The balance sheet idea is compatible with the current block list system. However as I mentioned, balance sheets enable you to throw the vast majority of the block list away. A minimal block list suitable for supporting balance sheets consists of blocks containing the balance sheet hash and a nonce. The nonce is changed until the total hash of the previous block's hash, the balance sheet hash and the nonce falls below a certain value. The transactions are ephemeral things which are passed around the network and serve to ensure that everyone updates their balance sheets identically. The transactions never need be recorded in the block list at all and, as I mentioned the block list purely becomes a method of assuring the integrity of the balance sheet.
Therefore, balance sheets is actually your idea when pursued to its logical conclusion as I implied in my first post on this thread. Balance sheets do everything you plausibly propose to do in this thread with a lower storage requirement and bandwidth useage. I believe that balance sheets and the above minimalist blocklist exhibit the lowest possible storage requirements for a Bitcoin-like system.

The question you asked at the start of the thread is

... could the block list be/have been implemented in a way that didn't store the full transactions in the list?

The answer is yes and in this post I've outlined exactly how little you need to store in the block list so long as a client can download a current(ish) balance sheet on start up and receive transaction broadcasts. Nearly full details about startup in the balance sheet thread.

ByteCoin

[Red]

Therefore, balance sheets is actually your idea when pursued to its logical conclusion as I implied in my first post on this thread. Balance sheets do everything you plausibly propose to do in this thread with a lower storage requirement and bandwidth useage. I believe that balance sheets and the above minimalist blocklist exhibit the lowest possible storage requirements for a Bitcoin-like system.

I pursued this line of reasoning in the thread, but it turns out it is a FAIL. It turns out that Satoshi was correct. You either need publicly validated transactions OR you need to save the entire transaction history so the receiver can validate a private transaction.

The reason eluded me at first, so it is not stated yet in the thread. In private transactions, if you send the money to yourself you will own both sides of the verification. As such, you can increase the values to be anything you want. Nobody else is watching. If you throw away the history no one will know. You can now pass on your inflated money to anyone. FAIL. Doh!

So the amount of validation required before you can purge the history is greater than a private transaction. It may not require a full public broadcast, but if it does we've added only minimal privacy. (see earlier in the thread)