Transaction

j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckM¹<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8836#msg8836">Quote from: satoshi on August 12, 2010, 02:46:56 AM</a></div><div class="quote"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8824#msg8824">Quote from: Red on August 12, 2010, 01:10:19 AM</a></div><div class="quote">I thought this too at first. But then I convinced myself otherwise.<br/></div>Are you back to talking about the existing Bitcoin system here?<br/></div><br/>Yes, I am talking about the hypothetical system.<br/><br/>The way I proposed the system, each time a block gets generated every validating node must accept or reject that block by validating the transactions and confirming the hashes in the block. In effect, the same work that is being done with the current system, plus the out-point hash checks. Since the other validators were already competing to generate the block, they already have (at least most of) the transactions.<br/><br/>As with the current system, if the transactions don't validate (plus match included out-point hashes) the other nodes will reject the block. If the block doesn't get acceptance by at least 50% of the CPU power, it doesn't make the block list.<br/><br/>So the presence of the hashes in the block list, signifies that at least 50% of the existing validators at that time saw and validated all the containing transactions and out-point hashes. <br/><br/>Therefore (barring hash crashes) if someone submits an antecedent transaction that matches an unspent out-point, it must be valid. <br/><br/>That antecedent's antecedent must have been valid as well, otherwise the antecedent would have been rejected. And so on and so on.<br/><br/>For that not to be the case, you have to postulate that there was a period in time where blocks weren't being validated against out-point hashes. But that's plausibly implausible with the CPU competition system. <br/><br/><br/><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=770.msg8836#msg8836">Quote from: satoshi on August 12, 2010, 02:46:56 AM</a></div><div class="quote">If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is:<br/>1) Show it the entire history back to the original generated coin.<br/>2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true.<br/></div><br/>If a client joined the network recently, it did so presuming that prior validators followed the rules and all pre-existing blocks are valid. (No one would join a known corrupt network)<br/><br/>Sure, in the current system, if transactions were never purged, a new node could validate all prior blocks for self consistency. But they still couldn't prove absolute truth. A bot net could have taken over and erased some transactions leaving "a new truth" and unhappy users. Equivalent to case 1) above.<br/><br/>In the current system, if transactions were Merkle tree purged then you have case 2) above. New comers must trust in the process. Anything missing, they don't need to worry about. Everyone must presume it was valid.<br/><br/>The unique thing I'm saying is that, if you have confidence in the bitcoin validation competition process (and we do!), then you really don't need "a 2) thoroughly deep block" to be very deep at all. Someone said in another thread that clients reject any changes to blocks more than two hours old. So we can have absolute confidence in all blocks buried 12 deep. <br/><br/>So if a transaction is unspent and buried 12 deep, we can purge all it's ancestors. They add warm fuzzies but no additional validation. We have to rely on them. There is simply no way to back up and change course.<br/><br/>After that, every succeeding block presumes all the preceding blocks are true. Otherwise it would be a fork and not a succeeding block. So for any transaction validated against out-points in a preceding block, if those out-points exist and are unspent, they must be presumed valid. If those are presumed valid, their ancestors must be presumed valid even if purged.<br/><br/>---<br/>In the proposed system, exactly the same things are true.<br/><br/>If an antecedent out-point hash is unspent and buried 12 blocks deep, then it is absolutely unspent. Nothing can change that fact. No point in checking its ancestors. You can finish validating the transaction, cancel the in-points hashes and create new out-point hashes.<br/><br/>Interestingly, if an antecedent out-point hash is unspent and buried LESS THAN 12 blocks deep, then it is RELATIVELY unspent. Curiously, there is still no point in checking its ancestors. The only thing that could change the antecedent's validity is a branch swap to a longer chain. If an ancestor of the antecedent you are validating this transaction against was swapped out, this transaction would be swapped out as well.<br/><br/>It's one of those cheesy time machine movie plots. Someone when back in time and spent my ancestor. Now I don't exist!<br/><br/>=====<br/><br/>So what I'm saying is that in BOTH systems (existing and proposed) the only thing validators need to do is to validate that the antecedent out-points exist and are unspent (for the current block chain). The process assures that everything else remains relatively or absolutely valid.<br/><br/>The rest is just warm fuzzies.<br/><br/>-- PS --<br/><br/>I know this is too long and redundant, but I'm to tired to edit. :-)<br/></div> text/html