[RFC] Stop automatically creating legacy and p2sh-segwit descriptors

achow101 commented at 11:09 pm on December 20, 2021: member

As we see segwit and taproot usage grow, it seems reasonable to stop making wallets that are able to generate legacy and p2sh-segwit addresses. We have already made it difficult to make legacy addresses through the GUI (starting with -addresstype=legacy is the only way). The default address type is bech32. So it seems that we should consider stop automatically generating legacy, and probably p2sh-segwit, descriptors.

This would simply be removing the automatic creation of descriptors for the LEGACY and P2SH_SEGWIT output types for new wallets. We would still retain the ability to spend those outputs, parse those descriptors, and make those types of addresses if the user’s wallet has descriptors for these output types. Additionally, if a user wanted to add such a descriptor to their wallet, they could via importdescriptors. There can also be some RPC which can add an automatically generated single key descriptor of whatever type that could legacy and p2sh-segwit descriptors to the wallet. Such an RPC would be the generic version of the one that will add tr descriptors (or perhaps the same RPC).

achow101 added the label Feature on Dec 20, 2021

achow101 added the label Wallet on Dec 20, 2021

maflcko commented at 12:12 pm on December 21, 2021: member

I think it would be nice to have an RPC to fill a blank descriptor wallet with specific descriptor types instead of the all-or-blank approach right now.

Haven’t thought a lot about not providing legacy/p2sh by default for non-blank wallets, but there are still some places that refuse to upgrade and can only support payout to base58 addresses.

maflcko added the label Brainstorming on Dec 21, 2021

Sjors commented at 4:19 pm on January 6, 2022: member

At minimum there should be a way to add them manually, e.g. with #22341 and (the import part of) #23544.

Dropping LEGACY by default would be fine with me, if e.g. we do generate them when started with -addresstype=legacy. Dropping P2SH_SEGWIT seems premature.

But I don’t know if there’s much added value to dropping 1 out of 4 descriptors. If performance if the main concern, then let’s just make the default key pool smaller.

Rspigler commented at 1:59 am on January 7, 2022: contributor

