pull down to refresh
Right, so you're saying that, when doing a re-hashed commitment to a pubkey in a "hashed addresses" commitment, and then a reveal, and you make sure you give a quarter of your stash to a miner so that it is not worth reverse-engineering the signature come reveal time and wait another 1440 or so blocks for the full stash, then p2(w)pkh and taproot are potentially clean as well as anything that has a hash in a key derivation path, and then the only question is: whether or not to confiscate p2pk?
If we're willing to make users wait 1440 blocks between commit and reveal, they'd only need to sacrifice (a bit more than) one 1440th (i.e. ~0.07%) of their rescued coins to incentivize miners. One quarter would be drastic overkill. See the "Parameters" section of the article for the math.
To clarify, the miners aren't "reverse-engineering" anything in a censorship attack - they're just blocking the authentic reveal TX from being mined, for long enough that their own malicious commitment can mature, allowing them to mine their own (malicious) reveal TX.
The happy path would look roughly like this:
- Your wallet sends an opaque commitment hash to an aggregator server (e.g. via an API call)
- The aggregator combines that hash with hundreds or thousands of others
- A few minutes later the aggregated commitment is mined
- a long time (e.g. 1440 blocks) later, you reopen your wallet and your funds are ready to rescue. Your wallet sweeps them into your primary account with a reveal transaction, paying 0.08% of their value as a fee to incentivize miners.
- now your coins are all on PQ-secure addresses.
then p2(w)pkh and taproot are potentially clean as well as anything that has a hash in a key derivation path, and then the only question is: whether or not to confiscate p2pk?
In theory yes. I have never heard of any knowledge asymmetries for P2PK wallets, so DropKick deployment has no utility or impact on those coins.
That's not correct. If a rescue protocol were deployed to allow rescue via only decidable knowledge asymmetries (hashed addresses, taproot) then none of those coins you cite would be confiscated. As Tadge said recently at Bitcoin++, "who doesn't know their public keys?".
Confiscation only occurs if we encumber coins with undecidable KA's, such as BIP32 derivation, where it's impossible to tell at-a-glance which addresses were generated via BIP32 and which weren't.
DropKick generalizes to any KA, so it can be deployed with or without confiscatory side-effects, depending on whether the future community puts more value on (1) rescuing the most coins from the QC, in which case use all the KAs, or (2) preventing all confiscation, in which case use only decidable KAs.