j"1LAnZuoQdcKCkpDBKQMCgziGMoPC4VQUckMÞ<div class="post"><div class="quoteheader"><a href="https://bitcointalk.org/index.php?topic=723.msg7934#msg7934">Quote from: mkrogh on August 06, 2010, 07:17:43 PM</a></div><div class="quote">Red, very interesting. So, a set of transactions in bitcoin can actually be made local. But it must be possible to control where a transaction should be validated. <br/></div><br/>I think that you are getting lost in the choice of wording on this list. Every bitcoin client, whether or not it is 'generating' or not, has a very recent copy of the entire block chain, and can check any new transactions against that block chain to see if those bitcoins were owned by the *address* that the other client claims he owns, at least up until the last block update. I'm not saying local verification is implimented in the current client, but it's possible. But that doesn't protect you from a concurrent double spend. The distributed verification will add confidence in the validity of the transaction with each passing block, but it's not neccessary to perform a transfer. Cash in person has similar problems, as the vendor can never be *certain* that the customer isn't passing off counterfit currency. The risks of fraud are included in the costs of retail business, and if speed of transactions are paramount, the vendor can simply accept the results of his own client and take the risks that he might get burned. Waiting for confirmation would help protect against fraud, but it's not a *requirement* for completion of a trade. I would expect that smartphone clients would do this quick local verify by default, particularly when communicating with each other directly over ad-hoc wireless.<br/><br/>Also, the system doesn't even require that the receiving client be on the network at the time of the transfer. You can send money to any address at any time, and their client could find out about it long after the transfer had been verified by the bitcoin network.</div> text/html
https://whatsonchain.com/tx/c53bd3843f047a6c3beee1eefc72aa741bef2af638b4d2cb8a98d00ec5f3f50f