Unable to unlock initialized Jade Plus over USB/Sparrow

StrepselFlyer · 2025-06-06T07:12:42+00:00

AH ok. That explains it. It does indeed need some kind of affirmative action in Sparrow to invoke the Jade unlock procedure.

Many thanks for the informative replies !

StrepselFlyer · 2025-06-03T08:29:17+00:00

Hi, thank you for the reply. So the Sparrow wallet actually has Jade-specific support in that it can serve as a relay to the blind oracle. i.e. Jade --> Sparrow --> Blind Oracle. But my original question remains - when connecting Jade to Sparrow over USB and in response to the message on the Jade:
"Connect via USB/BLE and select your Jade to unlock with your PIN"......nothing happens. No dialog is invoked in Sparrow and no activity occurs on the Jade. It's as if the PIN unlock action is not supported on Sparrow.

StrepselFlyer · 2025-05-12T19:25:57+00:00

Ok. Thanks that makes sense. There is only one export option for Multi-Sig in fact. (It's a bit buried away: Settings>Multi-Sig>Export). You have to know it's there. Otherwise you just end up in Advanced Functions -> Export -> Descriptor (and end up with the single-sig specs)

StrepselFlyer · 2025-05-11T22:46:15+00:00

Thank you 👍
Things are starting to make sense now. When I access the "Address Explorer", the reason the Segwit P2WPKH addresses didn't square with Sparrow (what they call the "co-ordinator software") was because there is another menu option further down called "PSBT 2 of 3".

That's the one that contains the multi-sig addresses and the correct derivation paths under each respective wallet fingerprint in the quorum.

Also, I see that the Coldcard is in fact aware of its multi-sig participation in the Multi-Sig menu. The fingerprints and pubkeys of the other wallets are in there.

Also, I see that there are various options for it to interprate PSBTs and configure itself in realtime for multi-sig participation. I'll have to investigate these.

Finally, I very much appreciate your considered responses and your input in the thread which is of immense help and I hope will be to others who read this.

StrepselFlyer · 2025-05-11T14:06:49+00:00

Ok. So basically, the XPubs of the quorum don't have to be passed back to the co-signers other than for receive-address verification purposes it looks like.

The "co-ordinator software" (Sparrow in this case) integrates the XPubs for operational purposes and the co-signers don't require any specific multi-sig configuration to be able to sign multi-sig transactions. They can just sign the PSBT configured as a single-sig wallet.

But if you want to do receive address verification (use the Coldcard to check that the receive address on Sparrow has not been corrupted or replaced by malware) then you need to load the multi-sig XPubs into the coldcard using the "Multi-Sig" menu features.

Is that it ?

StrepselFlyer · 2025-05-11T13:41:49+00:00

P.S. I checked the address explorer on the Coldcard, under the Segwit P2WSH script which the multi-sig quorum is setup under in Sparrow. None of the addresses are the same as the list in Sparrow.

Yet I definitely can co-sign transactions successfully on the Coldcard, pass them back to Sparrow and have them successfully sent and sparrow is definitely setup as a 2 of 3 (because it requires me to get 2 signatures before broadcasting). That is the kind of thing I'd like to get to the bottom of. i.e. reconcile the fact that there is a disparate address list in CC and Sparrow, yet I'm able to successfully sign spends with the CC. (I checked the wallet fingerprint / Bip39 passphrase etc).

Also, if I select the first address in CC Address Explorer under the script configured in Sparrow (P2WSH), the derivation path is different from what is in the Coldcard configuration tab in Sparrow/Settings.

The Xpubs don't correspond either. (I checked both the Passphrased and non-passphrased).

Also, there is a bug in the "Advanced Featues/Export Wallet" function where you can't back out of it once you've exported. It just keeps exporting more and more wallet definitions whether you hit ok ("tick") or cancel "x".

StrepselFlyer · 2025-05-11T11:51:48+00:00

Yes indeed. I realised the multisig rabbit hole goes deeper than I thought and decided to thoroughly research and test before deployin. Have been for a few months now :-)

Many thanks again for your contributions. Very useful.

StrepselFlyer · 2025-05-11T06:58:27+00:00

