From: Patrick Shirkey <patrickshirkey@protonmail•com>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Hardening against hash reversal attacks
Date: Sat, 06 Mar 2021 12:58:25 +0000 [thread overview]
Message-ID: <GmGlyaNk3JAtDK2R6C-cLMWQd2OxPJCj9MAZdKnjKfIRm0dowKWoo4h3dOCZeipQEHvX3wo4u1eV_xmSculSnC_n3AYLp1O2nIVa2Gfcg5Q=@protonmail.com> (raw)
[-- 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 --]
reply other threads:[~2021-03-06 12:58 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='GmGlyaNk3JAtDK2R6C-cLMWQd2OxPJCj9MAZdKnjKfIRm0dowKWoo4h3dOCZeipQEHvX3wo4u1eV_xmSculSnC_n3AYLp1O2nIVa2Gfcg5Q=@protonmail.com' \
--to=patrickshirkey@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox