importaddress

CodeShark commented at 0:18 am on December 20, 2012: contributor

The proposal is to add another kind of object to the wallet database - a bitcoin address sans private key - which the client treats as if it were any other wallet adddress except for when it comes to signing and privkey export operations. This means RPC calls such as getreceivedbyaddress and listtransactions can be used on arbitrary bitcoin addresses.

I’ve added an RPC call:

0importaddress <bitcoinaddress> [label] [rescan=true]

The address is added as a new type of serialized object in wallet.dat and loads into the key maps of the CKeyStore instances with the key set to the CKeyID and the secret set to an empty vector.

BitcoinPullTester commented at 0:44 am on December 20, 2012: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/513f8059232f8288a4798ac62f1a9982924ab716 for binaries and test log.

BitcoinPullTester commented at 1:12 am on December 20, 2012: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/cb944ad47e8ce752376783f0104c5ae20b2c88fb for binaries and test log.

luke-jr commented at 1:27 am on December 20, 2012: member

How do you control whether the Bitcoin client includes the address in balances or not? I think it would be helpful to be able to watch addresses without considering them your own.

CodeShark commented at 2:53 am on December 20, 2012: contributor

Right, so there are two solutions I see here:

Ignore nonspendable outputs from balance calculations for sending transactions and add an option to the getbalance method (or add another API call) to distinguish between total balance and spendable balance.
Add support for multiple wallets and require a wallet to either be 100% spendable or 100% unspendable.

It will probably also be necessary to add another field to the returned JSON for certain calls that states whether the addresses are spendable or not.

I would prefer to have a completely separate structure for verification/tracking/ultrapruning of transactions and have the wallet just deal with private key storage and transaction signing. But that would require too many changes to get it integrated quickly. I think either of these two solutions is a reasonable compromise for now, the second one perhaps being more powerful and simpler from a usage perspective.

luke-jr commented at 2:57 am on December 20, 2012: member

Probably option #1 is best, so there can be “this is mine, and I have the private key somewhere else (so prompt me for it when I need it)” too

gmaxwell commented at 3:01 am on December 20, 2012: contributor

Not just “prompt me” but we should actually store some kind of token which is returned. Unfortunately pretty much none of our private key using APIs are setup in a way that would reasonably work with them returning ’need private key with token foo'.

BitcoinPullTester commented at 10:42 am on December 20, 2012: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/f92db3b58692820e1cd72d2beaa653ba225f09ab for binaries and test log.

BitcoinPullTester commented at 11:10 am on December 20, 2012: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/fc05746a0bfce4de4686d8bb0880082e9cf2b7b5 for binaries and test log.

rebroad commented at 3:56 pm on December 20, 2012: contributor

I think a feature to have a number of balances would be ideal, and that way the user can choose which addresses to includes in which groups of balances. Either this, or just have a default separate balance for the offline (i.e. public only) addresses (well, two, one for unconfirmed, and one for confirmed).

sipa commented at 4:23 pm on December 20, 2012: member

I think that would make things too complex for users. Ideally, we’d just have multiwallet support and watch-only wallets, without per-address spendability.

CodeShark commented at 2:38 am on December 21, 2012: contributor

As to not break compatibility with the existing RPC calls, I’m thinking we can have a main wallet which is always used as the default wallet. If the user wants to use a different wallet, the name of the wallet would have to be specified in the call. Unfortunately, it doesn’t look like we can use many of the existing RPC calls (sendfrom, sendmany,sendtoaddress, etc…) since they all have optional parameters already and it would be awkward to just tack on the wallet name parameter at the end. Also, walletpassphrase is problematic as it is not stateless. So it looks like we need a whole separate set of calls which require a wallet name and passphrase (if the wallet is encrypted).

For instance,

0walletsendtoaddress <walletname> <passphrase> <bitcoinaddress> <amount> [comment] [comment-to]

This is one of the unfortunate things about relying on parameter order rather than key-value pairs.

CodeShark merged this on Dec 21, 2012

CodeShark closed this on Dec 21, 2012

DrahtBot locked this on Sep 8, 2021

importaddress #2117