What is the rationale behind dropping old wallet.dat support exactly?

[takuma sato]

The arguments for the new wallet.dat are clear: descriptors have some easy-of-use features like PSBT, easier to maintain watch-only wallets, no need for wallet.dat backups as you create new addresses and the new fancy signatures.

However, I have not seen a convincing argument that explains how new wallets aren't less safe than old wallets because of how the key derivation works. All the arguments I see are "but you would need to leak your xpub key" or something like that. So what? I still means you need to leak less data to end up a in complete disaster vs having to leak private keys on a key by key basis. They only need to get one seed and they get all future addresses you will ever generate.

Why would anyone reasonable would willingly create such a single point of failure when you can avoid it?

And then on top of it is suddenly some people decide that you are forced to migrate the wallet into the new format (along with the other nice up and coming Core V30 features being discussed). Like who the fuck are those people to force users into managing private keys the way they want to? There's no excuse to not maintain support for legacy wallet.dat for those that do not believe in this nonsense. What they should do is keep support for both formats, and try to improve features for the legacy wallet, because watch-only features could be improved without descriptors.

For people that only need base58 addresses, this seems like yet another excuse to force people into the new VC-backed money tokenfest that comes with V30.
And being forced to make backups is a good think actually. How is a backup that only needs to be stolen once a good feature.

[Satofan44]

However, I have not seen a convincing argument that explains how new wallets aren't less safe than old wallets because of how the key derivation works.

Maybe first you have to provide arguments as to why they would be less safe?

All the arguments I see are "but you would need to leak your xpub key" or something like that. So what? I still means you need to leak less data to end up a in complete disaster vs having to leak private keys on a key by key basis.

Leaking your xpub is the equivalent of publicly publishing all your addresses online. Why would anyone do this? Very few users will do this by mistake, and so what? We can't prevent users from submitting their seed phrase to a website so why would this be any different?

They only need to get one seed and they get all future addresses you will ever generate.

What about it?

Why would anyone reasonable would willingly create such a single point of failure when you can avoid it?

The legacy format comes with many of its own issues, which are a bigger deal than any issues with the new format.

And then on top of it is suddenly some people decide that you are forced to migrate the wallet into the new format (along with the other nice up and coming Core V30 features being discussed). Like who the fuck are those people to force users into managing private keys the way they want to?

Nobody is being forced to do anything. Using Bitcoin Core as a wallet is entirely optional. You can stay with the old version or you can use any other wallet of your liking.

There's no excuse to not maintain support for legacy wallet.dat for those that do not believe in this nonsense. What they should do is keep support for both formats, and try to improve features for the legacy wallet, because watch-only features could be improved without descriptors.

Technological debt, look it up.

For people that only need base58 addresses, this seems like yet another excuse to force people into the new VC-backed money tokenfest that comes with V30.

One has nothing to do with the other.

And being forced to make backups is a good think actually. How is a backup that only needs to be stolen once a good feature.

Every seed phrase backup works the same way, the legacy wallet.dat works the same way. If someone gets access to your recent backup just once, it is game over.

[takuma sato]

However, I have not seen a convincing argument that explains how new wallets aren't less safe than old wallets because of how the key derivation works.

Maybe first you have to provide arguments as to why they would be less safe?

All the arguments I see are "but you would need to leak your xpub key" or something like that. So what? I still means you need to leak less data to end up a in complete disaster vs having to leak private keys on a key by key basis.

Leaking your xpub is the equivalent of publicly publishing all your addresses online. Why would anyone do this? Very few users will do this by mistake, and so what? We can't prevent users from submitting their seed phrase to a website so why would this be any different?

They only need to get one seed and they get all future addresses you will ever generate.

What about it?

Why would anyone reasonable would willingly create such a single point of failure when you can avoid it?

The legacy format comes with many of its own issues, which are a bigger deal than any issues with the new format.

And then on top of it is suddenly some people decide that you are forced to migrate the wallet into the new format (along with the other nice up and coming Core V30 features being discussed). Like who the fuck are those people to force users into managing private keys the way they want to?

