Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMG <div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8798#msg8798">Quote from: satoshi on August 11, 2010, 09:07:59 PM</a></div><div class="quote">Still thinking this idea through...<br/></div><br/>It's a bit of a brain twisting idea isn't it. :-)<br/><br/>It turns out the notion of a cancelable notarization generalizes nicely. <br/><br/>For example this system is not limited to bitcoin transactions. Since the signed contracts are kept externally, with additional validation/notarization rules, you could easily implement things like IOUs/claim checks. <br/><br/>If someone gave you $5, you could give him a $5 IOU. Its IOU hash would be notarized into the blocks list (of hashes). When you pay them back you could have them sign the IOU for confirmation. Then have the notary insert an IOU hash cancellation. Then no one could show back up with a copy of the IOU and demand double payment.<br/><br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8798#msg8798">Quote from: satoshi on August 11, 2010, 09:07:59 PM</a></div><div class="quote">I believe the clients would have to keep the entire history back to the original generated coins.&nbsp; The fact that clients have to keep the entire history reduces the privacy benefit.&nbsp; <br/></div><br/>I thought this too at first. But then I convinced myself otherwise.<br/><br/>It is really a matter of how much trust you place in the verifiers and the process of verification. People like the warm fuzzys that having every transaction available lets them trace the roots of their money back to its creation. However that is not required. <br/><br/>If you are confident in the process that validated the transactions during block creation (&gt; 50% CPU agreement). And if you are confident the previous blocks can't be changed (you proved this). Then you only need to check that related out-points have not been spent. The security features remain in the block list and procedure, even if the transactions themselves are stored externally and the predecessors are not stored at all. You showed this yourself by proving old transactions can be deleted using the Merkle tree to maintain consistency. <br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8798#msg8798">Quote from: satoshi on August 11, 2010, 09:07:59 PM</a></div><div class="quote">Someone handling a lot of money still gets to see a lot of transaction history.&nbsp; The way it retrospectively fans out, they might end up seeing a majority of the history.&nbsp; Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history.<br/></div><br/>True, privacy is directly related to observability. If there is a central party like a money changer, he can relate a lot of out-points. But if we get away from the notion that every coin must be traced back to creation, the observation horizons will be much closer. <br/><br/>----<br/>It's really weird getting used to the notion that this coin is valid simply because the process wouldn't let it be included otherwise. But really, that is exactly how bitcoin generation works. The transaction has no inputs, but everyone decides the out-point must be valid purely because otherwise, it wouldn't be in the block at all. :-)<br/><br/></div> text/html