j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMA<div class="post">As some might have noticed, one of the things that bugs me about bitcoin is that the entire history of transactions is completely public. I totally understand the benefits of how this simplifies things and makes it easy for everyone to prove coins are valid. <br/><br/>So this is not a suggestion for a change to bitcoin. Rather it is a question about what could be possible, and what couldn't be possible.<br/><br/>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? Specifically, *perhaps* it would be possible to store only hashes of the in-points, out-points in the block list. These would be time stamped (notarized) in the blocklist exactly as is being done now.<br/><br/>The major difference is that it would be the coin receiver's responsibility to store the full transaction. And perhaps he might have to store previous transactions (X) deep to show history.<br/><br/>Then when he wanted to transfer the coins to the next party, he would create a transaction exactly as is being done now, except he would have to submit the antecedents to the transaction for validation as well. For validation, each antecedent of the in-points would be hashed and validated as existing in the block list. The in-points would be hashed and identified in the blocklist as not yet spent. Then the transaction would be validated as is currently done.<br/><br/>If everything validated correctly, the additional in/out-point hashes would be added to the block. This closes the transaction's in-points, and marks the new out-point hashes as unspent.<br/><br/>Once a node completes the block (by winning the hashing contest), he then broadcasts the block of hashes and the related transactions+plus antecedents to the other nodes for confirmation and acceptance.<br/><br/>as a rough example:<br/><br/>{block-9<br/> hash-a, hash-b, hash-c, hash-x <br/>}<br/>{block-12<br/> hash-a, hash-y, hash-c, hash-d <br/>}<br/>{block-17<br/> hash-b, hash-d, hash-e, hash-z, hash-f <br/>}<br/><br/>{Transaction<br/> {in-points: hash-x, hash-y, hash-z}<br/> {address, signature and other transactions stuff}<br/> {out-points: hash-payed, hash-change<br/>}<br/> <br/>{generating-block<br/> hash-x, hash-y, hash-z, hash-payed, hash-change<br/>}<br/><br/>So basically, if the i/o-point hash existed twice in the block list, it has been spent. If it exists only once it has not been spent.<br/><br/>So in after block-17: <br/> a, b, c & d are spent. <br/> e, f, x, y, z are unspent.<br/><br/>The transaction spends x, y & z and creates hash-payed & hash-change, so the transaction is valid.<br/><br/>After the generating-block:<br/> a, b, c, d, x, y, & z are spent. <br/> e, f, payed, change are unspent.<br/><br/><br/>====<br/>The Goal: <br/><br/>The goal is to provide all the same security of the existing system, but to avoid creating a public graph of every transaction that is easily correlated. In this case, the hashes don't even have to associate in the block. The block could simply sort all hashes in ascending order.<br/><br/>In effect, I want to create real gold coins. I can give my coins to you, but everyone in the world doesn't know I did. You can give them to the next guy and prove they are pure gold coins, because you have the pedigree of the coins AND every generation in the pedigree was notarized in the public record.<br/><br/>====<br/>The Question:<br/><br/>Satoshi showed that you can remove transactions from the block list through the Merkle tree structure, without compromising security. I guess my real question is: <br/><br/>"What is the earliest you can remove the transactions?"<br/><br/>You could argue that nodes could remember everything anyway (the web never forgets). But if you structured the protocol so that new nodes would only receive a block list of hashes, they could only remember from this moment forward. That would give a little additional privacy. (Maybe)<br/><br/>====<br/>Any thoughts? Is there an obvious way that people could cheat and get rich?<br/><br/></div> text/html
https://whatsonchain.com/tx/e26f2e762a4afa80c2da6983d9c3445c8ee47420dfd8560c1673b7efcd9ea257