Help Wanted (for pay): Implement "offline account" capabilities

[chaord]

I am willing to pay someone to implement this feature in a timely fashion.  Please respond to this thread with any clarifying questions.  If you would like to be considered for the coding of this feature, please contact me directly at chaord.btc@gmail.com and include an estimate for a) how long to implement the feature b) desired compensation (in BTC or USD equivalent). 

In a nutshell, here is what I need:

On top of the new "accounts" feature I need the client modified such that:

• An account's private keys can be exported to a provided location (eg USB stick).  Private key would then be deleted from the "live" database.
• When trying to send coins from an account where the private keys are "missing", have the client return an error message until the necessary private key(s) have been "found" (eg by inserting the USB stick),

This effectively allows one to, on the same machine, split your wallet into "online" and "offline" accounts.  A remote attacker could only compromise your "online" accounts.  Even if the attacker had physical access to the machine, he'd still need physical access to the usb stick to compromise the "offline" accounts.

I know that similar features have been proposed previously.  However, I need this feature (or something that accomplishes the same goal) implemented asap.  If you think you are qualified to implement a feature like this, please contact me and give me a quote via email.  Of course, if you have questions, or don't mind the details of your quote being publicly known, by all means, reply to this thread.

Thanks!

[1714058425]

1714058425

[1714058425]

1714058425

[ribuck]

An account's private keys can be exported to a provided location (eg USB stick).  Private key would then be deleted from the "live" database.

I don't think this will be as straightforward as you may expect. Although an incoming payment (to a receiving address) can be linked to an account, from that point onwards the account balances have no connection to specific private keys.

Therefore the phrase "an account's private keys" doesn't have any meaning in the current implementation.

[davout]

Therefore the phrase "an account's private keys" doesn't have any meaning in the current implementation.

It does. See "getnewaccountaddress".

[ribuck]

Therefore the phrase "an account's private keys" doesn't have any meaning in the current implementation.

It does. See "getnewaccountaddress".

I presume you mean "getaccountaddress". That call returns a receiving address (public key). Any bitcoins that are paid to that address get recorded against the corresponding account.

But when you make a payment from some account, the bitcoin client doesn't care which coins it spends. If you make a payment from account "B", it might spend coins that were received against a receiving address associated with account "A".

The bitcoin client adjusts the account balances correctly, but doesn't associate the balances with the private keys that correspond to the original receiving addresses.

[davout]

I presume you mean "getaccountaddress". That call returns a receiving address (public key). Any bitcoins that are paid to that address get recorded against the corresponding account.

True

But when you make a payment from some account, the bitcoin client doesn't care which coins it spends. If you make a payment from account "B", it might spend coins that were received against a receiving address associated with account "A".

True, however, this just means that the output selection algorithm should be restricted to some outs instead of all available outs when sending coins from an account.

So, there *is* such a thing as an account private key, it's just that the client does not take these in account when spending coins from an account.

[chaord]

ribuck & davout -

Thanks for your helpful replies.  Just so I can properly understand what is entailed, you're essentially saying that it *is* possible, but may require some considerable tweaking?  Ideally if each account created and pulled from it's own pool of addresses when sending/receiving.  One could then simply export all of the private keys for a particular account. 

This does introduce a potentially manual process, if Account A does not have enough funds to send from, but Account B does, the user manually must transfer funds (eg official bitcoin transaction, not internal) from one account to another.  However, this is precisely what I am after.  I want to make sure that transferring funds between accounts requires that the private keys be present (or inserted if not present).

Not only do I think this is a very helpful feature from a security standpoint, but I also think this would be a much more consistent approach to the idea of "accounts."

Would either of you be willing to implement this for me?

[ribuck]

Would either of you be willing to implement this for me?

Sorry, I can't implement it. Although I'm a software developer, I have no experience with C++.

It sounds like a big task because quite a few Bitcoin internals will need to be changed (for example, coin selection for payments will need to become account-aware, as will change-handling).

Finally, I think it was a conceptual mistake to put account handling into the standard client (it belongs in the business logic, external to Bitcoin), so this is not a development task that I would find interesting.

[ribuck]

Chaord, would it be sufficient to have the ability to split a bitcoin wallet into online/offline parts, without needing to tie each private key to an account? This would not harm the existing account functionality, and would be very useful to a lot of people.

[chaord]

Chaord, would it be sufficient to have the ability to split a bitcoin wallet into online/offline parts, without needing to tie each private key to an account? This would not harm the existing account functionality, and would be very useful to a lot of people.

As long as we can effectively have one part of the wallet "offline" such that coins cannot be transfered without insertion of the usb stick, I'd be happy.  I don't necessarily need the "account" aspect.  That can all be done with business logic, as mentioned.  I need the online/offline aspect for security reasons and was merely describing it using the "accounts" feature, thinking that would be the easiest entry point.