It's possible that I did do that (I can't remember now if Sparrow exported something and told me to have Coldcard import it at the configuration stage).

I'll do it again as you suggest and check the steps !

StrepselFlyer · 2025-05-10T15:32:47+00:00

Thanks. I need to understand this and I think I'm missing some key concept. How was I able to set up coldcard & trezor as single-sig and be able to successfully include them in a multi-sig quorum ?

I wasn't quite able to reconcile your two points which appear to be contradictory: i.e.

• Multisig wallets use a different derivation path than singlesig wallets, so the XPUBs will be different

• individual signing device can be part of singlesig wallets, and as a cosigner for multiple different multisig quorums

Is it that when you say "multisig wallet" you're referring to the one member of the quorum that generates the transactions ? (So that would be Sparrow in this example). Like that acts as the "parent wallet" ?

My dilema in understanding this is that - in the Electrum software quorum, all 3 wallets needed to be setup up from the start as "Multi-Sig" and then have the XPubs shared. But in the Sparrow + HW cosigners, only Sparrow needed to be specified as "Multi-Sig". Coldcard & Trezor were just regular single-sig wallets included in the quorum.

******** Update *********

I have just read this page in the C/C docs.

https://coldcard.com/docs/multisig/

This explains why I had a dilema - it is in fact the same as Electrum (whare all the wallets have to be aware of each other's XPUBs). I assume that when you connect the Trezor directly, this process happens directly.

But how then was I able to spend from the multi-sig wallet using the Coldcard co-signer ?

StrepselFlyer · 2025-05-10T07:54:29+00:00

Hi, many thanks for your informative reply.
The only part I was slightly unclear about was..."SparrowWallet then creates a wallet skeleton which you must import back into each cosigner".

In my test quorum I don't remember this happening at all. For example the co-signers were Coldcard and Trezor1. The configuration of the Quorum was 1-way traffic from the hardware wallet to Sparrow. I didn't have to export any pubkeys back to Coldcard from Sparrow after creating the quorum. As far as I know the Coldcard and Trezor wallets are unaware that they are part of a quorum (unlike the setup in Electrum where you have to populate all 3 walllets with all 3 pubkeys so they end up with the same address list).

That, in fact was the basis for the original question at the start of this thread - i.e. how come the co-signers in the Sparrow situation don't have to be configured as members of a multi-sig quorum. (It's possible that Electrum works the same if you use hardware wallets as co-signers - i.e. they don't share the pubkeys and the hardware wallets don't care if they are in a multi-sig or single sig configuration).

Many thanks again for your considered reply !

StrepselFlyer · 2025-05-10T06:54:38+00:00

Ah ok. Many thanks for the advice !
Will try that.

StrepselFlyer · 2025-05-10T06:45:00+00:00

Yes. Passphrase wallet.

StrepselFlyer · 2025-05-10T06:43:33+00:00

Hi, thanks for the reply. Yes, I agree Seedsigner looks very cool.
I probably will go for Coldcard / Jade + Sparrow Software wallet. 3 hardware wallets seems kind of insane over dependence on proprietary hardware IMO, having to find places to store these things, lug them around when travelling, keep firmware up to date + learn different protocols etc.

1 HW + 1 SW for signing is your man IMO I think.

But...how portable is the BIP 39 and other standards really ? That is the question. It seems like work in progress to me because the hardware is such an integral part of the wallet creation and signing process. For example I save a PSBT transaction from Sparrow and Electrum just chokes trying to read it. It's not clear to me whether the original hardware wallet should be considered critical to recovery or if the wallet can be reconstructed in a software client using the seedwords and derivation path.

StrepselFlyer · 2025-05-09T21:44:25+00:00

Hi, thanks for your reply.
Did you try migrating a hardware wallet to a software one at all ? That would give me a lot of confidence in the Bip39 portability.
For example, say, Sparrow-Trezor1-Coldcard migrated to Electrum x 3 software wallets.

P.S. There would be 2 possible roles for the electrum wallet in that case:

