Multisig issues with electrum

[boofusmc]

Has anyone had luck using electrum to configure/run a multisignature wallet using multiple Coldcards?

I've tried to do this several ways... going through electrum with the coldcards attached and just inserting the xpubs without attaching the coldcards. Wallets are made with derived addresses, and Im able to send to those addresses. However, when I try to spend from those addresses, I get an error that p2sh is not supported.

Any way around this?

[1713246504]

1713246504

[1713246504]

1713246504

[1713246504]

1713246504

[BitMaxz]

Honestly, never heard about coldcard wallet before and I tried to search in google and I heard that they don't support p2sh.

Take a look at this tweet from coldcard https://twitter.com/coldcardwallet/status/1025404753872732160?lang=en

Someone also experienced the same error as yours and they recommend to use other derivation paths "Did you do the m/45’/0 scheme" try to change your derivation path to m/45’/
And let's see if it works.

[jackg]

Using with Electrum via USB
install Electrum version 3.2.3 or later, with Coldcard support: download here
select "New/Restore" from File menu
pick file name
pick "Standard Wallet"
pick "Use a hardware device"
select the Coldcard device shown
choose Segwit or classic address format
operates like any other USB hardware wallet

https://coldcardwallet.com/docs/quick

Does it work without multisig? Potentially it could need a firmware update or an update of electrum (if they're not both up to date).


It may be that they might not support multisig however I think that's unlikely and if they don't they probably will soon.

[boofusmc]

AFAIK the only way electrum asks you to the derivation, allowing you to specify m/45', is if you restore a single wallet from seed - and entering your seed phrase into the computer negates the security benefit of your seed and private keys remaining completely air gapped w the coldcard. You are never asked for the derivation path when setting up a multisig wallet in 3.3.4; Ive tried doing so with the xpub keys as well as having the device attached to the computer. I know that they dont completely support multisig but on their github it also states:

"each Coldcard can only be a single "leg" of the multisig
we do not support PSBT combining of transactions involving P2SH signatures (but you can do your own combine step off-device)"

...but anyone have any clue how to do a "combine step off-device" ?

[jackg]

With legacy I think so, with segwit no.

I don't think you can use segwit at all with the device but I think that just means that you sign the transaction in stages.

So say there's 3 devices, you use one of the devices wallets to make the multisig and sign it, you then sign it with the others later on.

[boofusmc]

I've even tried making 3 separate legacy wallets in electrum, then verifying that a 2 of 3 multisig wallet, which utilizes the xpubs of these wallets, is able to spend BTC from it. I then take the xprv of one of the wallets and import it into the coldcard during setup. Unfortunately it still wont sign the transactions in this one wallet as the derivation scheme utilized by coldcard seems to be different than electrum, and no where does it prompt you to change this in the setup of either the coldcard or electrum.

Any ideas?

[HCP]

Using the xprv likely won't work... the xprv that is "stored" in an Electrum wallet is not the "root key" generated from the seed... but an Account Extended Key. That is to say, it is the xprv calculated from the path m/44'/0'/0'

Electrum then uses a derivation path of m/0 and m/1 to generate the "receive" and "change" keys/addresses, respectively, from that starting point.

However, I would guess that the Coldcard is attempting to use the full m/44'/0'/0'/0 derivation path and therefore is effectively using a "combined" Derivation Path of m/44'/0'/0'/44'/0'/0'/0 and that is why it would be generating different keys/addresses (and unable to sign your transaction)

If you start with the Coldcards... and export the three xpubs from those. Then, import those xpubs into three different Electrum (File -> New/Restore -> Standard Wallet -> Use a master key), wallets, do you get the correct addresses generated? If so, are you then able to create a MultiSig in Electrum from those three xpubs?

[boofusmc]

Using the xprv likely won't work... the xprv that is "stored" in an Electrum wallet is not the "root key" generated from the seed... but an Account Extended Key. That is to say, it is the xprv calculated from the path m/44'/0'/0'

Electrum then uses a derivation path of m/0 and m/1 to generate the "receive" and "change" keys/addresses, respectively, from that starting point.

However, I would guess that the Coldcard is attempting to use the full m/44'/0'/0'/0 derivation path and therefore is effectively using a "combined" Derivation Path of m/44'/0'/0'/44'/0'/0'/0 and that is why it would be generating different keys/addresses (and unable to sign your transaction)

If you start with the Coldcards... and export the three xpubs from those. Then, import those xpubs into three different Electrum (File -> New/Restore -> Standard Wallet -> Use a master key), wallets, do you get the correct addresses generated? If so, are you then able to create a MultiSig in Electrum from those three xpubs?

Thx for the reply - unfortunately Ive tried generating the wallets in the coldcard, exporting the xpub (can be found in the json wallet file the coldcard makes for electrum), then making a new wallet in electrum with the exported xpub. When all is said and done, it wont wont work in a multisig setup :/ Unfortunately the coinkite support has not replied to my query to specify what they mean using each as a "single leg" in a multisig setup.

[pooya87]

the xprv that is "stored" in an Electrum wallet is not the "root key" generated from the seed... but an Account Extended Key. That is to say, it is the xprv calculated from the path m/44'/0'/0'

are you sure about this?
i just checked an extended private key from a testnet wallet and it is indeed the master private key at path m not the extended (child) one at some other path.
you can decode them using http://bip32.org/ (it goes without saying that you if you do it,  you should consider it compromised). when the depth, parent fingerprint and Child Index are all zero it means you have the "root key"

[HCP]

are you sure about this?

Nope! Hmmmm maybe it is just the SegWit "xprv" (actually a zprv) that I saw doing odd things...

From the Electrum SegWit seed:

Code:

    "keystore": {
        "pw_hash_version": 1,
        "seed": "wine comfort off fat pudding initial wash they tennis fashion never nuclear",
        "type": "bip32",
        "xprv": "zprvAYvZpviDe8FvV1uHrqohakCtZ3M4Cv6pcZYqcvzHb1Ujh8s1c3J3cMzza2bCcK91iyik8dZJU3LSiMFkBtppQNSdmcpq3sxtBiT7ojnHq45",
        "xpub": "zpub6muvESF7UVpDhVykxsLhwt9d75BYcNpfynUSRKPu9M1iZwCA9acJAAKURHHq8bPcLS3X2p39SJHW45WYmWcsXzPdBTf5f8cPSf7tgUSipez"

You can see the stored zprv... it produces this address:




But, when we put the seed into the converter... we get this:




So, to see the same "xprv" (as stored in the wallet) in BIP39 converter... you need to use a derivation path of: m/0'

But... then addresses shown are NOT the ones in the wallet!!


To see the correct address you need the extra "0" (path= m/0'/0), which gives the correct addresses, but shows the wrong xprv:




Meanwhile, in Legacyland...

Code:

    "keystore": {
        "pw_hash_version": 1,
        "seed": "resist flee ginger seminar pretty walnut basic shift you reason trigger battle",
        "type": "bip32",
        "xprv": "xprv9s21ZrQH143K3jnoRp5JYq2zjuw1d6rAUmkMT2has1wFujr5SPQdDDma3jwjMRV1rT8xS7ZdeQywSdhzc7SHVncCEQH4FjK9DUKM7ip6WBU",
        "xpub": "xpub661MyMwAqRbcGDsGXqcJuxyjHwmW2Za1qzfxFR7CRMUEnYBDyvism263tzxQZLdm8Z2q44HbmjRKk3A28nMJMgM57fBdpnmEMmPSo8rSM7S"
    },

Which generates this:



The "xprv" stored in the wallet, is the same as you get if you put the seed into the converter... (so path=m):



but again, does not show the correct addresses until you add a 0 (path = m/0):



It all seems a bit confusing and somewhat inconsistent... but seems to be because the old BIP44 stuff only had:
m / purpose' / coin_type' / account' /  change / address_index

whereas the newer stuff apparently uses:
m / purpose' / coin_type' / account' / script_type' / change / address_index

But the "xprvs" we have stored in the wallets, are actually at m (legacy) and m/0' (SegWit) ??!?

This stuff does my head in sometimes!

[pooya87]

This stuff does my head in sometimes!

lol yeah it is pretty weird. i just double checked that and it seems like you are right. the wallet is in fact storing them at that path when it is SegWit! i can't think of any logical reason for doing it though...

ps. you didn't have to bend over backwards with addresses to prove it though you just had to do a decodeBase58Check on the xprv and then take the fifth byte like this:
04b2430c <- version
01 <- key depth (which shows it is at m/whatever instead of being m)
31024186 <-parent fingerprint
80000000 <- child number (which says whatever=0')
c7156a1d875bb40544e96fbe6aabf8cdabef1c5ea8dd0ea1a33602a6b0a26b1f <-chain code
00 <- another indication it is private key
305bd79fcefc145c3c99bbdb11303d0db2fe0aa6be21f7373b5cd44b4502c7f7 <- private key

[Abdussamad]

You can convert extended keys using the Electrum cli now. For example:

Code:

electrum convert_xkey xprv9zKZ5h5h2rxxvA3edftPEgJJUXTWgWHsJL4vqKH7nFxQqMRKVTH1LgPQefDNBizWi3uB7D3iBFbgh3AHmcg9CHjdq6FT8sngyw7R3RuJ2rk p2wpkh

Run `electrum help convert_xkey` for more info.  

You can't change the derivation path though. I wrote a script that lets you do that. It uses electrum functions for everything. Example:

Code:

electrum getmasterprivate | xprv -m - -d "m/0'/0" -c pw2pkh -p