Nobody is being forced to do anything. Using Bitcoin Core as a wallet is entirely optional. You can stay with the old version or you can use any other wallet of your liking.

There's no excuse to not maintain support for legacy wallet.dat for those that do not believe in this nonsense. What they should do is keep support for both formats, and try to improve features for the legacy wallet, because watch-only features could be improved without descriptors.

Technological debt, look it up.

For people that only need base58 addresses, this seems like yet another excuse to force people into the new VC-backed money tokenfest that comes with V30.

One has nothing to do with the other.

And being forced to make backups is a good think actually. How is a backup that only needs to be stolen once a good feature.

Every seed phrase backup works the same way, the legacy wallet.dat works the same way. If someone gets access to your recent backup just once, it is game over.

The number of bits that need to be obtained by an attacker is always smaller with legacy wallets vs HD wallets, nothing of what you have provided disproves this fact.

[Satofan44]

The number of bits that need to be obtained by an attacker is always smaller with legacy wallets vs HD wallets, nothing of what you have provided disproves this fact.

You are confusing things. The things are as equal as they come.

• Complete compromise: Legacy wallet.dat file or seed phrase from HD wallet.
• Partial compromise: One private key from legacy wallet or 1 private key from HD wallet.

In the case of partial compromise you can't do anything more than empty 1 address with that. Even if your xpub is exposed, if hardened derivation is used there is no danger.
If you are thinking of random guessing attack on the seed phrase then sure you need to guess much fewer bits to steal the whole wallet when compared to the legacy method. What about it? This is not a valid concern. If you believe you are smarter than statisticians and you feel like this is something to worry about, just use 1 HD wallet per address. Generate any number of wallets that you need. Problem solved.

The whole cryptocurrency environment pretty much uses HD wallets, but sure Bitcoin Core adding it is the problem. 

[takuma sato]

The number of bits that need to be obtained by an attacker is always smaller with legacy wallets vs HD wallets, nothing of what you have provided disproves this fact.

You are confusing things. The things are as equal as they come.

• Complete compromise: Legacy wallet.dat file or seed phrase from HD wallet.
• Partial compromise: One private key from legacy wallet or 1 private key from HD wallet.

In the case of partial compromise you can't do anything more than empty 1 address with that. Even if your xpub is exposed, if hardened derivation is used there is no danger.
If you are thinking of random guessing attack on the seed phrase then sure you need to guess much fewer bits to steal the whole wallet when compared to the legacy method. What about it? This is not a valid concern. If you believe you are smarter than statisticians and you feel like this is something to worry about, just use 1 HD wallet per address. Generate any number of wallets that you need. Problem solved.

Managing keys with the old wallet.dat format for those that do not feel safe with HD wallets (because the math checks in like it or not) is obviously a much more manageable method than having to create a wallet.dat per address.

The whole cryptocurrency environment pretty much uses HD wallets, but sure Bitcoin Core adding it is the problem.  

The whole crypto industry is a scam, just look around. Hardware wallets, SVPs, pruned nodes, shitcoiners spamming the blockchain. Everything about the crypto industry is built to make fiat, not to harden BTC holdings, most people run software on Windows with NSAware on their BIOS. It's all a big joke.

[Satofan44]

Managing keys with the old wallet.dat format for those that do not feel safe with HD wallets (because the math checks in like it or not) is obviously a much more manageable method than having to create a wallet.dat per address.

I didn't say that it is a good solution, I said that it is one.   You have many options and nobody is forcing you to do anything. You can write your own wallet as the last resort.

The whole cryptocurrency environment pretty much uses HD wallets, but sure Bitcoin Core adding it is the problem.  

The whole crypto industry is retarded, just look around. Hardware wallets, SVPs, pruned nodes, shitcoiners spamming the blockchain. Everything about the crypto industry is a scam, most people run software on Windows with NSAware on their BIOS. It's all a big joke.

If you really believe that then you should leave the space instead of whining here for almost every single thing that is changed.

[takuma sato]

Managing keys with the old wallet.dat format for those that do not feel safe with HD wallets (because the math checks in like it or not) is obviously a much more manageable method than having to create a wallet.dat per address.

I didn't say that it is a good solution, I said that it is one.   You have many options and nobody is forcing you to do anything. You can write your own wallet as the last resort.

The whole cryptocurrency environment pretty much uses HD wallets, but sure Bitcoin Core adding it is the problem.  

The whole crypto industry is retarded, just look around. Hardware wallets, SVPs, pruned nodes, shitcoiners spamming the blockchain. Everything about the crypto industry is a scam, most people run software on Windows with NSAware on their BIOS. It's all a big joke.

If you really believe that then you should leave the space instead of whining here for almost every single thing that is changed.

Why would I do that? Im just asking why is Core forcing users into this, no clear answers yet.

"Technological debt, look it up."

This is as close of an answer I've seen here. So what's next, drop base58 support?

Looks like Knots will probably continue to support legacy wallets, so I will be using that. They allow you to create non descriptor wallets on version 29 which in Core they do not, so it points on that direction. They should give users options, and users should choose the tradeoffs, that's all. But that is obviously against Core's ethos, just look at v30.

[Satofan44]

Why would I do that? Im just asking why is Core forcing users into this, no clear answers yet.

"Technological debt, look it up."

Yes, that is the main answer to these things. Who is going to maintain that codebase? Are you? If not, then don't complain. The arguments in favor of HD wallets can be found in the original BIP or any discussion relating to HD wallets since.

Looks like Knots will probably continue to support legacy wallets, so I will be using that. They allow you to create non descriptor wallets on version 29 which in Core they do not, so it points on that direction. They should give users options, and users should choose the tradeoffs, that's all. But that is obviously against Core's ethos, just look at v30.

No. Keeping all kinds of options incurs severe technological debt. The Core policy is always to try to reduce debt and dependencies.

[achow101]

Legacy wallets are being deprecated because Berkeley DB is a 12 year old unmaintained database that we have had to have multiple exceptions in various CI for because it constantly fails a number of safety checks that are implemented for the rest of the codebase and dependencies.

Furthermore, legacy wallets actually have a lot of weird behavior that is both confusing to users and developers. There were an incredible number of insane edge cases (edge cases that are unlikely for users to hit, but were there nonetheless) that made it difficult to maintain. It has a bunch of complicated logic that makes determining and analyzing the behavior to be extremely difficult.

You also seem to be conflating Descriptor wallets with HD wallets. Legacy wallets could also be HD wallets, and they have been the default for new wallets since 0.13.0. The ability to create non-HD wallets was removed in 0.16.

Descriptor wallets are much more than using BIP 32. They are significantly simpler in operation. They make it possible to actually do complex scripts. They simplify the watch-only wallet workflow. They make it possible to actually analyze and determine the wallet's behavior. They significantly reduce technical debt.

The architecture of Descriptor Wallets is also such that they are much easier to make improvements. There are number of things that the Bitcoin Core wallet could actually be doing which various Legacy Wallet behavior gets in the way of. By switching completely to Descriptor Wallets, it allows the wallet to actually have these improvements.

Lastly, you could say that Legacy wallets could be maintained in parallel instead of being removed. However, no one is interested in continuing to maintain it. It gets harder and harder to maintain as other dependencies change (glibc, c++ standard itself, etc.). It gets harder to maintain as the people who worked on it become less interested in the project. Fundamentally, that means it becomes even more technical debt, and it has an increasing possibility of having vulnerabilities which risk people's funds, both in Legacy Wallets, and in Descriptor Wallets. Such vulnerabilities could even impact consensus given the monolithic nature of the Bitcoin Core. Fundamentally, we should not be shipping code that is no longer being maintained, and that is ultimately the reason that Legacy wallets are being removed.

[ertil]

So what's next, drop base58 support?

That would be good, because base58 is never enforced by consensus. If you write everything in base16, then it would work as well, if not better.

For example: instead of 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, you can use 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d93. It is equivalent. And there is no a single place in the protocol, where people would ever be forced to use base58.

