Another way would be for a bank-like institution to print banknotes with only an address, in both machine and human readable form, onto a difficult to copy banknote.  That way, anyone who was to see it would be able to check the blockchain to make sure that said money is actually associated with that address.  However, the banknotes would have to return to the bank in order for anyone to claim the bitcoins, and the address used would have to be retired.  This allows the pubic to 'audit' the bank at will to make sure that there is full reserve related to the banknotes, and it's difficult for anyone to nab the bitcoins before you deposit them.

Another similar way would be to use the plastic rfid tokens that casinos use, each could have a face value, but report a checkable address when a rfid reader was available.  Once they return to the bank, the rfid tag could be rewritten with a new valid address and sent back out into the flow.

There is no way that I can see that easily copied paper money could work, particularly without a bank.

It's not required that the kid have a bluetooth phone, although he is likely to already have one.  It's not even required that *you* have one, although that might make the transfer more convientent.  All that is required is that you have an address of his.  He doesn't need to verify that your money is good; he knows where you live and he couldn't force you to pay him if you refused anyway.  He is dependent upon your honesty from the start, although if you screw him, not only are you going to have to cut your own grass, you might wake up one day and find someone has salted your flowers.

Yes, the Iphone app that allows two people who meet in person to exchange contact information.  It would be easy to include a bitcoin address field that could be accessed by the Iphone bitcoin client to permit one to send money to the other immediately.  This wouldn't work in the absence of service or a network outage, however, so it's not the ideal solution for direct IRL transactions.



I don't.  In fact, I don't think that the IP option should even be on by default.  I think that it would be a security risk.  Not only can a probe determine if a particular website/server/laptop-in-the-cafe has a bitcoin client running, and therefore a potentially profitable target for a cracker to break into; performing multiple requests on the same IP could give the attacker multiple addresses to the same person.  By themselves this seems unimportant since cranking the hash math backwards upon one hash begets an astronomical number of possible results.  But crypto can be undermined by comparing the reverse hash results of one to those of the other, significantly narrowing the possible set of public keys that could have begot it.  Not to say that this is a particularly easy computation to make, either; but a possible one.  Of course, even knowing the public key will not help an attacker to steal bitcoins from said person, but it would allow the attacker to search the blockchain and see all his transactions.  This would not only tell the attacker how much this person has, but could also be used to identify the owner by data mining the transactions.  At least that *could* be possible.  I don't know if this has been considered already, or even if this is a realistic concern.  But I do know that a laptop that responds to bitcoin specific ports or requests already says too much.  That alone could make choosing a target for a laptop thief an easy one.

Beyond the message feature, none that I can think of on the open Internet.  However, it would be useful for direct smartphone-client to smartphone-client trading over ad-hoc wireless.  It would need to be secured, however.

There might still be a better way for two people to do an in person transfer than use ip addresses.  Something similar to bump, perhaps.  An in person transfer would require some kind of two way communications, however, which is not currently required.  In order to allow the receiving client to verify the transaction against it's local copy before the actual transfer.

Yes, but I was pointing out that waiting for verification is not usually neccessary in common usage of the currency.  It's the unknowns that call for waiting for verification or the use of a trusted third party.
So most everyday transactions, either online or IRL, can be performed with faith instantly, or with the additional confidence of the local client verification almost instantly.  The 10 minute lag isn't really a detriment.

I see problems already.

First, there are no crypto-objects in your wallet that could actually be called coins.  You could, at best, print out a 2d scancode that represents the signed transfer chain, but you would still need an address first.  You would need some kind of bitcoin bank reserve willing to issue traditional banknotes or checks. 

There was another point here that I intended to make.

As with the example above, most cash transactions are not actually anonymous, but psuedo-anonymous.  For example, one party can be well established (the shopkeeper) while the other is mostly anonymous, (the bargain hunter in the above example) but even the buyer is not truely anonymous.  He has been in the shop many times before, and even if the shopkeeper doesn't know his name, he has seen his face enough times to recognize it.  So there is some trust that, since he is a local or regular customer, that he is not some pro trying to sting him with an opprotunistic scam.

Another example of a psuedo-anonymous transaction is the kind that both parties are anonymous to the world, but not to each other.  This is actually how *most* cash transactions work in the real world; but online it could go like this...

You want to get something, let's say, unusual.  You find this guy on, say, Tor with a hidden website selling your wanted commodity.  He is known to you only as, "pothead420" on the website.  You have no other way to contact him, and no means of finding out who is actually is.  You don't trust this guy, but someone is going to have to take a leap of faith, and that someone is likely going to be you.  So at first, you order small.  After a few succesful trades, your trust grows that "pothead420" is an honest dealer; so your orders grow larger.  He could screw you over at any time without recourse, but then he would be cutting off a regular customer, so he has an incentive to continue to treat you properly.


A third kind of pseudo-anonymous trust relationship could be found on this very forum that depends on reputation.  Most of us do not use our real names, but some of us do.  We assume that the member who uses the name of the bitcoin programmer is the actual programmer, and have some evidence to support this, but we cannot know for sure.  But, as far as this forum is concerned, he has a reputation.  So if you were to do direct business with him, and screw him, his word that you are not trustworthly would harm any business that you desired to conduct in the future, solely because he has a longer reputation than any newcomer.


