Bitcoin Forum

There is an issue with bitcoins, which is that you always need to communicate with someone and recieve an adress before you are able to send them any bitcoins. This is opposed to regular cash where you can leave it somewhere (like under a door mat, or in someones mailbox or wherever depending on the sum and security needed) and have someone pick it up later. In the digital world this would be achieved if we had a standardized way to send someone bitcoins regardless of the way we communicate. We should be able to send bitcoins over e-mail, http, sms, or really any way we want as long as we have some way of sending a message, even if it's just one way communication.

I've seen some ideas to provide this for e-mail through third parties, but I really think such a fundamental service could and should be provided at a more basic level.

There is a way to do this right now though, by creating a new wallet that contains some bitcoins and send it to my friend, but it is really cumbersome at the moment, and intuitively there should be a difference between wallets and spare cash. My idea is to use a new file type, called a bitcoin container with the file ending *.btc. Technically it would be a small wallet with only one key-pair, but once it is opened by a client, the client simply sends the money to the user's wallet and informs the user "X btc added to your wallet."

An example of how neat this could become. Say I want to send my friend some cash, but doesnt have any bitcoin adress of his. Instead, I go into my android btc app that uses the android share api and I press share via e-mail. The android client then creates file.btc, it sends a chosen amount to the new adress, withdraws it from my balance in the app, and enters my e-mail application with the new file attached. So I e-mail my friend who recieves the money and simply opens the file to put it in his own wallet with.

Preferably, you should also be able to protect these containers with a password. That would also provide a fairly easy way to store parts of your own btc outside of the client in a secure manner. Simply create a btc container from the client and choose to save it on a usb drive. If you use an android app you could send it directly to drop box via the share api etc.

Thoughts?

Couldn't you just send a private key with an amount assigned via email? QED.

Instawallet!

Go to instawallet.org
Send coins to the address shown
Copy the link
Email to person
If they can't or don't take the funds they are not lost, you can get them back easily.

If there is a person you trust or want a 'petty cash' for joint venture it makes a great shared account too.

Exactly.  That is the easiest method.  Create a private key, transfer funds to it.  Now you have a portable digital and physical method of transfering it.  You can print it, encrypt it, email it, put it on a thumb drive, generate a QR code on your phone etc.

This is better in the sense of not needing a trusted party. But instawallet is the stone cold nuts in convenience. Key passing will probably only get easier though and ultimately be the best way. A URI type thing where your browser can 'see' a key in an email or whatever and do a one click collect would be sick. This kind of possibility is why bitcoin wins.

The question is wether or not the average non-technical user could. Everyone can send an e-mail. Everyone understands a file that is attached to an e-mail. Everyone understands the sentence "X Bitcoins added to your wallet" if they double-click the file. Not everyone understands public key cryptography, and they shouldn't need to either.

A standardized container with bitcoins would also provide a really intuitive way to store your bitcoins outside your wallet as I mentioned. You may only have an android client but doesn't want to keep all your bitcoins on it. Create a password-protected container, name it 100btc.btc and send it to drop box. Problem solved.

You need to generate a new address, send the coins there, send the private key to someone and delete your copy of private key. The other person needs to import the key and immediately send the funds to a new address in order to guarantee that they are not stolen. So I would say that, above all, we need a smart client integration that allows these features.

OP suggestion is interesting because it allows for more complex operations than just sending the private key. You can add a password or a personal message for example.

Doesn't my suggestion make exactly that possible. You would one-click the file rather than a link, but that's really the only difference, and my proposal create some other possibilities as well. It's also probably easier to make your browser recognize a new file type than a new URI standard, depending on your browser.

This could also be used on sites such as MT. Gox to allow one-click-withdrawals rather than typing in an adress, simply by having them linking to a file.

Sure, it's just not 1-click yet, it totally could be. Instawallet is pretty damn simple already.

I like the idea of .btc files.
As said already, you can encrypt the privkey inside that file as well as add comments, checksums, returnadress or the like.

Files mailed have a better chance to remail intact too. Its too easy to have long strings corrupted in mails, like by different character-encoding or linebreak or auto-smiley-replacement or incomplete marking prior to copy and paste.

Also, a .btc file "feels" more like something substantial, has more "weight" to it, in a haptic way. I think. At least I feel a lot more comfortable having my mom handling .btc files instead of "random" strings..

