[bitcoin-dev] Hardening against hash reversal attacks

[bitcoin-dev] Hardening against hash reversal attacks

[Patrick Shirkey]

[-- Attachment #1: Type: text/plain, Size: 1968 bytes --]

Hi,

Given recent discussions around possible cracks to RSA, ECDSA and even sha256 we have been looking at possible options for hardening Bitcoin against those potential attack vectors. While most consider it a low priority, IMO it is better to discuss this issue than ignore it especially given recent developments. Possible solutions may not be quick to implement, test, deploy and prevention is better than the cure.

We humbly present a few seeds of ideas which might be viable defenses. These are not deeply thought out at the technical level but may inspire some useful discussion for a few new BIPs.

We have discussed these ideas in private before submitting to shake out weaknesses. We are aware that the ideas are challenging and probably contentious. We are not seeking didruption. The goal is to defeat potential attacks. Apologies if these ideas are not new and have already been dismissed.

Possible defense strategies:

1. Alternate hashing methods. Not sha256. Exposing them sooner rather than later to enable a smooth transition.

2. Per address seed phrases. In addiition to mulitisig, segwit, P2SH, schnorr, taproot.

3. Removing private keys from a wallet for safe storage in a seperate location.

4. Completely removing wallets from the blockchain for 'absolute' cold storage*. If possible there would no longer be any trace of the wallet or associated addresses. Possibly in combination with the next suggestion.

- Bonus for general maintenance.

5. Burning old coins and generating 'new' coins to 'reset' tx history.

A 'Burn and Reissue' FIFO queue with set miner fees. Satoshis submitted to the queue are permanently 'disabled and no longer in use. Replacement satoshis are added to new blocks and distributed by queue priority. Suggest a set fee to avoid excessively high processessing fees and/or getting stuck in the queue.

* We realise this would require some significant changes that may not be technically possible.

--
Patrick Shirkey

[-- Attachment #2: Type: text/html, Size: 2077 bytes --]