I agree with removing legacy by default (and argued for that here, but the legacy address option was added back to the GUI in this PR: https://github.com/bitcoin-core/gui/pull/459.

According to https://en.bitcoin.it/wiki/Bech32_adoption almost everyone can now send to Bech32. Doing this will probably help with the last stragglers.

sa-tyam commented at 1:55 pm on February 15, 2022: none

Hello @achow101 and others. I am Satyam, 3rd year Computer Science and Engineering student at NIT Hamirpur, India. I have good experience of working with C++ as my project in Google Summer of Code 2021 was totally based on C++. I also have good experience of python development. As the skillset required for the project Remove Automatic Creation of Legacy Descriptors matches mine, I am very much eager to participate in the Summer of Bitcoin working on this project.

As per the competency test, I shall build the project and let you know soon. It will really help me a lot if you could let me know of any prerequisites or any other instructions important for the project.

Looking forward to a great summer ahead.

sudonims commented at 6:26 pm on March 15, 2022: none

@MarcoFalke ,

Haven’t thought a lot about not providing legacy/p2sh by default for non-blank wallets, but there are still some places that refuse to upgrade and can only support payout to base58 addresses.

I’m not completely understanding the mechanism but I’m guessing if descriptor A is not in the wallet then we can’t send btc to other wallets using descriptor A… If that’s the case, we can ask users to import descriptor. Now that one of the Summer of Bitcoin project works on implementation of GUI for “import RPCs”, it should become easy for users to import descriptors…

Rspigler commented at 9:29 pm on August 18, 2022: contributor

I agree with removing legacy by default (and argued for that https://github.com/bitcoin-core/gui/pull/459#issuecomment-961328134, but the legacy address option was added back to the GUI in this PR: https://github.com/bitcoin-core/gui/pull/459.

According to https://en.bitcoin.it/wiki/Bech32_adoption almost everyone can now send to Bech32. Doing this will probably help with the last stragglers.

Sjors commented at 2:55 pm on August 22, 2022: member

@Rspigler it’s fairly easy to modify the GUI to only show the relevant address options. It involves a few extra methods on src/wallet/interfaces.cpp that I didn’t feel like adding back then.

murchandamus commented at 9:23 pm on September 15, 2022: contributor

I’d consider it beneficial to further discourage creation of legacy UTXOs with new wallets both because I don’t see a point to wasting block weight and it helping us move past third-party malleable transactions. The only reasons I’d see for receiving legacy outputs from a newly created wallet these days would be to match the change type to a recipient’s output (which hopefully eventually goes away by others not using legacy addresses), and wanting to be able to sign a message that is clearly associated with a specific UTXO (which hopefully gets resolved by some generic message signing standard).

ghost commented at 5:11 pm on September 16, 2022: none

NACK

We dont’t need to be dictators as bitcoin core developers even if we try to, users will try different type of addresses in transactions. Bitcoin Core Wallet is the not the main wallet used for all transactions.

Example:

0Block 754309:
1
2758 transactions
3638 witness tx
4
5120 tx with no witness - 73 have different version and locktime

Are you trying to police what people do with their transactions when segwit and taproot was a soft fork OPTIN?

This will only affect how core wallet works not bitcoin.

achow101 commented at 5:36 pm on September 16, 2022: member

We dont’t need to be dictators as bitcoin core developers even if we try to, users will try different type of addresses in transactions. Bitcoin Core Wallet is the not the main wallet used for all transactions.

Are you trying to police what people do with their transactions when segwit and taproot was a soft fork OPTIN?

This will only affect how core wallet works not bitcoin.

I think you misunderstand the purpose of this suggestion. I’m not trying to force anything onto the network or “be dictators”. I’m not saying that this will affect users who do not use Bitcoin Core. The purpose is to improve the user experience for users of the wallet, and that includes not storing data that will likely never be used, and also making it harder to have to spend more money unintentionally.

Even so, this suggestion does not mean that legacy addresses will be completely unsupported in the wallet. Anyone who has a legacy address descriptor will still be able to make legacy addresses. If you want legacy addresses and the wallet does not have such a descriptor, one can be imported using importdescriptors. After #25907, the process for adding such a descriptor will also become much easier.

ghost commented at 6:00 pm on September 16, 2022: none

We dont’t need to be dictators as bitcoin core developers even if we try to, users will try different type of addresses in transactions. Bitcoin Core Wallet is the not the main wallet used for all transactions. Are you trying to police what people do with their transactions when segwit and taproot was a soft fork OPTIN? This will only affect how core wallet works not bitcoin.

I think you misunderstand the purpose of this suggestion. I’m not trying to force anything onto the network or “be dictators”. I’m not saying that this will affect users who do not use Bitcoin Core. The purpose is to improve the user experience for users of the wallet, and that includes not storing data that will likely never be used, and also making it harder to have to spend more money unintentionally.

Even so, this suggestion does not mean that legacy addresses will be completely unsupported in the wallet. Anyone who has a legacy address descriptor will still be able to make legacy addresses. If you want legacy addresses and the wallet does not have such a descriptor, one can be imported using importdescriptors. After #25907, the process for adding such a descriptor will also become much easier.

I agree with you and sorry for misunderstanding. Go ahead, I already love PSBT created by you however its not easy and we need to look at privacy, security, ui,ux, etc.

luke-jr commented at 9:12 pm on September 16, 2022: member

wasting block weight

Consuming, but not necessarily wasting (a value judgement). Consuming more weight with less actual cost helps keep block sizes down. Block sizes are already harmfully large, so that is good for Bitcoin.

ghost commented at 3:41 am on September 17, 2022: none

wasting block weight

Consuming, but not necessarily wasting (a value judgement). Consuming more weight with less actual cost helps keep block sizes down. Block sizes are already harmfully large, so that is good for Bitcoin.

Looking at the demand for block space space in Bitcoin.. I think we should make legacy address as default.

Rspigler commented at 6:15 pm on September 17, 2022: contributor

This doesn’t make sense to me. If we want to make better use of block space, we should want to take up less space with each transaction? https://bitcoinops.org/en/tools/calc-size/

luke-jr commented at 6:10 am on September 18, 2022: member

Segwit/Taproot transactions do not use significantly less space. They just allow blocks to be larger.

ghost commented at 5:05 pm on September 19, 2022: none

Segwit/Taproot transactions do not use significantly less space. They just allow blocks to be larger.

+1k

ghost commented at 7:15 pm on September 19, 2022: none

What’s wrong with users trying different type of addresses

murchandamus commented at 6:45 pm on September 20, 2022: contributor

Segwit/Taproot transactions do not use significantly less space. They just allow blocks to be larger.

A P2TR input+output are 17% smaller than P2PKH. P2TR inputs have a serialized byte length of 107 B vs 147 or 148 B for P2PKH, and while P2TR outputs are 43 B vs 34 B for P2PKH. So in total 150 B vs 181/182 B. The size reduction is bigger for multisig applications that transition to aggregate key constructions.

luke-jr commented at 7:02 pm on September 20, 2022: member

Not only is that trivial, it’s also “bytes” that don’t have an actual cost. In other words, they’re just additional weight, not actually larger.

murchandamus commented at 7:35 pm on September 20, 2022: contributor

I would have actually expected you to like P2TR. It has significantly less witness data per non-witness data than prior segwit output types.

Either way, asking for bad defaults in software that cause its users to pay more for equivalent outcomes to achieve a global reduction of the overall throughput doesn’t sound like a compelling approach—game theoretically speaking.

aureleoules commented at 6:41 pm on September 22, 2022: member

Just Let us use everything.

You would.

We would still retain the ability to spend those outputs, parse those descriptors, and make those types of addresses if the user’s wallet has descriptors for these output types. Additionally, if a user wanted to add such a descriptor to their wallet, they could via importdescriptors

fanquake commented at 6:48 pm on September 22, 2022: member

bitcoin for users who can can use all type of address based on need not BLOCKSTREAM and CHAINCODELABS telling them what is good/bad

We dont need certificate for address from core developers. Just Let us use everything.

#25600 (comment) (other thread) @1440000bytes Please keep your commentary on topic, and stop with the random accusations / hyperbole. This repository is not the place for it.

ghost commented at 7:26 pm on September 22, 2022: none

bitcoin for users who can can use all type of address based on need not BLOCKSTREAM and CHAINCODELABS telling them what is good/bad

We dont need certificate for address from core developers. Just Let us use everything.

#25600 (comment) (other thread)

@1440000bytes Please keep your commentary on topic, and stop with the random accusations / hyperbole. This repository is not the place for it.

Sorryt. I still think we should have multiple addresses.

ghost commented at 9:38 pm on September 22, 2022: none

I would love to see usage for new addresses likes P2TR but I don’t wan’t want to remove options for all old types in descriptor walllet . This is commentary in an issue but I would do the same thing in an pull request particularly if it affects privacy.

Example: https://github.com/bitcoin/bitcoin/pull/24362

Rspigler commented at 11:25 pm on September 22, 2022: contributor

@1440000bytes This PR wouldn’t effect such a scenario because (emphasis mine).

This would simply be removing the automatic creation of descriptors for the LEGACY and P2SH_SEGWIT output types for /new wallets/. We would still retain the ability to spend those outputs, parse those descriptors, and make those types of addresses if the user’s wallet has descriptors for these output types.

ghost commented at 11:35 pm on September 22, 2022: none

@1440000bytes This PR wouldn’t effect such a scenario because (emphasis mine).

This would simply be removing the automatic creation of descriptors for the LEGACY and P2SH_SEGWIT output types for /new wallets/. We would still retain the ability to spend those outputs, parse those descriptors, and make those types of addresses if the user’s wallet has descriptors for these output types.

This would simply be removing the automatic creation of descriptors for the LEGACY and P2SH_SEGWIT

This is not required. This is what I don’t like and care about the issues so I am commenting. And there is nothing wrong with allowing users to create wallets with all types of descriptors. I do not agree with the opinion that this will help in efficient block usage.

Bitcoin is not an efficient financial network, its censorship resistant network where users should be allowed to do what they want. They could still import descriptors but default matters and affects the way people use core right now.

Sjors commented at 9:15 am on September 23, 2022: member

Another thought: we could lazy-generate the descriptors the first time a user calls getnewaddress, creates a new address in the GUI, etc. Only downside is that this requires the user to unlock their wallet. So we should probably at least create the tr() and wpkh() descriptors during wallet creation.

murchandamus commented at 6:24 pm on March 8, 2024: contributor

Since even Coinbase now seems to be working on sending to bech32m (Coinbase Custody already being able and Coinbase retail app supposedly getting it soon), we are even getting into the territory where we could default to P2TR addresses eventually. Surely that means that we could stop creating legacy and wrapped segwit address descriptors on new wallets by default.

[RFC] Stop automatically creating legacy and p2sh-segwit descriptors #23831