Edit: More than that: Nobody forces you to use 32-bit checksum. You can use 256-bit checksum as well:

Code:

SHA-256(SHA-256(0062e907b15cbf27d5425399ebf6f0fb50ebb88f18))=c29b7d937e3049e279391e62fdf00c12def7444013ddf6215808d10e9f2d5996

And then, instead of writing 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d93, you can use the full version, and write 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d937e3049e279391e62fdf00c12def74 44013ddf6215808d10e9f2d5996. Nobody will stop you.

So, when it comes to wallets, you can use anything you want.

[takuma sato]

So what's next, drop base58 support?

That would be good, because base58 is never enforced by consensus. If you write everything in base16, then it would work as well, if not better.

For example: instead of 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa, you can use 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d93. It is equivalent. And there is no a single place in the protocol, where people would ever be forced to use base58.

Edit: More than that: Nobody forces you to use 32-bit checksum. You can use 256-bit checksum as well:

Code:

SHA-256(SHA-256(0062e907b15cbf27d5425399ebf6f0fb50ebb88f18))=c29b7d937e3049e279391e62fdf00c12def7444013ddf6215808d10e9f2d5996

And then, instead of writing 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d93, you can use the full version, and write 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18c29b7d937e3049e279391e62fdf00c12def74 44013ddf6215808d10e9f2d5996. Nobody will stop you.

So, when it comes to wallets, you can use anything you want.

No, it obviously wouldn't be good to drop base58 support, im not even going into that. In fact, all of this nonsense started since segwit was introduced, which opened the can of worms we have now. Bitcoin shouldn't have anything but base58 addresses that begin with an 1. At least a proper node can ignore these.

As far as HD wallets, the fact that an attacker needs less bits to steal all funds vs a non-HD wallet has not been disputed, and this defeats any ease of use cases of HD wallets over non-HD wallets, for also obvious reasons.

Non-HD wallets barely need any maintenance, just let the software load the keys, it's just a collection of private keys sitting on an airgap computer, no excuse to not support it.

[ertil]

Bitcoin shouldn't have anything but base58 addresses that begin with an 1.

Then tell me, should it have P2PK? Because in the Genesis Block, and in many blocks after it, coins were sent to public keys, not addresses.

the fact that an attacker needs less bits to steal all funds vs a non-HD wallet has not been disputed

Of course, because every HD wallet is in practice a single key, that is expanded in deterministic way. And if you somehow break that key, then you will access everything. But good luck with that. The famous puzzle from transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 also used HD wallet.

And more than that: public keys from 161-bit to 256-bit range were revealed. Many private keys with lower ranges, up to 70-bit, are known. So what? Over 900 BTC is waiting for you, so just break a single key, and grab them all. Hmm, you don't know how? Well, maybe because it is not so easy, to compromise a HD wallet. So, don't worry too much about HD wallet security. This challenge can prove you, that HD wallets can be safe, otherwise you would sweep all of that instantly, if you would know some weakness.

no excuse to not support it

But they are supported. You can have a descriptor wallet, and load each and every key from WIF manually. So, what exactly is your problem?

Edit: For example, let's assume that you are purist, who wants to use only compressed P2PK with descriptor wallet:

Code:

createwallet "" false true
{
  "name": ""
}
listdescriptors true
{
  "wallet_name": "",
  "descriptors": [
  ]
}
getdescriptorinfo "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)"
{
  "descriptor": "pk(0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798)#gn28ywm7",
  "checksum": "c6fur0yd",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": true
}
importdescriptors '[{"desc":"pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd","timestamp":"now","label":"one"}]'
[
  {
    "success": true
  }
]
listdescriptors true
{
  "wallet_name": "",
  "descriptors": [
    {
      "desc": "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd",
      "timestamp": 1231006505,
      "active": false
    }
  ]
}

See? It works. If you replace "pk" with "pkh", then you will get your favourite addresses, starting with one. So, just migrate your old wallet, and enjoy it. And you can still use the old wallet, if you want to. Nobody would stop you. Or you can call "createwallet" manually each time, when you want to get a new address. It is up to you.

