pull down to refresh
Any proposal that asks for additional proof post Q-day, no matter which flavor, will always confiscate every coin in such a wallet.
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.
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.
Thanks for explaining commit/reveal. It's a powerful scheme.
Generic comment, not personal (I know that this is what you meant with "controversial" and that you acknowledge this in your bottom "drawbacks" item.):
Any wallet created with Bitcoin Core version < 0.13.0 (2016) will have a random() sourced keypool. Can still be p2pkh, single use, and secure against everything but in-mempool / reorg-driven replacement by a quantum attacker. Any proposal that asks for additional proof post Q-day, no matter which flavor, will always confiscate every coin in such a wallet.
What is needed to make people come to their senses and not propose confiscation, ever? If there is insufficient disincentive to proposing it, then maybe this disincentive must be created, but it would be much better to for once not walk the same path of toxicity and just collaborate to enable decision making, rather than making them for people as if Bitcoin is a nanny state.