All of these examples involve some kind of two party trust, but not one requires both parties trust a third.  Not even the verification of the blockchain.

There is more to it than just hoping.  For starters, you could already have an existing business relationship, and trust built between two parties due to honest prior trading. 





Counterfeiting bitcoins is really difficult as well, and that is what a local blockchain check would protect you against.  It would also protect you against a double spend that wasn't concurrent, as if one guy backs up his wallet file and then spends his coins the night before and attempts to yank your chain.  It does not protect you against a professional criminal, but against the petty attempt.


[/quote]
With bitcoin in the version I have seen (not red's), you cannot build a local machine that verifies it.
[/quote]


I know from other threads that Red has a different understanding than I about how the system works.  Either or both of us could be wrong.  My understanding is that, at present, the clients attempt to announce a transfer and then wait for the collective to confirm the transfer via accepting the claim as valid in at least two blocks, after which point the network believes that you have valid bitcoins, therefore you do.

However, two clients can interact directly, in theory.

Imagine this picture...

You have a full client on your Iphone running in the background, and then there is a power failure.  You head down to the corner store, and find that the shopkeeper has put everything in the cooler on sale half price, cash or bitcoins only.  Your cellphone client connects with the shopkeeper's cell phone client over ad-hoc bluetooth.  Signs the transfer accouncement (there are no actual cryptocoins in your wallet, they exist only as a series of entries into an encrypted ledger we call the blockchain, more like writing a check than actual coins) over to the shopkeeper's address.  Shopkeeper's client can then (but does not have to) check his copy of the blockchain to verify that you actually owned said bitcoins at the time of his last blockchain update.  If it's good locally, he can assume that you are not trying to cheat him and accept the trade and you leave with your half priced milk.  This does not protect the shopkeeper from an intentional double spend, but you still had to have honestly owned the coins at one time in order to do this.  If you did not own the coins at the time the power went out, his client would have rejected the transfer.

This also means that the shopkeeper can only spend bitcoins that he had at the time of the power failure himself, since any new bitcoins that he receives will not yet be included in the blockchains of any other vendor, and any attempts by his client to transfer his unannounced coins will be rejected by the other clients.  All transfers will either be verified or rejected by the network within 30 minutes of network reconnection.

That still requires prior intent, along with the expectation that you will be the one on your side of the break to make bitcoins.  And the risks involved to others is still dropping at a log, proceeding from very unlikely risk currently to astronomicly improbable over time.

I'm not saying that it's impossible, but neither is it impossible that the Mayans had it right and we only have two years left to live.  Personally, I don't think that it's a problem worth spending much time on.

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.

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.

Be careful not to confuse your ideologies.  Libertarianism and agorism are closely related, but they are not the same thing.  Generally speaking, agorists are libs who have dropped the 'live and let live' non-aggression principle in favor of an intentionally subversive market stragedy with the intent of 'starving the beast'.

I think that he already did.

An honest client can't really do that without spending the older coins first.  It doesn't *have* to spend the older coins first, but an honest client will not show any preferences towards spending the newest coins.  This would require a previously hacked client, or some rapid coding skills.

Go for it.  In the meantime, I think that you both miss some fundamental truths.

1)  The point of the system is not to 'mint' coins at a high energy cost, but a high computational cost, to protect the system no matter how high Moore's law may go. 

2)  The award of bitcoins is not 'minting' really anyway, it is an award by lottery for participating in the strenghtening the currency.  Those 50 bitcoins already existed from the moment that the rules were conceived and the process set into motion.  They are just distrubuted from the original owner in a systematic manner.

 The computations are a neccessary part of keeping the system strong and confidence high, and are a small price to pay when compared to the costs that we all incur from the administration of fiat currencies.  I think that it was a brilliant idea.

Also, a powerpoint presentation might be handy in the future.

An open offer, you say?  It's been a while since you had some pizza.  Feeling a craving, Laszlo?

What town would that be?

Also, there is a case of diminishing risks as the number of blocks grows and the number of nodes continues to grow.  Relative to the existing coins, new coins represent a smaller percentage of the monetary base with passing time.  Even though the risks of catching a bad coin created since a split increases with time as well, they are relatively remote, and tend towards zero over the next 120 years.  But the risks also tend toward zero at a log, not in a linear progression.

What I'm saying here is, by the time that bitcoins catch on, the risks of trading with bad coins during a network outage drop as the popularity of the bitcoin increases *and* also decrease simply as the blockchain grows over time.

Same for me.  100 if Satoshi blesses the final product as correct.

Either you are misunderstanding or I am, both are possible.

From the perspective of the vendor's client, it doesn't matter *why* the average block time has doubled, only that it has.  The watchdog daemon simply notifiys the vendor that a problem could exist.  It's an alarm, but the vendor still would have to determine if it's a problem for him or not.  I think that he could still make valid transactions, if he was willing to risk the possibility that he could be left with invalid coins when the grid come back up.  The real cash economy has similar risks, as no one can really know with any degree of certainty that the 20's in his cash drawer are not counterfit.  I'm pretty sure that only the coins created since the break are at risk, since coins owned by people on the other side of the split are still theirs, and cannot be (honestly) traded on both sides, but honest trades on either side should still be reflected in the block chain once the grid comes back up.  At least that is the way I inderstand the functions of the system.  I could still be wrong.