Now to combine the advantages of both ideas:
Make the .btc file plaintext! Have readable, optional fields in it: "key", "comment", "checksum", "backup" etc. the only absolutely necessary field would be "key". You can open the file in a texteditor and text the key over mobilephone, or print out the whole .btc file or whatnot.

And, as always, all this depends on integration. Alternate clients, official client, exchanges, emailclients. The proposal goes in a similar direction like offlie transactions, which didnt make it into the official client yet. Encryption made it into the official client already, though.

Ente

Another third-party method is @PayBitBack -- you send a tweet to your friend and the PayBitBack service creates an intermediary wallet the recipient later can access.
 - http://www.paybitback.com

But as far as a URI scheme to accommodate bitcoin transactions I believe that has already been described here: https://en.bitcoin.it/wiki/URI_Scheme
  The &send=[private key]  is the method for sending coins

I don't know if the key import capability being included in the Bitcoin.org client v0.6 will accommodate this yet though.

Interesting!

This is why a lot of people are suggesting a "sweep" function in the client for private keys (and hopefully mini-pks).

Then you could write it on a paper leave it under the door mat.  They find it, sweep it into their client/wallet and throw the paper away.  You can do this now with 3rd party tools but if you don't know what you are doing it can be risky.

I really like this idea.  It's a nice and open way to enable people to send bitcoins via email.  If you also used asymmetric encryption for the bitcoin private key, you would only need to store some protocol/address and their public key (for communications) for any given person.  You could send bitcoins via email or any of a number of other protocols (a p2p file transfer protocol would be an interesting option to add and build into wallet software…the p2p nature of the transfer would serve to conceal the sender and recipient).  The sender can also monitor whether sent coins have been claimed and even set a deadline for them to be claimed or else they're recovered back into the sender's wallet.  In terms of the bitcoin block chain, the privacy aspects are fully preserved for the recipient (the recipient's wallet can generate a brand new bitcoin address(s) to sweep the coins into or they can reuse old addresses as they see fit).

P.S. The transaction that funds the private key used in the transfer need not include any transaction fee…the recipient can choose to add a fee to the sweep transaction depending on how important and transaction is (miners would include both transactions in order to claim the fee on the sweep transaction).  Assuming a private file transfer method is used, this enables the recipient of the funds to control both the privacy and the cost of the transaction.

Good idea, but for now I use instawallet also. I loaded btc in IW's for xmas gifts and send the url to the lucky recipient ... boom done boom!

technically, this works, of course.
But that cant be all of it.. Trusting a single company/project/website, its availability, accessability, honesty and all. Went wrong too often already. Yes, I use Instawallet too. But the future *must* be p2p-exchange, OTC-exchange, mixing cascades, and, consequently, direct import/export of single keys to transfer bitcoins "offline".
Else, we could keep using bankaccounts, papermoney and paypal, not? :-P

Ente

Creating an incentive for people to click on files in emails or opening email attachemnts does not seem a good idea at all, it is just a way of helping phish by email and hack by email people sucker people into opening email attachments or clicking on links in emails.

The world probably needs less opening of email attachments and clicking on links in emails, not more.

-MarkM-

What about a text friendly format that can be copy and pasted?  Like:

Does that already exist as a private key?  The only thing "missing" is a good/easy and user friendly import or sweep option in the client.

The Bitcoin container should contain not only the private key but also the funding transaction output. This allows the receiving client to create a transaction that sends to its own wallet without scanning the entire block chain. Scanning the block chain is a long and painful task and is not going to be less painful going forward.

The problem is that can be faked and won't be discovered until the transaction is rejected by other nodes.  Either you scan the block chain locally or you send a potentially bogus transaction into the network and wait for a rejection from the first node who validates it against the block chain.  Either way the work is being done.

There is a big difference. Because you know the funding transaction output you don't have to scan all transactions that ever occurred to see which ones match the new key. This is like telling you where in the hay stack to look.

I wouldn't imagine it saves that much time. A fraction of a second maybe?  In either case you need complete copy of block chain w/ indexes built.

When did you last run bitcoind with -rescan?

agree, would be like encapsulating money coins and sending them over other type of channels, like tcp/ip stack does.

