Add RPC for combining multiple private key parts and importing result #9978

It's possible to have several parts of a private key that are only useful when combined. This might be used for vanity addresses, or for a split key with parts stored in separate locations that need to be combined to sweep or spend. Today, combining the private key parts requires the use of in-browser tools, or otherwise obtaining (and potentially compiling) tools like keyconv in the samr7/vanitygen source code. This may be a feature rather than a bug, but it is not particularly simple and often insecure.

It could be better to implement this support into Bitcoin Core instead.

I do not think this support should be added to importprivkey. This could be implemented with the following new RPC/command:

importprivkeyparts "bitcoinAddress" "label" rescan "part1" "part2" ... "partN"

bitcoinAddress would be either empty to indicate no part contribution from that address or a valid Bitcoin address associated with the user's wallet. In the case of a valid address, the private key for the Bitcoin address would be used as an additional part in the combination -- a part0, if you will.

label and rescan would work the same as they do in importprivkey today.

part1, part2, etc would be the individual private key parts in WIF. At least one part would need to be specified.

The actual implementation would simply add the private key parts (modulo the curve's order) and then perform the same operation as importprivkey using the resulting combined private key.

It may be possible to add UI for this but I suspect it's not an operation to broadly endorse with a presence in the UI, but rather should require the use of the console, cli, or jsonrpc to use.

Hi,

I stumbled upon this issue while filtering the history for "least commented issues". :)

If I correctly understand, the idea is to let users specify an arbitrary number of privkeys (but no less than 1) and also an optional address whose privkey could also become part of the future add operation. The other two options, rescan and label, would then be forwarded to importprivkey together with the assembled privkey.

I have played a bit with this idea, and if I had more knowledge about "modulo the curve's order" and what addition in those realms really looks like, the RPC would look like this:

UniValue importprivkeyparts(const JSONRPCRequest& main_request)
{
    CKey assembled_privkey;
    const UniValue& requests = main_request.params[3];
    for (const UniValue& request: requests.getValues()) {
        //Get each of the privkeys from their request objects.
        //Then add them to the assembled privkey.
       assemble_priv_key(request, &assembled_privkey);
    }  
    return importprivkey(assembled_privkey);
}

In client.cpp we would then expand this table:

static const CRPCConvertParam vRPCConvertParams[]

with these entries to get proper argument conversions:

{ "importprivkeyparts", 2, "rescan" },
{ "importprivkeyparts", 3, "privkey_parts" },

And in rpcwallet.cpp's:

static const CRPCCommand commands[] = 

we would insert a new entry:

 { "wallet",  "importprivkeyparts",   &importprivkeyparts,  {"address", "label", "rescan", "privkey_parts"} },

However, all this is the easy part, actually, as I'm not sure what the best way is to execute the aforementioned add operation. There are many functions in secp251k1 that deal with addition, multiplication and various other magical things, but I am not sure if this would make much sense.

I have seen functions like secp256k1_eckey_privkey_tweak_add, but I am not sure if this is the correct way of generating privkeys based on a multitude of others.

If someone could give me a few hints...where to search...or maybe examples of addition and what this "modulo curve's order" is, I'd like to work on this issue.

I think combining of key parts should be done by the program that parted them, not by Bitcoin Core. Unless I am missing something this seems out of scope for the Bitcoin Core wallet.

I think combining of key parts should be done by the program that parted them, not by Bitcoin Core. Unless I am missing something this seems out of scope for the Bitcoin Core wallet.

Ok. Then this issue seems to have deserved to be closed. :)

Ok, closing for now.