Quote from: tonych on September 10, 2016, 09:43:06 AM

Wow, you made a good job of explaining the concept in a clearer way! Anyone who didn't understand the OP should jump here and read your post. Except for one correction: in the below paragraph, where you say "signature" you are actually referring to "hash" rather than a cryptographic signature.

Quote

So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner. It is just a block chain of "data". These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote". The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file. Is that the gist ? In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output. The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).

Well, then I missed something, exactly for the attack I previously mentioned, and your answer. If the "spend proof" is just a hash which everybody can calculate, then my earlier proposed attack is valid. Your mentioning of "it can only be send from the right owner", in this language, means a cryptographic *signature* (that's what "send" means here). Otherwise, if I pay you, I KNOW the transaction and hence the output that you are going to spend, and I CAN calculate the hash of that and post it on the block chain. If, however, this is not a hash, but a signature with *your private key* (corresponding to the address I'm sending it to), then I cannot post this signature as I know your address, but I don't know your private key.

I see it this way:

The private coin file consists of:
(signature of proof of burn of bitcoin with bitcoin private key that burned it ; transaction containing Joe's address ; transaction containing Jack's address signed with Joe's secret key ; transaction containing Alice's address, signed with Jack's secret key ; ... transaction containing MY address ; transaction containing YOUR address signed with MY key)

On the public block chain, there is the actual burning of the bitcoin ; .... there must be a spend proof SIGNED BY JOE of of the transaction to Joe so that Jack can verify the spending, but that ONLY JOE can produce. There must be the hash of the transaction from Jack to Joe.

But now, the spend proof by Jack must be signed with Jack's private key, or otherwise, JOE CAN POST THIS TOO. However, only Jack can SIGN it. Alice can verify it, because she has Jack's public key (his address) ; Joe can verify this too, but he doesn't care. But ONLY JACK MUST BE ABLE TO PRODUCE THE SPEND PROOF. As such, everybody that Jack would like to take with a double-spend can verify that it was spend (as all of them get the file, and get his public key, and can verify the signature on the block of the previous transaction Joe->Jack).

A hash is good enough for the new transaction, as this only needs to render the transaction that goes with the spending unique.
But a hash is not good enough for the spend proof, because otherwise, the previous owner can post it too (with a fake hash of a transaction, rendering the coin unspendable).

Quote

You can't redeem BBC back to bitcoin. "Unburning" would mean dumping the entire history of the coin to the public, which is clearly against its purpose. But you can exchange it.

The thing is, one could think of a cryptographic way to redeem the bitcoin, instead of burning it, style Lightning network, so that in the end, only one transaction needs to be broadcast, to the final owner. I don't know exactly how to do this, but it must be possible in some way.