Get a phone with NFC.

Sure, we still use smart cards here as well.

But look on the horizon and what the credit card companies are doing. NFC is about to become standard in smart phones. Google is releasing google wallet. The next iPhone will most likely have NFC as well. The general trend is that people want to do more and more with their phone, and the payment processors have finally caught up on this trend. Sure, it will take a long time to phase out smart cards considering how integrated with society they have become. But the newer card readers are already NFC capable. Those who want to will be able to pay with their phone almost anywhere in the very near future. And that is the future that bitcoin should be aiming at.

Why should we divert resources into creating smart cards when the rest of the world are moving away from them?

Then 2 things are clear, no one has stolen your coins, and your coins aren't technically lost. As long as you keep your Bitcoin Labs wallet with the private key it should be possible to retrieve them.

However, there seem to be a bug in the App which causes your phone to show an incorrect balance. I don't know how solve this since I'm not familiar with the app. If the app has an option to re-scan or similar I would try that. Otherwise, if the app lets you backup your wallet I would make a backup and reinstall the app (don't uninstall the app without a backup though, since this will most likely remove the wallet with the coins as well). If this doesn't work I'm out of suggestions and you are probably better of to contact the developer of the app.

Search for your transaction here and see if the network has seen it.

http://blockchain.info/

My estimate is that the value of one individual spam mail is probably so incredibly low (since the vast majority of them are filtered and a majority of the rest are ignored) that the postage required is nowhere near the value of legitimate e-mails. The profit for spammers come from the huge amounts of mails they can send.

If the postage fee is calculated by the formula "spam profit/number of spam mails sent", then you have essentially made spamming unprofitable. I can't imagine that number is anywhere near an amount of money you actually need to care about, but maybe my estimates are completely of base. I don't really know the GDP or the revenues of the internet spam economy.

Why? 1 victim is better than 2 victims. Stolen rescources is better than stolen resources + spam.

And if it were my account or computer that was hacked I would prefer if the hacker only got away with a miniscule amount of bitcoins, rather than using my computer/account to spam others.

They are paying the alternative cost of the resources they control though. So if the value of keeping bitcoins is higher than paying "anti-spam postage" they will be inclined to keep the bitcoins, regardless of how they aquired them.

Even if they do get access to the bitcoins, why should they mail them to others rather than themself?

I think the goal here is not to get 100% security, but rather stop someone who just borrows your phone for 5 minutes to steal your money, or give you more time to empty your wallet from a back-up in case you drop your phone.

At first I was going to say that the bounty needs just to be higher than the cost of sending an e-mail with regards to electricity, bandwith etc. But this is obviously wrong since most spammers probably don't pay for this themselves.

So the bounty needs to be higher than the monetary value of one spam mail, so that spammers would rather keep their bitcoin than to send the mail. This is still very low, since the value of spam comes from bulk sending.

We would need a good method for nanopayments though, since spamming the network with this would be a bad idea. Maybe the probabilistic payment method would be good for this.

I proposed another way to achieve something similar to this. It requires a third party, but probably not a lot of trust and works with the current block chain. The idea is that one of the bigger pools could let people buy mining hashes that they can use for payments.

If payer wants to pay payee, then payee gives him an adress, payer has an account at the pool that he can reload, and instructs the pool to redirect some of its hashing power towards that adress. The pool can compensate the miners with money from the account. Payer then gives the hashes directly to the payee who can verify that they represent real proof of work the same way hashes are verified by pools.

Regarding TOR nodes and the like, this has the added benefit that you can't link the user to a bitcoin adress since all the payments will be newly created coins.

Switching to another coin would be disastrous pr wise since it would show that Bitcoin was essentially a failure. It would be really volatile, many would lose a lot of money and most people would probably suspect the  next coin will fail eventually as well. Switching the Bitcoin proof-of-work algorithm, would be much more feasible if ASICs ever poses a threat. Such a switch wouldn't even need 51% of the hashing power (but a large majority of user support), since the miners hashing power would be essentially worthless after the switch.

I like my thinking too, but it was a more of a question. I have no idea if the MMS protocol actually allows the transfer of any file type. I also don't know what other possible restrictions there are like file size limit etc, and my google skills won't give me a clear answer. But if MMS could possibly allow the transfer of .btc files it should certainly be taken into serious consideration when creating the standard. Transfering bitcoins P2P through phone messages would be too good of a feature to give up lightly.

I will do as soon as I've straightened out some of the question marks I still have.

The thing is, those who had acces to the container before you can take the value away from it. That is why you would need to redeem the coins i.e. "take them out of" the container and "put them in" your own wallet. I don't think there is any way around that. So this would only be secure to move bitcoins from one person to another, not between multiple persons.

A password protected container would be safe to show to anyone though, assuming the password is strong enough.

I think the cleverest way to bootstrap would be to pick a bitcoin block and then look at the bitcoin balances of that block and copy them to the new genesis block. Then every bitcoin user would become a newcoin user automatically and they would be inclined to at the very least install the new client, copy their private keys to it and sell their newcoins.

I just realized why this idea could have another very huge but subtle implication rather than just letting people browse anonymously. It would provide a very easy way to get your hands on bitcoins that could out-compete even mining.

Mining is currently the number one way to get bitcoins. The problem is that it requires specialized hardware, and thus shuts most people out. If it were somehow as easy to earn bitcoins with your bandwith as with your GPU, we could see a new craze even bigger than the last rally, with posts on all different forums telling you on how to set up a TOR/i2p node to earn bitcoins. Just think about all the people who currently use their spare bandwith for seeding torrents. That's a lot of people that would be inclined to take a closer look on bitcoin. The P2P community as well should embrace such a step even if it would compete with seeding, since it could make truly anonymous file sharing possible.

I believe something like this could be a very important step to lose the reliance on exchanges. Not many people know a bitcoin miner. Far more people know a pirate or can at least get in contact with a pirate fairly easy, and would thus have a way to get bitcoins in a decentralized manner.

Nice to see some positive feedback on this.
Yes, and I'll make sure to check out multibit.

I think where we differ is that you seem to talk mainly about the feature itself, while I'm more concerned about creating standard for the feature. Your way could become just as convenient but it would still not work well with other clients or online wallets unless everyone has a standard to follow.

Yes. This is exactly what I'm getting at. If I where technically competent enough I would have written a draft for such a specification myself already, but unfortunately I'm not. But this is absolutely the most important part in order to make sure we don't end up with 10 different standards for importing and exporting funds to your wallet. I'll do what I can though and pledge $50+ worth of BTC (10 BTC at todays rates) to whoever creates such a standard that becomes accepted by the community (assuming enough people actually see a need for this).

This seem reasonable. I don't know how much data a QR-code contains but I don't see a big need for much more than a private key, some voluntary additonal information like balance and return adress, maybe a checksum and a short private message. And surely this should fit in a QR-code, no? Obviously, others should jump into the discussion now if they see a need for bigger containers.

A thought, if you choose to encrypt a container, would it make more sense to only encrypt the private key or all of the data? I see arguments for both sides.

OffTopic question, but does anyone know if you can send any kind of file over MMS, or just multimedia? It would be another really neat use case for this.

Possible: https://en.bitcoin.it/wiki/Script#Transaction_with_a_message

Preferably the message should be encrypted using the recipients public key as well so it's not stored in clear text in the block chain. I don't know how that would work with more advanced transactions though, such as multisig transactions.

Sure, you could even achieve the same thing using the official bitcoin client, by copy-pasting wallets and creating one with the amount of bitcoins you want and sending that. The problem is that it's not very user-friendly and requires that the user actually has good understanding on what goes on "under the hood". Requiring users to create and send wallet files will also lead to many disastrous mistakes.

So I'm not really arguing for a way to send bitcoins through other means than a regular transaction, but rather a standardized user-friendly way to do it. The same way we have standardized QR-codes and standardized bitcoin-URLs it would be neat with a standardized file-type that "cointains" bitcoins and is recognized by any client that wants to implement it.

The arguments against using regular wallets:
1. It's unintuitive. If I send you regular cash through regular mail, I won't send it in a wallet. We should avoid confusion and let wallets be wallets.
2. Wallets are made to store bitcoins, not send them, and thus there is no standard protocol for them. Since wallets differ between different clients, you need to make sure the recipient uses the right client first.
3. It's not very user-friendly, and could possibly lead to mistakes by sending the wrong wallet etc.

The arguments against using strings of private keys as suggested in this thread:
1. Again, not user friendly. Preferably, a user should not even need to know what a private key is.
2. Exporting a private key means you need to make sure it holds the correct amount of bitcoins first. Creating a new key, sending the correct amount of bitcoins to it and then exporting it creates a lot of unnecessary steps, and possibility for mistakes.
3. Risk that you give away a private key that will recieve a transaction meant for you some time in the future. That won't happen with a standardized procedure.

Arguments for using a standardized new file type for this purpose instead.
1. Simple. It could even be a one step procedure, just enter an arbitrary bitcoin amount and click "create btc container". Everything else (creating a new private key, embedding it in the file and sending the bitcoins to the corresponding adress + any extra requirements/features for the container) could happen under the hood. To retrieve bitcoins from a container you simply open the file.
2. A file is familiar. Everyone already know how to manage, copy and share files to others. So the risk for mistakes since you don't know what you are doing is minimized. Required knowledge of cryptokeys and bitcoin wallets is zero.
3. There will be a clear distinction between wallets (which intuitively are supposed to be personal) and bitcoins meant for sharing with others.

Multibit seem to be a step in the right direction, sure. But the way I'm imagining it could be so much more user-friendly, intuitive and feature-rich. For example, by using nlocktime you could create containers that are automatically retrieved to sender if they are not redeemd before a specified time. A bitcoin client could also be created to recognize e-mail adresses in the adress field, and automatically create a container if you choose to send to a e-mail adress rather than a bitcoin adress. The most important part though, is that we have a standard between all clients, so that you don't need to worry about what client the recipient is using. The meaning of a *.btc file should be as obvious as a *.torrent file.

And as I've said, this could be huge for promotion. With a feature like this, any site with a public e-mail adress automatically accepts bitcoins in an easy and intuitive way.

I'll bump this thread because I still think it's a good idea and I think it could warrant some more discussion. More specifically I have been thinking about what features a standard bitcoin container should have. One of the more interesting ideas I had was to use nlocktime in order to make containers that are automatically retrieved to your wallet if noone redeems them before the specified time. That should be possible, no? It would be a pretty neat feature. I'd love to see more discussion on creative ways to send bitcoins to those who don't have an adress, and what could be possible with such transactions.

One of the main advantages of a system like this is for promotion, which should be in all of our interests. Every other day I see threads on how to make different sites accept bitcoins for donations. With this suggestion in place it wouldn't even matter. We could donate bitcoins to sites without even having an adress to send them to. E-mail 10 BTC to someone and tell him what it is and I'm sure he'll be more inclined to look it up.

See this thread for example:
https://bitcointalk.org/index.php?topic=74386.0

Spamming sites to get them to go through the work of setting up a bitcoin client before they even know how valuable it could be for them is the wrong approach. I'm sure they'll be far more interested in setting up a client to retrieve money they already have. It will also be a great show of the versatility that bitcoin provides.

I just posted some feature requests in the Bitcoin Spinner thread but since it applies to any mobile app I'll link to it here as well:
https://bitcointalk.org/index.php?topic=53353.msg820451#msg820451

But anyway, I really appreciate the work both of you are putting in to your clients. And I absolutely love the design and layout of your app. Mobile apps are the way to go to promote bitcoin.

The thing that is really holding me back from using your app though, is the need to download the block chain. This particularly holds me back from promoting your app to others since I want to show people the ease of use with bitcoin and the waiting period kind of puts people of. So I'm wondering what your future plans are regarding this and if I can look forward to a future light weigth client with your design and features.