[Satofan44]

Non-HD wallets barely need any maintenance, just let the software load the keys, it's just a collection of private keys sitting on an airgap computer, no excuse to not support it.

Enough. This is not true, stop repeating lies. If you believe it is easy to maintain it in the Bitcoin Core code base, go and YOU do it.

[ABCbits]

No, it obviously wouldn't be good to drop base58 support, im not even going into that. In fact, all of this nonsense started since segwit was introduced, which opened the can of worms we have now. Bitcoin shouldn't have anything but base58 addresses that begin with an 1. At least a proper node can ignore these.

Does anyone remember issue of transaction malleability and quadratic sighash before SegWit exist?

Non-HD wallets barely need any maintenance, just let the software load the keys, it's just a collection of private keys sitting on an airgap computer, no excuse to not support it.

Enough. This is not true, stop repeating lies. If you believe it is easy to maintain it in the Bitcoin Core code base, go and YOU do it.

At this point, i would point OP and other reader to this article. I'll snip most important section.

Some people who use open source software think or feel that they somehow have a right upon the developers of such software to provide support or service of some kind. Some are even so deluded that they think threating the developers with promises of not using the software will somehow force the developers into compliance.

[ertil]

Does anyone remember issue of transaction malleability and quadratic sighash before SegWit exist?

Yeah, and it is still present, because you can still use legacy addresses. It could be fully eliminated, if legacy addresses would be obsolete, would be fully unsafe, and as easy to move as OP_TRUE is, and then, they could be made non-standard (not "invalid", because of the past timelocked transactions; as long as there are any legacy UTXOs, they cannot be fully invalidated).

[takuma sato]

Bitcoin shouldn't have anything but base58 addresses that begin with an 1.

Then tell me, should it have P2PK? Because in the Genesis Block, and in many blocks after it, coins were sent to public keys, not addresses.

the fact that an attacker needs less bits to steal all funds vs a non-HD wallet has not been disputed

Of course, because every HD wallet is in practice a single key, that is expanded in deterministic way. And if you somehow break that key, then you will access everything. But good luck with that. The famous puzzle from transaction 08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15 also used HD wallet.

And more than that: public keys from 161-bit to 256-bit range were revealed. Many private keys with lower ranges, up to 70-bit, are known. So what? Over 900 BTC is waiting for you, so just break a single key, and grab them all. Hmm, you don't know how? Well, maybe because it is not so easy, to compromise a HD wallet. So, don't worry too much about HD wallet security. This challenge can prove you, that HD wallets can be safe, otherwise you would sweep all of that instantly, if you would know some weakness.

no excuse to not support it

But they are supported. You can have a descriptor wallet, and load each and every key from WIF manually. So, what exactly is your problem?

Edit: For example, let's assume that you are purist, who wants to use only compressed P2PK with descriptor wallet:

Code:

createwallet "" false true
{
  "name": ""
}
listdescriptors true
{
  "wallet_name": "",
  "descriptors": [
  ]
}
getdescriptorinfo "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)"
{
  "descriptor": "pk(0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798)#gn28ywm7",
  "checksum": "c6fur0yd",
  "isrange": false,
  "issolvable": true,
  "hasprivatekeys": true
}
importdescriptors '[{"desc":"pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd","timestamp":"now","label":"one"}]'
[
  {
    "success": true
  }
]
listdescriptors true
{
  "wallet_name": "",
  "descriptors": [
    {
      "desc": "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd",
      "timestamp": 1231006505,
      "active": false
    }
  ]
}

See? It works. If you replace "pk" with "pkh", then you will get your favourite addresses, starting with one. So, just migrate your old wallet, and enjoy it. And you can still use the old wallet, if you want to. Nobody would stop you. Or you can call "createwallet" manually each time, when you want to get a new address. It is up to you.

P2PKH is the safer available option. When it comes to P2SH/P2WSH, the problem is the potential anyonecanspend attack vector. If after reading about that you are still okay with it, then keep using addresses that do not begin with 1, but forcing this unto everyone else is a mistake.

