Computing the BIP32 master key from multiple derived keys

[buhrmi]

Hey guys,

does somebody know if it's possible to compute the master key (xpriv) from multiple derived private keys?

[1715142231]

1715142231

[achow101]

It depends on the type of derivation that you used.

If you used unhardened derivation, and you have both the parent xpub and a child private key, you can derive the parent xprv.

If you used hardened derivation, then it is impossible.

[BrewMaster]

you still can't compute the master key (private or public) by only having the child keys (private or public) because the process is simply irreversible since it uses SHA512 hashes inside the HMAC.

[buhrmi]

I see, thanks.

So here is the question:

Assuming my xpub is publicly available.
Is there a way that I can send ONE derived private key (lets say m/12345) to another party, to enable the other party to sign a message ON MY BEHALF, without enabling the other party to calculate my xpriv, BUT allowing the public to verify that "yes, that message was indeed signed with the 12345th key"?

I'm trying to implement an encryption scheme that uses derived keys to enable another party to sign a message on my behalf (where I don't care about the content). Or is there already a mechanism that implements something like this?

[buhrmi]

Some more background on what I'm trying to do:

I want to implement a multi-signature process where some selected nodes send private keys derived from their xprivs by a determined derivation path (eg m/12345) to a collector node. This collector node then proceeds to multi-sign a message using those private keys, and all other nodes will be able to easily verify this multi-sig by deriving the corresponding public keys from the publicly available xpubs of those selected nodes.

But I do not want the collector node to be able to compute the original xpriv of the selected nodes. So the derived private keys that are being sent to that collector node should serve as "one-time throw-away keys".

[BrewMaster]

Assuming my xpub is publicly available.
(lets say m/12345) to another party,

12345 is a non-hardened key (anything below 0x800000, or paths that don't have the hardened indicator like 12345') so now that you also have your master key available alongside a child as achow101 pointed out your master private key can be easily calculated.

to enable the other party to sign a message ON MY BEHALF,

when you give your "private" key to someone then it is no longer "on your behalf" because they have full control over that key.

without enabling the other party to calculate my xpriv,

you can use a hardened path which would be 12345' then it is not possible to compute the xprv but it still is very flawed design to send someone the private key.

I'm trying to implement an encryption scheme that uses derived keys to enable another party to sign a message on my behalf (where I don't care about the content). Or is there already a mechanism that implements something like this?

what purpose does this signed message server? maybe there is a better way to achieve the same thing.

[buhrmi]

what purpose does this signed message server? maybe there is a better way to achieve the same thing.

I've just added another reply to provide some background while you were answering

The purpose is to multi-sign a message that is not known to the nodes, but only to that collector node. I want to generate "one-time-use throw-away" derived private keys that this collector node can use to sign that message and prove to all other nodes in the network "all these nodes have signed this message. This multi-sig is the proof".

The issue I'm having is that when I send the collector node a hardened m/12345' key, it's impossible to verify the signature because the verifying nodes cannot derive a the corresponding hardened public key from xpub

[BrewMaster]

The issue I'm having is that when I send the collector node a hardened m/12345' key, it's impossible to verify the signature because the verifying nodes cannot derive a the corresponding hardened public key from xpub

you can't have both with BIP-32 design because it is defined in a way that you either can compute pubkeys from xpub and that means revealing a single child private key reveals xprv or you can not derive pubkeys from xpub which means revealing child private key doesn't reveal xprv.

The purpose is to multi-sign a message that is not known to the nodes, but only to that collector node. I want to generate "one-time-use throw-away" derived private keys that this collector node can use to sign that message and prove to all other nodes in the network "all these nodes have signed this message. This multi-sig is the proof".

what if this collector node sent the hash of the message to the node and that node signed the message itself?

you see in ECDSA when you want to create a signature from an arbitrary length message you don't sign the message itself, instead you use a hash algorithm (double SHA256 in bitcoin) then use that result in the signing formula.
so the collector node could hash the message itself (the first step of signing) then send that hash to the node that has the private key locally and can sign it then send the signature back to the collector node.
since hash is a one-way function the receiving node can not know what the message was.

[buhrmi]

what if this collector node sent the hash of the message to the node and that node signed the message itself?

you see in ECDSA when you want to create a signature from an arbitrary length message you don't sign the message itself, instead you use a hash algorithm (double SHA256 in bitcoin) then use that result in the signing formula.
so the collector node could hash the message itself (the first step of signing) then send that hash to the node that has the private key locally and can sign it then send the signature back to the collector node.
since hash is a one-way function the receiving node can not know what the message was.

I can't do that, because the message that is to be multi-signed includes a list of all nodes that have sent a private key to the collector node. It's up to the nodes whether or not they want the collector node to include them in the list.

The purpose of this exercise is to implement a new consensus algorithm to replace proof-of-work. Let's call it proof-of-votes. I'm still working on the white paper. In this proof-of-votes-based chain, the chain with the cumulative highest amount of votes is the "valid" chain. Let's assume there are 10000 nodes participating in the network. In this proposed consensus algorithm, nodes cast votes by sending a one-time-use private key (m/n where n is the next block height) to the node they vote for (the collector node). The collector node then collects these keys and uses them to multi-sign the next block hash. The multi-sig is the proof-of-votes and is included in the block header, while all the nodes that voted for the collector node are included in the block body and receive coins. So up until the actual creation and signing of the block hash, the collector node doesn't even know which nodes will end up in the block body. The collector node doesn't just want to collect signatures from the nodes, because including all the signatures in the block header will make the block header balloon to unfeasible sizes. Broadcasting a multi-sig created with 5,000 private keys is feasible, but broadcasting 5,000 individual signatures is not.

When the new block is broadcasted, all the other nodes in the network need to be able to verify the multi-sig. So they take the xpubs of the 5,000 nodes included in the block body, derive the m/nth pubkey and validate the multi-sig.

So that's why I'm asking if there is a way to share a "throw-away" private key with one collector node, while at the same time having the xpub publicly available to allow all the other nodes to verify what the collector node has been doing with the private key. Without enabling the collector node to calculate the original xpriv.

Maybe BIP-32 isn't the right tool for this job. So now I wonder if there is something else that I could use to "shrink" multiple signatures into one tiny signature to implement this algorithm.