@Jan yesterday and it's painful  :'(  and you can't use bitcoin while it does that, db is locked

Why would you do that?  I mean honestly?  To accomplish what?  Do you think it is impossible to sweep coins from a private key without a rescan?

easily, after you fund the wallet the software waits for a confirm then enables you the option to "export to file". You have secured the funds and your client knows the exact height of the unspent output and writes that in the metadata of the exported wallet.

When importing, the client can look only at that block height and sweep the funds into a personal wallet without ever bothering to scan whole years of blockchain transactions. The best example would be the same "wallet.dat" file that bitcoin software has, where you have lots of extra info besides private keys.

Some people will like to save those encapsulated private keys and scan for other outputs, or other purposes altogether, but that is out of the scope of this thread.

I think you missed the point.  I was asking WHY one would need to rescan the entire blockchain.  That isn't necessary to sweep a private key.

yep, i missed it alright sorry, i have to much open threads in my head... closing some  ::)

If you want to sweep a private key with the satoshi client today you would use pywallet and -rescan.

To sweep a private key you need to determine which transaction outputs are sending to the address of the corresponding public key. This is not a cheap operation. You either have to have a complete index of addresses to transaction outputs (thats a big one) or scan each and every transaction in the block chain (heavy workload). I don't think the Satoshi client has such an index, as it has no use for it with the feature set it currently has, and I don't think that any client out there has it. We need a solution that is viable for many use cases. Adding the funding transaction output is really cheap. It is just a few  more bytes.

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.

wallet.dat = bitcoin container

could do with a rename though to something like wallet.btc

You can do what the OP proposed using MultiBit:

Sender:
1) Creates a wallet which initially will have a single private key.
2) Funds the wallet's receiving address with the BTC they want to transfer.
3) Creates a private key export file with the 'Tools | Export private keys' option.
    These are small files with the suffix 'key'.
    You can password protect them.
4) Sends the key file to the recipient (via email or whatever) and tells them the password.

Recipient:
1) Imports the private key file using 'Tools | Import private keys' and enters the password.
2) MultiBit then imports the key from the file and replays the blockchain to get the key's transactions.

There are screenshots and more details here:
Exporting private keys (http://multibit.org/help_exportingPrivateKeys.html)
Importing private keys (http://multibit.org/help_importingPrivateKeys.html)

PS For writers of other tools : the password protected key files can be read with the OpenSSL command (https://bitcointalk.org/index.php?topic=43616.msg783013#msg783013).

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.

Hi 2_Thumbs_Up,

All good ideas for a bitcoin container.

I think it is one of these things that is 'one step at a time'.

I accept that people should not have to know what a private key is.
If you have not tried MultiBit v0.3.1 try it out - you do not have to copy wallet files around or anything. All the steps for create wallet/ export keys/ import keys are in the GUI. For the recipient they just have to save the key file, go to a dialog and 'press some buttons'.

Edit: honestly I do the export/ import routine half a dozen times as part of my release check list (Win/Mac/Linux x encrypted/ unencrypted).

Further steps could be:
+ get the file suffix registered by the client so that a double click opens it.
+ the bitcoin URI spec is the closest we have to a standard at the moment for this but the private key (the send parameter) is not encrypted which I think it ought be.

I think we are thinking along pretty similar lines actually.

Thumbs up on all points! ;-)

Ente

I never really thought a "container" file was useful but I am starting to see the merit.

Moving funds between wallets can be done but:
1) It does take a lot of manual steps.
2) Every wallet is different.

Also from a "meta" point of view it helps to extend the wallet analogy.  The cointainer file is essentially cash.  It is used to move funds from one wallet to another wallet offline.  If you give $10 to a friend you don't give him your wallet, or make a new wallet you take $10 out of your wallet, hand it to him and he puts the $10 into his wallet.

The file extension (.btc) is a new point which hadn't been brought up yet and an interesting concept.  Making it to that a btc file can be used by any wallet would be ideal.

So you convinced me.  Having a standardized format to "export" and "import" funds would be useful.  I think the next step would be for someone to write up a format v0.0.1 spec and create an RFC.  That will give us a starting place to move towards implementation.  Likely you will want lots of input from various client developers.

One thing I would recommend is a max size requirement.  This would ensure all containers can be converted into QR codes which is easy to transfer using mobile wallets than files.

@DeathAndTaxes

I particularly like the typo in your post:

cointainer

:-)

I must have coins on the brain.

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.

MMS? I like your thinking!

I suggest you create a bounty thread for this? It shouldnt be too difficult to create a draft for someone knowledgeable. The idea itself will appeal to many. Maybe others add to the bounty too.
I hope this works out nicely!

Ente

As Death and Taxes says.

Great point, it would be similar to real cash if the value could be checked and if you can pass it along knowing that
noone else who had it before could take away the value from it.

I also like "cointainer".

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.