Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMÔ<div class="post">Satoshi: I know you know the first part of what I'm writing, but I want others to be able to follow and for you to correct any misconceptions I might have.<br/><br/>I was looking at the current Merkle tree implementation trying to figure out when transactions could be removed without losing security. <br/><br/>In transaction graph terms, the transactions represent the nodes. The edges of the transaction graph are represented by the in-points which point to previous transactions using a BlockHash-&gt;TransHash-&gt;OutPoint kind of structure. It is the existence of an in-point that marks a previous out-point spent. <br/><br/>So for a transaction to be valid, you most show for every in-point in a transaction that BOTH, a previous out-point exists AND no previous in-point exists that references that out-point. So for every out-point, there are zero or one in-points referring to it. zero = unspent. one = spent.<br/><br/>That also means that no transaction can be culled from the block list, until both its out-points are spent. Otherwise coins will disappear. <br/>You can however, delete all double-bound transactions as soon as you are confident the 2nd binding block will stick around. (earliest possibility)<br/><br/>However, as you delete transactions and replace them with their tree hashes, you lose the graph structure present in the block list. In effect, all transactions undeleted from the block list have unspent value purely because they still exist. They can no longer prove validity by ancestry since that part of the graph was culled.<br/><br/>Which got me thinking, is there a way to prove validity if you never put the whole transactions into the graph to begin with?<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8637#msg8637">Quote from: satoshi on August 11, 2010, 12:14:22 AM</a></div><div class="quote">The challenge is, how do you prove that no other spends exist? &nbsp;It seems a node must know about all transactions to be able to verify that. &nbsp;If it only knows the hash of the in/outpoints, it can't check the signatures to see if an outpoint has been spent before. &nbsp;Do you have any ideas on this?<br/></div><br/><br/>The key is to hash the transaction information as part of the out-point hash. So instead of creating a single transaction hash, you represent the transaction as two out-point hashes. (I originally considered an in-point/transaction/out-point structure using hashes, but that proved unnecessary.)<br/><br/>Only transaction validators need to know the bitcoin address associated with a recorded out-point hash. That comes from the submitted antecedent transaction for an in-point of the current transaction. The antecedent transaction and out-point is hashed and presumed BOTH valid and unspent if that hash appears one-and-only-one time in the block list.<br/><br/>The current transaction must be signed by the key for the address in the antecedent transactions of course. If this proves valid, two new out-point hashes are generated and inserted in the current block. The in-point hashes are marked spent by including them in the current block as well. (If a hash exists twice it is spent.) If you want to represent the transaction as a unit (and the currently visible transaction graph), the in-point hashes and out-point hashes could be grouped. However, this is not strictly necessary to prove validity.<br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8637#msg8637">Quote from: satoshi on August 11, 2010, 12:14:22 AM</a></div><div class="quote">We're trying to prove the absence of something, which seems to require knowing about all and checking that the something isn't included.<br/></div><br/>In this case we are trying to prove the presence of ONE matching hash and the absence of TWO matching hashes. It does require knowing all of them to prove.<br/><br/>I think the prohibitions against double spending are as strong as in the current version.<br/><br/><br/>==== CAUTION! ====<br/><br/>However, you have to consider the case where a node causes mischief by deliberate adding random "canceling hashes". In this case, the node wouldn't be able to gain access to the coins, as he has no signed transaction hashing to a valid unspent out-point hash. However, the current owner wouldn't be able to spend the coins either. The in-point would be presumed already spent.<br/><br/>That means the validation conditions are EXACTLY THE SAME as with the current implementation. All validating nodes must examine and validate all transactions represented in a block before accepting it and building on it.<br/><br/>If there exist any hashes in the proposed block that are not represented by valid transactions, the block must be rejected. <br/>That is exactly the same as the current system's, if any transaction doesn't validate, the block must be rejected.<br/><br/>I had hoped the condition to pass all transactions to all validators could be weakened but I can't see how (yet) without relying on trusted delegation.<br/><br/>----------<br/><br/>An interesting feature is that this simplifies the validation process. All that needs to be done is to parse the block list (of hashes) once. As each hash is parsed you simply look it up in a hash-set. If it doesn't exist you add it. If it does exist you delete it. When you are done parsing the block list, you will have the minimal set of valid and unspent out-points. You might even be able to keep the whole set in memory. (at least for a while!)<br/><br/><br/></div> text/html