Bitcoin Forum

It's first time I use ledger nano s with Electrum wallet. On setup I got asked which address type the wallet should have. I can select legacy (p2pkh), p2sh-segwit (p2wpkh-p2sh) and native segwit (p2wpkh). Which one should I select, or better say, which one is current standard?

I think it is better to choose "p2sh-segwit (p2wpkh-p2sh)" option because you can get less fee compared too legacy and the transaction is much faster than a legacy address.

Legacy address form starts from 1.... and P2sh segwit start from bc1 and for native segwit the address form starts from 3...
Read more about the differences about legacy and segwit addresses from here  Legacy vs Segwit wallets. What's the difference?  (https://bitcointalk.org/index.php?topic=2251039.0)


If you need a guide about Ledger Nano S you can check this review with a guide from here (https://bitcointalk.org/index.php?topic=5038606.0)

You've got that your "bc1" and "3" the wrong way round:

P2PKH are legacy addresses and start with 1. (All addresses which start with 1 are legacy i.e. not segwit.)
P2SH nested segwit addresses (which can be either P2SH(WPKH) or P2SH(WSH)) start with 3. (However, not all addresses which start with 3 are segwit.)
Native segwit addresses (P2WPKH or P2WSH) start with bc1. (All addresses which start with bc1 are segwit.)



This is the best option to pick if you are unsure about which one you want - it allows you to take advantage of lower fees of segwit whilst maintaining compatibility with all services, some of which do not yet support bc1 addresses.

Is the derivation path for native segwit and non native segwith the same or different? I thought people were saying it was different which means you could have both afaik unless electrum does something different? I might be getting confused with another hardware wallet though.

The 'speed' of a transaction (i think you mean the confirmation time ? Or the propagation time ?) doesn't differ, regardless of which type of transaction you build.




Yes, they differ.

Native segwit is m/84'/0/.., where nested segwit is m/49'/0/..



@OP:

Choosing the type fully depends on your needs. Here is a quick summary:

Legacy (P2PKH):
- Pro:

• Compatibility with each online service
• The possibility to extract future forks exists (even tho not that necessary regarding the value of those forks)

- Contra:

• The highest fee of all types
• Transaction malleability (https://bitcointechtalk.com/transaction-malleability-explained-b7e240236fc7?gi=759451239f4d)

Nested Segwit (P2SH nested into P2WPKH):
- Pro:

• Fixes transaction malleability
• Fees lower than legacy, but higher than native segwit (bech32)

- Contra:

• No guaranteed compatibility with future (low quality) forks who don't support segwit

Native Segwit (P2WPKH)
- Pro:

• Fixes transaction malleability
• Lowest fees of all types (up to ~ 40% lower size (and therefore also fees) of the transaction compared to legacy)

- Contra:

• No guaranteed compatibility with future (low quality) forks who don't support segwit
• May not be accepted by older online services which haven't been updated for quite some time, they will show 'invalid address'

Native segwit is definitely becoming a new standard. You should either choose to use bech32 (bc1..) addresses or at least nested segwit (starting with 3...).

I'm pretty sure derivation paths are different for P2WKH / bech32 and P2SH address, and when Ledger add support for SegWit there is only option to create P2SH (which starts with 3) wallets. I am not sure how long Ledger support native SegWit, but it is possible to use it with Electrum and OP post is show that. 

Derivation path for native SegWit is m/84'/0'/0' - for P2SH nested segwit is m/49'/0'/0'.

It is important to know that some exchanges/wallets still do not support bc1 addresses, so user can have problems with send/receive coins:

More info: https://en.bitcoin.it/wiki/Bech32_adoption

+ you are wasting a lot of space on the blockchain with this form of transactions because you have to put a script in place of the signature while moving the signature elsewhere and that script is adding 23 bytes extra to the total transaction size. (you won't notice it because you are paying the fee based on virtual size not the real size)