Similarly, if you are ok with having a single point of failure were a single seed compromises all your existing and future addresses, then go for it, but do not force this unto others.

Migrating the wallet with the migration tool. But this will convert the wallet from non-HD to HD. I don't know what happens to existing keys. I assume the existing keys are not part of the new seed, so they wouldn't be exposed to this single point of failure risk, but any future keys will be derived from the new assigned hdseed key. Descriptors per se are not the problem, but the single point of failure that is hdseed. It is not possible to create a non-HD wallet with current Core software as far as I know. They are also disabling or going to disable importing and exporting private keys "to protect users". So you are basically forced to use the migration tool, which means your wallet is an HD-wallet. If you create a blank wallet, you cannot generate new addressess since it has no hdseed, and if you cannot import and export private keys separately from your old wallet, then im not sure what you are suggesting there.

Having the keys isolated with each having it's own private keys is better. This makes it more cumbersome to deal with it, so what. Having to use some old computer to avoid Intel's/AMD spyware is also more cumbersome, but that is the only option we have. 99% don't do this, and this is part of the problem. HD wallets may be more handy, but introduce risks, same thing. Because Intel and AMD make it hell to flash their BIOS', you are forced to use older computers. Now Core wants to do the same with this or force people to relay spam. The conclusion is that one must run Knots to at least have the options to choose what to do with your keys and what is relayed by your node. None of this breaks consensus, so it should be up to the user, not to some so called developers which kick opposition, that isn't even trying to hardfork the network as others attempted.

[Satofan44]

\Now Core wants to do the same with this or force people to relay spam. The conclusion is that one must run Knots to at least have the options to choose what to do with your keys and what is relayed by your node. None of this breaks consensus, so it should be up to the user, not to some so called developers which kick opposition, that isn't even trying to hardfork the network as others attempted.

Then just run Knots and shut up. The ship has sailed for Bitcoin Core on the topic of HD wallets. Nothing and nobody will get them to go back to the legacy format. Accept the reality. They won't do something just because a tiny minority of which you are a part of may want something.

[takuma sato]

\Now Core wants to do the same with this or force people to relay spam. The conclusion is that one must run Knots to at least have the options to choose what to do with your keys and what is relayed by your node. None of this breaks consensus, so it should be up to the user, not to some so called developers which kick opposition, that isn't even trying to hardfork the network as others attempted.

Then just run Knots and shut up. The ship has sailed for Bitcoin Core on the topic of HD wallets. Nothing and nobody will get them to go back to the legacy format. Accept the reality. They won't do something just because a tiny minority of which you are a part of may want something.

Exactly, nothing must be done about spyware on hardware because only a tiny minority uses open source BIOS on their computers.

[ertil]

When it comes to P2SH/P2WSH, the problem is the potential anyonecanspend attack vector.

It is very unlikely, that any soft-fork will be "reverted". All Segwit nodes will mark such block as "invalid", if coins will be moved without any signatures. Also, if breaking rules would be so easy, then what about P2PK? You can also use "anyonecanspend attack vector" here, and move any coins anywhere, without any signatures. Because if you would have a client, which would allow always spending any coins, then it would be compatible with the current chain. You can start a node, disable the whole Script, make all coins spendable, and you will sync it to the chain tip, without any problems.

More than that: what about "Value Overflow Incident attack vector"? Because that fix was also a soft-fork. You can have a client, which would allow producing coins out of thin air, and it will also successfully sync the whole chain, up to the current chain tip. Are you still worried, that this fix will also be "reverted"?

but forcing this unto everyone else is a mistake

Why? If soft-forks could be easily "reverted", then any rules could be "lifted", by using exactly the same attack vector. For example: what about 21 million coins limit? If you would have a client, where there would be no halvings, and the basic block reward would be set to 50 coins forever, then guess what: it would sync the whole chain without any problems. Because the reward, claimed by miner, can be always smaller. It cannot be bigger, but coins can be burned, and miners could always decide to burn all new coins and fees in the coinbase transaction. So, a node, which would enforce no halvings, would land on the same chain, just because hashrate majority enforces "soft-forked halvings".

