Nostr Web Client

The derivation paths doesn't really change anything in the meaning of the policy, so as long as it's a path you can export from your signer, everything will work.

(some devices might have path restrictions for xpubs they export, though - so using standard patterns maximizes compatibility)

What is your goal?

Big Barry Bitcoin 8mo ago

I was thinking about 2 things...

1. The coldcard's co-signing feature https://coldcard.com/docs/coldcard-cosigning/

2. Their satscard/tapsigner.

In both cases, you could have the device generate a master key that you will never know. Only the device knows it (I might be wrong about the co-signing feature).

With the tapsigner, you give it a chaincode, and that _theoretically_ gives you a key that you know Coinkite would never know.

You can export the XPUB of m/0' (I think) and it will have your chaincode in it.

But... Since the rest of the derivation path is hardened in a typical key, you can't verify that the xpub for a typical wallet is derived using your chaincode.

So....

What if, just for that one key in a multisig setup, you don't use the typical derivation path so that you can confirm that it uses your chaincode, and since the change and index are not hardened, it still works as expected.

Just trying to think about how you can Guarantee that neither the manufacturer or yourself knows the private key.

Reply to this note

Please Login to reply.

Discussion

salvatoshi 8mo ago

> Just trying to think about how you can Guarantee that neither the manufacturer or yourself knows the private key

What for? I see footguns in this scheme, but I don't quite see the benefits.

In general, I think that both cosigners and blind signers are unlikely to make much much sense in multisig setups - much more useful in miniscript wallets, where you can do more 'experimental' stuff with the primary spending path, while keeping recovery paths straightforward.

Big Barry Bitcoin 8mo ago

Mostly just spitballing. Benefit in my head is:

1. Create an opendime where you know Coinkite doesn't know the key, and the recipient knows you don't know the key.

2. Create a #bitkey but know that Block doesn't know the key on your device as well as on their server.

I think it's powerful being able to give your customers the ability to verify that your products are not cheating them.

The tapsigner can be verified, but you have to export your key and decrypt it on a secure computer to prove it to yourself.

salvatoshi 8mo ago

I'm gonna shill this blog post I wrote some time back: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript

If you don't trust a signing device, it's really hard to meaningfully use it without additional devices - I don't think creative paths can help much. For example, a device could lie about the xpubs you ask.

Big Barry Bitcoin 8mo ago

... But if you use that xpub to generate an address and the device signs it, where can the lie exist?

Big Barry Bitcoin 8mo ago

To be clear, knowing that the chain code is in the xpub and it is one you supplied yourself. This is how you would know it isn't malicious.

salvatoshi 8mo ago

Yes, of you provide a chain code yourself and it has enough entropy, then it works somewhat. But it's not better than a 2-of-2 between the device and the software wallet in terms of security model, and I think the latter is easier to analyze.