Bitcoin Forum
December 10, 2016, 03:14:10 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Help Wanted (for pay): Implement "offline account" capabilities  (Read 1986 times)
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
February 08, 2011, 08:25:27 AM
 #1

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!
1481339650
Hero Member
*
Offline Offline

Posts: 1481339650

View Profile Personal Message (Offline)

Ignore
1481339650
Reply with quote  #2

1481339650
Report to moderator
1481339650
Hero Member
*
Offline Offline

Posts: 1481339650

View Profile Personal Message (Offline)

Ignore
1481339650
Reply with quote  #2

1481339650
Report to moderator
1481339650
Hero Member
*
Offline Offline

Posts: 1481339650

View Profile Personal Message (Offline)

Ignore
1481339650
Reply with quote  #2

1481339650
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 08, 2011, 11:07:22 AM
 #2

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
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
February 08, 2011, 01:36:02 PM
 #3

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

ribuck
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 08, 2011, 01:53:26 PM
 #4

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
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
February 08, 2011, 02:21:44 PM
 #5

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
Full Member
***
Offline Offline

Activity: 218


View Profile
February 08, 2011, 04:28:20 PM
 #6

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
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 08, 2011, 05:02:44 PM
 #7

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
Donator
Legendary
*
Offline Offline

Activity: 826


View Profile
February 08, 2011, 05:07:33 PM
 #8

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
Full Member
***
Offline Offline

Activity: 218


View Profile
February 08, 2011, 08:10:07 PM
 #9

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
February 08, 2011, 08:27:13 PM
 #10

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
chaord
Full Member
***
Offline Offline

Activity: 218


View Profile
February 08, 2011, 09:46:07 PM
 #11

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
Sr. Member
****
Offline Offline

Activity: 294



View Profile
February 09, 2011, 12:09:19 AM
 #12

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
February 09, 2011, 01:32:56 AM
 #13

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
February 09, 2011, 04:08:03 AM
 #14

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
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
February 09, 2011, 04:35:30 AM
 #15

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

How often do you get the chance to work on a potentially world-changing project?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
February 09, 2011, 04:50:20 AM
 #16

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?

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
February 09, 2011, 07:50:45 AM
 #17

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
davout
Legendary
*
Offline Offline

Activity: 1358


1davout


View Profile WWW
February 09, 2011, 09:08:47 AM
 #18

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
Full Member
***
Offline Offline

Activity: 218


View Profile
February 09, 2011, 04:02:34 PM
 #19

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
Administrator
Legendary
*
expert
Offline Offline

Activity: 2506


View Profile
February 09, 2011, 04:35:36 PM
 #20

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!