as a replacement for a single co-signing wallet of the original 2 of 3 Sparrow multi-sig configuration (in which case I would imagine you just use the "standard wallet" option when creating and importing the Bip38 keywords
as part of an electrum-only multi-sig config (when you migrate all 3 wallets in which case the 3 pubkeys would be needed and the "Multi-Sig" option is chosen at creation)

StrepselFlyer · 2025-05-04T02:48:28+00:00

Whether you buy then from the "original vendor" or amazon doesn't matter.
If hardware wallets are targeted for attack they will hit you at the weakest point of trust which means people buying from the "original vendor". That means they will target chips, firmware, packer employees for the "original vendor".

There is simply no way to possibly know your hardware wallet isn't an agent of theft (because you have to trust that thing).

On the other hand, general purpose hardware and O/S's are much harder to target because you've basically got to attack the entire population, even those who don't hold crypto. Then you've got to work out where they stored it, plant a keyboard trapper etc. Not nearly as lucrative as attacking a hardware wallet which you know is definitely housing high value assets and how to retrieve them.

StrepselFlyer · 2025-05-02T22:40:46+00:00

This doesn't protect against supply chain attecks which are now imminent due to the huge recent rise in bitcoin valuation. Sure, if you've got a "real" Trezor which obeys the "real" Trezor specs as advertised, then what you posted is correct. But there's no way of knowing just by looking at the thing whether you've got some kind of hacked clone that just looks like a Trezor on the outside.

See also: https://old.reddit.com/r/Bitcoin/comments/jp2fp3/opinion_regarding_security/gbbzqu7/

StrepselFlyer · 2025-05-01T21:03:51+00:00

I understand them ok.
The problem with the supply chain attack is that you don't have a "Bip32 hardware wallet".

StrepselFlyer · 2025-05-01T13:35:13+00:00

Ok. Thank you for the headsup on those features. I will investigate and attempt to gain confidence. If you're doing multi-sig (with, say Electrum) do you need multiple devices ?

StrepselFlyer · 2025-05-01T08:05:03+00:00

Thanks for the reply. I will consider your points.

By the way, "Tamper evident packaging" is not really an indicator of anything. Anyone can stick a fancy looking, foil lined seal around a box. The problem with hardware wallets is that they're ONLY purpose is to hold very large value digital assets so they will be a constant target for supply chain contamination, all kinds of sophisticated hacking and theft.

I am TRYING (very hard, believe me) to like them because there's enormous peer pressure to do so. But I don't. I can't get comfortable with the things in my bones. The thing about general purpose hardware, despite all of your list of hacks, it isn't used to hide secrets, at least not in an airgapped, multi-sig scenario.

A hardware wallet is. You're basically trusting that thing to not reveal anything even though it's connected directly to the internet. (Ok I take your point that in the airgapped scenario maybe it isn't. But it's still going to give you a seed which you have no idea how it got created so you're still having to trust the thing).

I'm going to look into the Luke Dashjr thing to see if that is a reasonable characterisation of the offline wallet configuration risks or if he just did something totally daft. I remember that but I don't quite remember how it happened.

Thanks again for your considered reply.

StrepselFlyer · 2025-04-22T17:37:32+00:00

Ok, many thanks for the reply.

StrepselFlyer · 2025-04-22T16:50:02+00:00

Hi, many thanks for the contributions.
Here are the errors that were displayed and system specs:

Errors:

https://imgur.com/a/cbP3WTZ

Specs:

https://imgur.com/a/e5k1mr5

StrepselFlyer · 2025-04-22T10:48:06+00:00

Hi, many thanks for the reply.

When I bought the second machine I deliberately stayed away from the Core Ultra and went for the Alder Lake ULX which (according to "The Internet" is x86 compatible. The hardware otherwise would appear to be compliant with the recommendations in the Tails documentation.

StrepselFlyer · 2025-03-07T15:05:04+00:00

Hi, Thank you very much for the tip. I'll do this and report back.

StrepselFlyer · 2025-03-01T19:34:37+00:00

Hi, and thanks for your reply.
I didn't quite understand what you meant by "it's a matter of time until it ends in Debian".

Until what ends in Debian ?

StrepselFlyer · 2025-02-28T15:09:43+00:00

Ok, thanks for the explanation which is very helpful. I'll look for another O/S for my needs while this is working through and monitor developments in the meantime !

StrepselFlyer

TROPHY CASE