it has taken time but "removal" of legacy p2pkh has progressed pretty steadily over the years, most exchanges don't use them anymore now, a little but it's becoming less common. they still work but it's not advisable because crafting a signature on them is trivial compared to compute available.

the same thing can be done with segwit. you just need a p2spkh - what should have been done in the first place, a bip-340 x-only schnorr pubkey, hashed with sha256, with 64 byte signatures - just like taproot, except without the tweak bullshit. that is your monetary payment address type and transaction type. it does not reveal the pubkey until spend, unlike taproot. everything else is much the same. the difference is that a taproot "address" is actually a pubkey, and that's vulnerable to shor's algorithm using a quantum computer.

so, in summary, p2spkh:

- requires reversing a sha256 hash (not enabled by quantum computer)
- is a simple monetary transaction - just like p2pkh and segwit addreses

why is that not already there? go read up on the blocksize war history. this was why they didn't do it then, and is irrelevant now because here we are chatting on a protocol that uses these exact signatures for authentication and tamper resistance:

1. complexity risk - schnorr signatures required a new signature algorithm, new key aggregation schemes (musig wasn't finalized), and changes to the consensus rules. segwit was already a massive change. adding schnorr on top was seen as too much risk for one upgrade.

2. patent concerns - schnorr signatures were under patent by certicom (blackberry) until 2008 for ECDSA, but there were concerns about other patents covering specific implementations or optimizations. the community was paranoid about patent traps after the whole RSA/ECC patent saga.

3. deployment order - the argument was: deploy segwit first to fix transaction malleability (needed for lightning), then add schnorr later as a separate upgrade. this became the "segwit first, schnorr later" consensus that eventually led to taproot bundling schnorr + taproot together.

4. not a priority - the immediate crisis was block space and malleability. schnorr was seen as a nice-to-have optimization (smaller signatures, key aggregation) but not critical for the network's survival. segwit was the fire that needed putting out.

5. implementation readiness - bitcoin core didn't have a production-ready schnorr implementation in 2017. the BIP for schnorr (BIP340) wasn't finalized until 2020. pushing it into the segwit UASF would have delayed everything.

point 5 is irrelevant. peter wuille's implementation is insanely fast.

point 4 is stupid, the malleability problem is solved by schnorr

point 3 is stupid, because segwit and schnorr both solve the issues needed for long lasting lightning channels that aren't vulnerable to malleability.

point 2 is long dead

point 1 was stupid because they already pre-assumed that segwit would win (interesting, no?)

taproot complicates things. to explain what taproot means:

you have a secret key

you have to add a tweak (or nothing) and hash the concatenation of the tweak with the secret

then you have the actual secret that applies to the spending right for that address

the taproot transaction you have to put the pubkey in the open at the end of the transaction, after the signature on the in-point and amount, in the same place that you have the ripemd160 hashed pubkey (address) in a segwit or legacy monetary transaction (monetary as in coin, moneta = coin).

the threat of shor's algorithm that depends on quantum computers to reverse pubkeys to secret keys, was already known very well at the time they proposed taproot.

hiding the secret key is irrelevant to the problem that having the public key visible to the world means the clock starts at the point that transaction hits the mempool, for a quantum computer attack on that pubkey

the protocol requires a hash on the secret in the first place, why do it first when the actual security comes from doing it last

so taproot was basically "oh, here's your non-malleable signature, but we are going to expose it even though we know that means in 10-20 years someone can crack it in the time you receive it to when you spend it.

what's more important is the fucking hash on the taproot transaction. not a fucking naked pubkey. that's my issue here.

since they rammed through taproot and never considered that hashing the secret does not have anything to do with the spending conditions of the utxo, it is completely a distraction to say "oh we hashed the secret" no, you have to HASH THE FUCKING PUBKEY to secure it against quantum computers.

this is so elementary that the ethereums are laughing at bitcoin. and probably, the funders of ethereum are involved. that means, jp morgan, a bankster organisation.

that people are not alarmed about the situation and don't realise what a fraud taproot is, is ridiculous.

yeah, taproot is a great idea. one secret, multiple independent addresses derived out of it.

but that's also what hierarchic derivative keychains are. really, that's exactly what they are.

but hd keys on segwit are no more quantum resistant than taproot naked pubkeys.