Thoughts?

[theymos]

The easiest method would be to create a key, send bitcoins to it, and then move that key.

To import the key again, you'd either have to re-scan the block chain, or Bitcoin would have to be modified to continue watching for transactions to that key.

[chaord]

The easiest method would be to create a key, send bitcoins to it, and then move that key.

To import the key again, you'd either have to re-scan the block chain, or Bitcoin would have to be modified to continue watching for transactions to that key.

Yeah, something along these lines could work.  So would anyone be interested in laying out an exact plan to accomplish the desired goal and coding it up asap? for pay?

[BitterTea]

The easiest method would be to create a key, send bitcoins to it, and then move that key.

To import the key again, you'd either have to re-scan the block chain, or Bitcoin would have to be modified to continue watching for transactions to that key.

Wasn't there talk of adding a command line switch or JSON-rpc command for the client that would force it to rescan the block chain? I thought the code might have already been written, even.

[theymos]

Wasn't there talk of adding a command line switch or JSON-rpc command for the client that would force it to rescan the block chain? I thought the code might have already been written, even.

It is. A -rescan switch exists in gavin's branch. Key import has not been implemented, though, and export is only available through a third-party tool.

The -rescan switch might be too slow to be frequently usable. I don't know how much faster it is to rescan than to re-download the block chain.

[BitterTea]

It is. A -rescan switch exists in gavin's branch. Key import has not been implemented, though, and export is only available through a third-party tool.

The -rescan switch might be too slow to be frequently usable. I don't know how much faster it is to rescan than to re-download the block chain.

Ah, I might have to check that out. I've been working on an off on a tool that does some helper functions for Bitcoin. I've got it set up right now where it keeps each configured wallet encrypted until you launch Bitcoin with that particular wallet. The problem is that if Bitcoin downloads new blocks while running under one wallet, it won't see those blocks while running under another.

I'd love to contribute to the Bitcoin client, especially working on implementing encrypted private keys, but looking at the code is daunting... I'm so spoiled from all the layers of abstraction coding in .Net...

[Gavin Andresen]

-rescan will be in 0.3.20.

It takes about a minute right now on my machine (but that will get longer and longer as there are more and more transactions in the block chain).

[theymos]

It takes about a minute right now on my machine (but that will get longer and longer as there are more and more transactions in the block chain).

Interesting. I thought most of the block download time was due to verification, which is replicated with -rescan. Is it faster because it doesn't write to disk at all?

[MoonShadow]

This request is functionally identical to my previous request for an 'export to file/import from file function', except mine included transaction data as well.  I don't understand why this is such a difficult thing to implement, since GnuPrivacyGuard can import and export public and/or private keys to files, which I can then attach to emails if I desire.  Granted, this is extremely dangerous with private keys; but it's going to happen anyway.

[davout]

This request is functionally identical to my previous request for an 'export to file/import from file function', except mine included transaction data as well.  I don't understand why this is such a difficult thing to implement, since GnuPrivacyGuard can import and export public and/or private keys to files, which I can then attach to emails if I desire.  Granted, this is extremely dangerous with private keys; but it's going to happen anyway.

Depends on what you want exactly, with the accounts thing as described originally, it's pretty hard.
Just exporting a key, and rescanning upon re-import is not that hard.

[chaord]

Depends on what you want exactly, with the accounts thing as described originally, it's pretty hard.
Just exporting a key, and rescanning upon re-import is not that hard.

Not being intimately familiar with the source code, I probably should not have described the goal in terms of "accounts."  It sounds like creighto is after an almost identical feature.  Perhaps we should start a new fresh thread that won't bog us down thinking about the account intricacies.  Instead we can focus on simply allowing private keys to be exported to (and read from) from outside the standard wallet.dat file.

If I am understanding bitcoin's internals correctly, one thing that seems to be a hold up is the "change transaction."  Correct?  So assuming you had say, 100 BTC in a bitcoin address tied to private key Y, which is located on a mounted USB drive.  If you wanted to send all 100 BTC to a new address, everything would work fine.  However, if you wanted to send, say, 80 BTC, to a new address, you'd need an additional private key (eg bitcoin address) on the USB stick available to receive the 20 BTC as change. Am I understanding the issue correctly?

[theymos]

If I am understanding bitcoin's internals correctly, one thing that seems to be a hold up is the "change transaction."  Correct?  So assuming you had say, 100 BTC in a bitcoin address tied to private key Y, which is located on a mounted USB drive.  If you wanted to send all 100 BTC to a new address, everything would work fine.  However, if you wanted to send, say, 80 BTC, to a new address, you'd need an additional private key (eg bitcoin address) on the USB stick available to receive the 20 BTC as change. Am I understanding the issue correctly?

It's allowed to send the change back to yourself, though Bitcoin doesn't do it right now.