What about bitcoin containers?

[DeathAndTaxes]

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.

[Jan]

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.

[DeathAndTaxes]

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.

[Jan]

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?

[paraipan]

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.

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

[DeathAndTaxes]

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?

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?

[paraipan]

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?

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.

[DeathAndTaxes]

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?

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.

[paraipan]

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

[Jan]

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?

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?

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.

[2_Thumbs_Up]

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.

[payb.tc]

wallet.dat = bitcoin container

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

[jim618]

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
Importing private keys

PS For writers of other tools : the password protected key files can be read with the OpenSSL command.

[2_Thumbs_Up]

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
Importing private keys

PS For writers of other tools : the password protected key files can be read with the OpenSSL command.

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.

[jim618]

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.

[Ente]

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.

Thumbs up on all points! ;-)

Ente

[DeathAndTaxes]

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.

[jim618]

@DeathAndTaxes

I particularly like the typo in your post:

cointainer

:-)

[DeathAndTaxes]

@DeathAndTaxes

I particularly like the typo in your post:

cointainer

I must have coins on the brain.

[2_Thumbs_Up]

Nice to see some positive feedback on this.

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.

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.

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.

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).

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.

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.