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

[takuma sato]

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".

All your arguments are "it has not been hacked yet/reverted yet, so it's good to go". Yes, P2PK is less safe long term, that's why people don't use it, and so is segwit, but it's been made mainstream that it is safe. The fact is, you are assuming an increased dependency of miner goodwill compared to P2PKH, and so I will be using P2PKH, you can keep using whatever you want. Extrapolate this to having your entire wallet depending on a seed forever. The problem is when these so called innovations end up screwing up the rest of the users, such as Core 30's VC spamfest.

[ertil]

it has not been hacked yet/reverted yet, so it's good to go

The whole cryptography is built on top of that assumption. Caesar cipher was also great in the past, as well as Enigma was, not that long time ago. And now, we have computers, so these old ciphers are obsolete.

And the same is true with ECDSA: if one randomly generated key is weak, then all of them are, which are based on the same entropy. Which means, that if you have some legacy wallet, then you also have "HD wallet" in practice, just the input to that wallet is more complex, and it has more bits of entropy, than just some 128-bit or 256-bit seed. But still: it is technically possible to target old wallets, by guessing their entropy. It is impractical now, but can be practical in the future.

Because what happens, when you want to get a random key from a legacy wallet? Your device just grabs some entropy from your Operating System, and then it is often hashed through SHA-256, or processed in other similar way, and then, you have a private key out of it. And what happens, when your OS entropy is too low? Well, then your keys are weak. But they are never "random". They are always based on "something". Even if you flip a coin, or roll a dice, then still, it is not a fully "random" input. It has just bigger entropy, than needed, but all of that, is always simplified to a single 256-bit private key, which always have at most 128-bit security, no matter what you use to generate it.

Which means, that HD wallets are not "weaker". They can only capture your "entropy generator" into something manageable. But if you would replace it with an algorithm, which would take things, that are captured by your OS, then guess what: you will get the same private keys! You can always take some old wallet, even with 0.1.0 version, and run it in some environment, where it will always produce the same keys. It is just a matter of your OS entropy.

Also, while in HD wallets, you need that strong entropy only once, in legacy wallets, you need it every time, when you generate a new key. Which means, that if you have a single, strong HD key, then the whole wallet is strong. But if an attacker can compromise your entropy only for a while, then in legacy wallet, some of your keys could be weak. And if you are unlucky, and you will sweep everything to a weak key, then all of that is gone (while in HD wallet, even if your OS entropy would be weak for a moment, then because of deterministic signatures, the client will never ask the system about entropy, once you fill it with a single, strong seed).

I will be using P2PKH, you can keep using whatever you want

If your choice is to pay higher fees, enable transaction malleability, and quadratic hashing, then it is your choice. You will just pay higher fees, for making transactions, which are harder to process. Because huge Segwit transaction can be processed faster, than a huge legacy transaction. We could lift transaction size limit, if the whole content would be hashed only once, no matter what Script would be used. But because of FindAndDelete implementation, it cannot be done.

Fortunately, if you use P2PKH, then your blocks would be at least smaller. But when 160-bit hash collisions will be there, then you will be forced to upgrade to something else anyway (we have chainwork around 2^96 for double SHA-256, collisions in RIPEMD-160 require 2^80 hashes, so they may be practical, if there will be enough incentive).

[ABCbits]

Yes, P2PK is less safe long term, that's why people don't use it

Really? P2PKH have obvious advantage of checksum and shorter length and P2PK mostly used to receive mined Bitcoin in early days.

and so is segwit, but it's been made mainstream that it is safe. The fact is, you are assuming an increased dependency of miner goodwill compared to P2PKH

If you mean anyonecanspend "attack vector", i'll remind you that node of other miner/mining pool consider block that contain such as TX as invalid.

Extrapolate this to having your entire wallet depending on a seed forever.

Details of generating seed/HD wallet is publicly available and many wallet support it these days, so it's not as bad as you imply.