Closed lvella closed 6 years ago
This has been discussed already, e.g. in https://github.com/spesmilo/electrum/issues/3283
Since bech32 is not widely supported
Yes, that is unfortunate.
it makes sense to place on the "receive" screen a button to switch between bech32 and P2SH addresses for the same pubkey.
That would be really confusing to casual users.
Electrum would have to scan for transactions received in both formats.
The project would really not like to do this. Electrum seeds are versioned to not need to do this exact thing.
Would a patch for such a feature be accepted?
I don't think so but it would be @ecdsa's prerogative.
it does not make sense at all to create such a button, because these are technically different output scripts. segwit addresses will eventually be widely supported; it is just a matter of time.
So I believe the Electrum strategy for supporting it is completely wrong. Electrum is a major player in Bitcoin, probably the preferred choice for enthusiasts and power users, and how it helps with the new address adoption probably impact significantly in the whole ecosystem. This is not a suggestion on how to implement it, but how it should be for maximum impact and adoption of the new format:
Supporting the transition phase is a major contribution towards the adoption of the new format.
I say this from the perspective of an old time user: it was a disappointment for me not be able to use my old seed to receive segwit transactions, and even a greater disappointment when creating a new segwit wallet, to be unable to receive from someone else because they didn't support bech32.
@ivella,
You can crate a P2SH-P2WPKH wallet in Electrum if you provide your own BIP39 seed and select m/49'/0'/0' derivation path.
But indeed, you cannot have two address formats in Electrum corresponding to the same private key. I think it is unfortunate because it would have been super convenient but Electrum developers do not like to mix address formats. However, Bitcoin Core is going to have such a functionality, see the prepared pull request.
It doesn't have to be from the same private key, i.e., if it follows a different BIP32 derivation path for each address type, it doesn't matter. What is important for usability is to have access to all types of addresses from the same seed/wallet.
important for usability is to have access to all types of addresses from the same seed
Short term usability, sure. However, there are long term concerns with that.
Let's say 15 years from now, there are now 10 different script types.
Suppose all 10 can be derived from a seed. Do you expect every wallet to implement all of them? Because they would need to. If they don't support the older scripts, then long-time holders will see a balance of zero when they try to restore from seed. I can assure you their main concern will not be that they can use the latest script with their seed. They will blame the software; and the trust in the software - maybe in the currency/system as a whole - will fall. The wallet software will not be able to even tell that the user has coins without implementing at least partial support. This creates a high barrier for developing new wallet software. In any case, this is the bip39/44 approach.
The Electrum approach is to have one script type for one seed. This way the software can right away tell if it has support for a given seed, and if so, guarantee that it will find the coins and be able to spend them.
It is no worse to have an old seed that new software support only partially, than to have an old seed that a new software doesn't support at all.
So, maybe this is how the seed version should be used instead: if a seed version is too old, and the new software lacks support for the older address formats, it should warns the user that the seed may have funds that are not fully supported, and that he might want to use another software or a previous version to transfer funds to a newer seed.
Considering that strategy in today scenario, newly created seeds in Electrum should support bech32 and P2SH-P2WPKH address types, and drop support for P2PKH. Older seeds should provide all types of addresses until the support for P2PKH is officially deprecated, then later removed. Eventually support for P2SH-P2WPKH could be remove, too.
agree with @lvella. Lack of support for p2sh segwit addrs is dis-incentivizing use of segwit. For example, if receiving funds from a customer using coinbase, I wish to provide them a p2sh segwit enabled address, but instead must give a non segwit address, and then send to a separate wallet with bech32, incurring an additional fee at a time when fees are high.
I choose not to do this. So either will use another wallet with p2sh segwit, or iikely will not use segwit at all. Which is at odds with the goal to migrate users to segwit.
just saying.
please complain to coinbase, about that. by not supporting withdrawals to segwit addresses, they are contributing to the current high fees issue.
we do not follow what users want, if what they want is bad for the ecosystem.
Do you think every Electrum user sending their changes to bech32 addresses bad to the ecosystem only because they will have to receive on P2SH addresses?
Isn't that better than they sending changes to and receiving from P2PKH addresses?
mixing script types in the same wallet is a bad idea, because it creates technological debt.
How is that worse than having to support old seed format indefinitely in the future?
As I said previously, if support for pre-segwit seeds is dropped in a future version, the wallet may simply warn the user that this seed may contains unspendable funds from this version on, with a "never show this again" checkbox. Only the supported derivation paths would be used then.
The unavoidable technical debt is there for the time Bitcoin will support spending from P2PKH addresses, which is certainly for its entire future existence.
@ecdsa @SomberNight I wonder how could a user migrate from legacy addresses to SegWit? I've seen wallets using SegWit as change addresses only, which is quite elegant for me. Is that policy bad in you opinion? If so, I wonder why?
mixing script types in the same wallet is a bad idea, because it creates technological debt.
Then could we attach a new SegWit wallet to a old legacy wallet?
Since bech32 is not widely supported, it makes sense to place on the "receive" screen a button to switch between bech32 and P2SH addresses for the same pubkey. Electrum would have to scan for transactions received in both formats.
Would a patch for such a feature be accepted?