That would be a much needed feature for computers that will serve as safe for important amounts and are not to be connected to the internet at anytime.
The blockchain could be updated from time to time using removable media and rescanned using existing functionality.
So the client would need to create a transaction, sign it, serialize it and output it. It would also be necessary that the client is able to deserialize a transaction and broadcast it.
Great idea - I was just thinking the same thing. This would be a very important feature allowing one to safeguard a high-value savings wallet.
just some more clarifying comments.
tx import/export is a useful feature, /in addition/ to address import/export. it allows one to keep 100% airgap on a savings wallet, by creating and exporting the transaction, then transferring just the tx data via usb key (or even a re-typing) over to an online computer.
it is not possible to do the same with key import/export. not least because you have to get a list of coins available by key, which the client doesn't really tell you. if you, e.g., need to send out 10 coins, you need to know which of your keys has that many coins, but not too much more than that, to export and bring that over to an online wallet. that, for one, is not easy to do with current client, and for two, you're (potentially) compromising your actual private key.
in contrast, with tx import/export, the only data that sees the broad internet, is just a signed transaction message, which is public info.
This will likely become a priority item.
+1
+2
@nanotube if i get you correctly, it's hardly possible for an offline client to just create a tx from thin air without knowing which outs it's allowed to pick-up since it's not always perfectly up to date with the blockchain ?
I don't really get how the key import/export could be potentially dangerous in itself ? Maybe we could have an option that exports only public keys/only private keys/both.
I guess the big picture of the general use cases for such a features needs a little more thought.
@davout: obviously, you'll have to periodically insert the latest blockchain snapshot, and run -rescan. once you do that, it is perfectly fine to create transactions.
danger of key import export: well, where are you exporting them /to/? obviously, to take them somewhere with an internet connection. thus opening them up to compromise which you were trying to protect against via the airgap. re: public/private: in order to create outgoing transactions, you need to export the private key (to sign the transaction). exporting public keys for this purpose is useless. so you would necessarily be exposing one of your private keys, if you were attempting to do this via key import/export, rather than transaction import/export.
To me, the use case are quite clear and unambiguous. :)
@nanotube take the example of bitcoin-central, one thing that would be great would be that the internet accessible client can generate addresses at will, only have knowledge of the pubkeys so it can track incoming transfers, and have an offline client which also has the private keys in order to be able to sign transactions.
This would require a two way interaction :
So at any time the public client has a pool of 10 to 100k public keys for which the private client knows the private keys, and whenever you want to sign transactions you feed some blocks to the private client, create a tx, and feed it to the public client for broadcast. Hopefully I'm clear and making sense :)
I think that would be an awesome level of security.
@davout: The idea of having a wallet with 'only public keys', and thereby being able to monitor your balance while keeping your private keys secure, is a great idea :) but it is a /separate/ idea (and i think it deserves its own github issue).
the ability to import/export transactions would be useful independent of this 'public wallet' functionality. the 'public wallet' functionality would also be useful (but somewhat less so) without the tx import/export functionality.
+1
+1
This is a great idea. +1
Er, hey. It's not desirable to have the blockchain on the airgapped wallet— god forbid someone figure out how to trigger a bug in its blockchain parsing. ... More importantly your airgapped wallet might be a dumb smart card.
Instead the normal client should maintain your balances, create the transaction... but when it goes to sign it it will find out it doesn't have the private key. So it creates a signing request, which you shuttle over to the secure wallet (somehow). The secure wallet asks you to approve the transactions— showing you the outputs and values (perhaps supporting batches), then signs them all, and you shuttle them back over to the main client for injection into the network.
Also— I described how to solve the running out of addresses problem here: http://forum.bitcoin.org/index.php?topic=19137.0 (the type-2 proposal)
@gmaxwell: ok, and once they figure out how to trigger a bug in blockchain parsing... what are they going to do? the wallet is airgapped! even if they manage to create a bunch of txns to try to spend the coins, they won't go out to the network. so with a wiping of the wallet and a restoration of a backup, all your coins are still gonna be there safe and sound.
but yes, as another complementary feature, running a public-keys-only mode has been suggested above. the tx import/export functionality, together with the public-keys-only wallet functionality, would bring us some good offline wallet capability. that said, tx import/export will be useful even without it.
Step 1. Trojan on user's computer. (duh, this is what we're fighting against so its a given). Step 2. Create corrupted block data for airgap computer sync. Step 3. Airgap computer compromised, copies private key data into the signature fields instead of signing. Step 4. User dutifully carries data back to the computer where the trojan then runs off with the keys.
Far out? A bit— but it's reduced to nothing not giving the airgap computer more non-trivial data than is required, which is just sound practice. The block chain is a complicated data-structure which has has triggered vulnerabilities before. I think of it this way: If someone did pull off this attack, would many people say (in retrospect) that it was obvious and your fault for not avoiding it? I think so. :)
Also, lfm pointed out to me that you need to know the input transactions too— otherwise you might be sending lots of money away in fees if your system was compromised. But they can simply be packed up with the data to be signed. The secure wallet only needs to parse them for their output values an verify their hashes.
@gmaxwell: aah, very nice - copying private keys into signature fields is nice and sneaky - and since a user cannot easily check by inspection whether it is a signature or private key data, since they both look like gibberish to the eye... bam, you're hosed. ok, i buy that.
re: needing to know txins: yea they just need to be included with the data.
still, getting tx import/export i think is a good first step. :)
Related:
BIP 10 describes a standard that guarantees interoperability of all programs that implement transactions that are broadcast:
raw TX RPC API covers this.
We are working on this concept https://www.tsstoken.com/ but its more suitable for the big investors.