a single point of failure were a single seed compromises all your existing and future addresses

Then, demonstrate me a practical attack on some HD wallet. Show me, how to get 900 BTC from the puzzle.

But this will convert the wallet from non-HD to HD.

Wrong. If you make an empty wallet, then it is empty. It contains only keys, which you manually import. If there are no descriptors, which automatically can be used to make new addresses, then if you try to make a new address, it won't work. For example:

Code:

createwallet "" false true
{
  "name": ""
}
listdescriptors
{
  "wallet_name": "",
  "descriptors": [
  ]
}
getnewaddress
Error: This wallet has no available keys (code -4)
importdescriptors '[{"desc":"pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd","timestamp":"now","label":"one"}]'
[
  {
    "success": true
  }
]
getnewaddress
Error: This wallet has no available keys (code -4)
listdescriptors true
{
  "wallet_name": "",
  "descriptors": [
    {
      "desc": "pk(KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn)#c6fur0yd",
      "timestamp": 1231006505,
      "active": false
    }
  ]
}
getnewaddress
Error: This wallet has no available keys (code -4)

See? Commands like "getnewaddress" can work, if the wallet knows, how to make a new address. But if it doesn't, then it only stores the things you put there, without adding anything new.

I don't know what happens to existing keys.

Existing keys are imported, so you can see them in "listdescriptors". But if there are just single keys or addresses, then the wallet does not know, how to make new addresses, so you will have to decide about it manually, generate new keys manually, import them manually, and decide, how they should be handled.

but any future keys will be derived from the new assigned hdseed key

If you start from an empty wallet, then there are no seeds. You don't have to use public keys in a descriptor wallet. You can even use keyless puzzles, if you want to.

It is not possible to create a non-HD wallet with current Core software as far as I know.

Empty wallet is a non-HD wallet. No new addresses are automatically generated in a deterministic way, if you don't let the wallet know, how to do that.

They are also disabling or going to disable importing and exporting private keys "to protect users".

If you use "listdescriptors true", then you can dump the content on a paper, and later import it through "importdescriptors". And you can have only WIF keys, without any HD keys, if you want to. Or even keyless addresses, if you need them.

and if you cannot import and export private keys separately from your old wallet, then im not sure what you are suggesting there

You can do that, key-by-key, from WIF. What else do you need?

Edit: By the way, there is also BIP-42, which made the supply finite. So, are you worried, that there will be more than 21 million coins in circulation, when after 64 halvings, miners would start producing 50 coins again? Because I am pretty sure, that if anyone would try it, then it would be an altcoin.

Edit: Meanwhile in Bitcoin Knots:

Code:

createwallet
createwallet "wallet_name" ( disable_private_keys blank "passphrase" avoid_reuse descriptors load_on_startup external_signer )

Creates and loads a new wallet.

Arguments:
...
6. descriptors             (boolean, optional, default=true) Create a native descriptor wallet. The wallet will use descriptors internally to handle address creation. Setting to "false" will create a legacy wallet
...

So, if your favourite Knots uses descriptors by default, and if it creates HD wallets by default, then what exactly are you using? Because I guess you always called "getnewaddress", without being aware, that you have a HD wallet. You can use "dumpwallet", and read the text file, that will be produced. I bet you will see some HD seed in it, instead of a long list of WIF keys, without any "master private key".

[Mia Chloe]

The whole idea of a descriptor wallet is more like you're trading a bit of granular key by key security for a bigger leap in convenience and a way to protect against the more common ways people lose their coins like a wallet backup that's missing half the keys or just plain forgetting what you've got.

I think the core argument isn't actually that an XPUB is safer to leak than a private key, but that it's much easier for a normal person to secure one thing (their seed phrase) than to constantly manage and back up a bunch of individual keys and kinda reduce problems too and that means moving away from a legacy system that was always more difficult to maintain.