Topic: Ledger doesn't show transaction, it shows up in Electrum. What's going on? (Read 366 times)

You're likely quite right, P2MS is realy rare and uncommon. And Pay-to-PubKey has likely only a relevance for the first few tenthousend blocks until it has been replaced by P2PKH.

In the context of Bitcoin private key, public key and address I like to call the latter "public address", because, well, it's supposed to be public and revealing it is no problem, except if you make it clear it's your Bitcoin address which would allow an attribution of the address to you.

It's okay not to count P2MS since it doesn't have an address, just bunch of public keys;
In that sense, count P2PK out as well since it's literally "Pay-to-Pub-Key", just a public key.

BTW, it's been a long time since I read "public address" to refer to "address".
I usually only use it to refer to my addresses that are already shared in public.

If I remember correctly a private key (that's a 256bit number, idealy random) can derive 6 different address types (7 if you count the rare P2MS type).

• Derive an uncompressed public key and use that for the ancient P2PK type "public address" (pay to pubkey)
• Derive an uncompressed public key, hash it with SHA256 and RIPEMD160 and you get a P2PKH type public address, those that start with 1... (pay to pubkey hash)
• Derive a compressed public key, hash it with SHA256 and RIPEMD160 and you get a P2PKH type public address, those that start with 1... too, and are not the same as no. 2 (pay to pubkey hash)
• P2SH or P2WPKH-P2SH, you lock the coins to a hash of a redeem script, which gives you a public address that start with 3... (pay to script hash; nested segwit)
• P2WPKH, native Segwit in Bech32 notation gives you the public addresses that usually start with bc1q...
• P2TR, Taproot in Bech32m notation gives you the public addresses that start with bc1p...

(I'm simplifying things and the Bech32 part is a bit incorrect, but for the sake of simplicity...)

Thanks for this info.

I feel sure I've come across these concepts before, but the problem with bitcoin is that... there's SO DARN MUCH to learn, and I have a head kind of like a bucket. It's kind of full, and if I learn more stuff, some of the old stuff has to go.

Appreciate that there's people like you guys who can clarify!

 

He's not wrong but the article is not contradicting the replies here.

The equivalent to "master private key" that they are talking about is the "master extended key" mentioned in the article.
That master private key is used to derive the wallet's private keys and public keys where the addresses are derived from.

So then, is this guy wrong?

https://6102bitcoin.com/faq-bitcoin-seed/#All-seeds-are-not-created-equal

In his terminology he has this:

Private Key = A secret 256 bit number that you use to spend bitcoin   
Other names = Secret Key

But you're saying that he should have said Master Private Key, not private key?

Taproot address type?

Always feel free to ask any question. Members will be happy to help. These websites can be quite helpful in getting you started.

• https://learnmeabitcoin.com
• https://www.lopp.net/bitcoin-information.html. You will get many more resources under this second website.

A seed phrase (which is called mnemonic phrase as well) is a series of words and can generate the master private key and numerous addresses.


A single private key can generate three types of addresses. A legacy address which starts with 1, a nested segwit address which start with 3 and a native segwit address which starts with bc1.

You're right, I think I am. I was thinking seed phrase is the mnemonic for the private key, but since private key is actually a bitcoin address, it's not. The seed phrase is the mnemonic for the MASTER private key.

Right? So private key = one bitcoin address (which can differ based on script type)?

Sorry for these basic questions. If you have a recommendation on an article/book/video for someone at my level, I'm all ears!

thanks.

In terms of script type: if your address is legacy, native-SegWit, nested-SegWit or Taproot and the two systems restored the same; then, both derived the same script type.
But this is still reliant on the wallet where you imported the master key or seed since it may display the desired addresses but filled the keypool with different script type.

In terms of derivation path: it needs to be exactly the one in the other system to derive the correct private/public key to other system.
Because a single discrepancy in any index from 'master private key' to 'chain index' level will produce an entirely different child keys.
Like for example: m/84'/0'/0'/0* will produce different receiving addresses as m/84'/0'/1'/0*.
So if both systems have same addresses, then their derivation path should be the same as well.

If the addresses generated on two different wallets are the same, it means that they have been derived from the same seed phrase or master key.


I feel you are confusing a private key with a seed phrase and master key.
Take note that there is no derivation path for individual private keys. If you have an induvial private key, to get the correct address, all you need is the script type.

One more question on this one - is it a good rule of thumb to say that if you are viewing the addresses for a private key from 2 different systems, and they're the same, then you have everything correct in terms of script type, derivation, etc?

Electrum is a nicely built piece of software and works well together with a Ledger hardware wallet. Unless OP is using a really outdated version, regular updates aren't a must unless he needs a functionality that exists only in the newer versions. But if it's a minor update like from 4.4.1 to 4.4.6, there shouldn't be any problems with compatibility, particularly since the HW keeps all the keys in place (for now at least ).   

Make sure to update Electrum wallet with latest version, they often release fixes and updates for better compatibility with hardware wallets.
I wouldn't use ledger live app for anything else except for firmware update, and I would seriously consider switching to some open source hardware wallet, instead of closed source ledger.
One more thing, ledger stopped manufacturing model S, so it's just a matter of time when they stop supporting it.

I tried again, and this time connecting with Electrum worked on my Nano S. I thought I had shut down Ledger Live previous to trying to connect last time in Electrum, but maybe I didn't.

Thanks again.

Your Ledger hardware wallet can't only be plugged in to your computer for it to connect with Electrum. You have to unlock the wallet with your PIN, and open the Bitcoin app. It's also important that you don't have Ledger Live open when trying to connect Ledger to Electrum or any other third-party software wallet that's connected to your hardware device. So close all other software wallets, unlock your Ledger, open the BTC app on it, and try to connect to Electrum then.

Would you mind to check if the ledger device is up to date? I don't know what exactly ledger device you have do you mind telling us if it's Nano S, Nano S plus, or Nano X?

Or check the latest version of any of these ledger devices from this link below.

- https://support.ledger.com/hc/en-us/articles/7103926130845-Latest-Firmware-updates-for-Ledger-Nano-S-X-and-S-plus?support=true

Also, what version of Electrum are you currently using? If your device is Nano S there might be a compatibility issue on the latest Electrum version because the last firmware update for this model was released on November 30, 2021, and they no longer provide newer versions.

If you are using the latest version of Electrum can you try to use a lower version of Electrum I suggest 4.3.1?

Clients take xpubs differently:

• Some have specified extended public/private key format per script type like "xpub", "ypub" and "zpub" which indicate the script type of the addresses to be derived.
  Like I've mentioned in the very first reply, Electrum take an xpub as indication to derive standard (P2PKH) addresses from it.
  Blue Wallet isn't strict on this when importing a master key but new addresses will default to whatever the format of the imported xpub.
• Some clients only take the "xpub" format and have their own way of identifying/setting the script type of the addresses to be derived.
  Like for example, Sparrow which uses descriptors.

So based from your latest replies, I think when you imported it to Blue Wallet,
it automatically detected your existing transactions which are for your native SegWit addresses and created a wallet based from it.
But when you requested a new address, since you've imported an "xpub" instead of "zpub" it gave you legacy address type which didn't yet exist in you Ledger Live.

 

It WORKED, thank you so much! It was the script type, I was able to change it both in Ledger Live and Sparrow (thanks for the detailed pointers BitMaxz), and then the transaction showed up.

BTW BitMaxz - I tried plugging the Ledger device into a different USB slot and still no luck with Electrum, though doing it via Ledger Live works fine.

So - where was my big mistake here, where did I go wrong and what should my take-away be? I thought that generating receive addresses from the Xpub was something people did regularly. In Blue Wallet there's not a place (that I saw) to input the script type, when importing an Xpub.

Thank you again for all your help, I was really stuck and you guys helped me out!!

If the addresses on both Sparrow and Ledger start with bc1 these two wallets use the native segwit script type and the Electrum and bluewallet used different script types.

On both Sparrow and Ledger Live, you can switch the script type to legacy or nested segwit you can follow the guide below

For Ledger:
- https://support.ledger.com/hc/en-us/articles/9068401160221-How-to-add-different-formats-of-Bitcoin-accounts-in-Ledger-Live?docs=true

For Sparrow, you can just go to settings under script type and change it to nested or legacy.

Once you are done it should show the legacy or nested addresses and let's hope the addresses are the same as Bluewallet and Electrum.

If it still shows a different address then your last hope is to use the xPub scanner to find the right derivation path and script type.



Would you mind trying to plug it into different USB slots or reboot the device and test it again?

What address type did you get from BlueWallet as receive address where you sent coins to (1..., 3... or bc1...)?



Now it gets a bit confusing. You say Electrum and BlueWallet have same receive adress, but it's not a native segwit type starting with bc1. This is how I understand what you wrote, correct me if I'm wrong. Addresses in Ledger Live are bc1?

I don't use Ledger crap and Ledger Live isn't the finest piece of software engineering. Can you switch address type in Ledger Live to match receive address type used with BlueWallet? Does then the transaction show up?



OK, so all xpubs match and likely are the same as your Ledger hardware would communicate to a software wallet if you'd connect it to a wallet. I assume you screwed up with the address type and/or derivation path.

Thanks for all your input, very much appreciated.

I think the only thing that was a little unusual is that I used Blue Wallet (with the xpub) to get the "receive" address. I didn't generate it or validate it on Ledger. I didn't think that was a problem, guess I was wrong. In Blue Wallet, in the watch only wallet, there's a Receive button that I clicked, no options or anything, it comes up with receive address in the format of a QR code and also a string.

I just checked all locations (Ledger Light, Electrum, Sparrow, and Blue Wallet). The xpubs all match.

To get the xpub from Ledger Light, I followed this process: https://support.ledger.com/hc/en-us/articles/360011069619-Extended-public-key-xPub?docs=true

Electrum and Blue Wallet have the same next Receive address
Sparrow looks different, they start with bc1. It may be because of the current derivation path (m/84'/0'/0') which I've messed with a bit, don't really understand the derivation path but I do understand it's important.

The next address on the Ledger ALSO starts with bc1, and is identical to the one in Sparrow. Neither Sparrow or Ledger find the transaction. Hmm...

I went into Electrum and tried creating a new device, connecting to hardware device, etc. But it says "no hardware device detected" even when the ledger is plugged in.

I will try the xPub scanner tool if I have to, it looks like it's above my head, though.

The title is highly deceptive. Open your Ledger, select Bitcoin app and make in Electrum a new wallet off that
Until then I agree with @nc50lc: the xpub is most probably unrelated to your Ledger addresses.


I would start with same setup, i.e. actual Ledger in Electrum. Then find out how that odd xpub has transactions. Isn't that the right way?

I don't think it's clipboard malware because OP said that the balance is also shown in the Electrum wallet.

What I think is nc50lc might be right that the other wallet like Bluewallet and Ledger Live have different derivation paths.

@OP would you mind to try to use the xPub scanner developed by Ledger it can be used to find the addresses with balances and the right derivation path. You can find the tool from the link below.

- https://github.com/LedgerHQ/xpub-scan

Let's hope that it can find the address generated from Bluewallet where you received BTC with the right derivation path so that you can later use that path to Ledger Live and Sparrow.

Here is the Ledger guide on extracting an xpub - https://support.ledger.com/hc/en-us/articles/360011069619-Extended-public-key-xPub
Did you follow these steps?

If you go back in to Ledger Live and extract the xpub again, does it match the xpub you are importing to all these different wallets?

You say the transaction does not show up in Ledger Live or in Sparrow. Do these wallets show different addresses to Blue and Electrum, or are the addresses the same but just with no transaction?

Did you at any time confirm that the receiving address on Blue Wallet is the same as the one displayed on the screen of your Ledger hardware wallet? Did Blue Wallet and Ledger request such address verification when you generated the receiving address?

I doubt it's a clipboard malware. OP can see the transaction they made in their Blue Wallet. If it was a clipboard malware, the destination address would be something completely unrelated to any of their addresses.

My immediate guess is the copied xpub isn't related to any of your account in Ledger Live.
It can also be something like extended derivation done by Blue wallet to the provided xpub or as simple as different address type.
The worst case scenario is if it's changed from your clipboard by a malware.

As for Electrum, it derives the 'internal chain' and 'external chain' paths after the provided xpub,
for example: your_xpub/0/receiving_address_0+ & your_xpub/1/change_address_0+
In Electrum, the script type for "xpub" is standard P2PKH; in Sparrow, it depends on what you've selected.

Describe how you set-up your Ledger Device, the exact steps including the software used and which part of the client you've exported the xpub.

You can also tell how you imported the xpub to Blue wallet because AFAIK, Blue Wallet follows whatever path where it found any related transactions.
If it didn't find any, it wont let you import the extended master public key.

Hope this provided enough hint before clarifications are provided.

I set up a Ledger device a while back. Then I put the Xpub from the Ledger device on BlueWallet (set up as a Watch Only Wallet). I then used the receive address that I got from BlueWallet to receive some bitcoin.
The transaction showed up in BlueWallet. However, it never showed up in Ledger Live. I imported the Xpub into Electrum, and the transaction DOES show up there.
However, it does NOT show up in Sparrow when I import the xpub.
I'm thinking that somehow the receive address that BlueWallet generated is not one that either Ledger or Sparrow would check. I've tried turning on the "extended account search" in Ledger Live, and also increasing the "custom gap limit" in Ledger Live to what I believe is the max (from 20 to 999), and the transaction still doesn't show up (even after I clear the cache).

Any thoughts?