📅 Original date posted:2014-06-03
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
I thought a lot about the worst case scenario of SHA256d being broken in a way
which could be abused to
A) reduce the work of mining a block by some significant amount
B) reduce the work of mining a block to zero, i.e. allow instant mining.
Bitcoin needs to be prepared for this as any hash function has a limited
lifetime. Usually crypto stuff is not completely broken instantly by new
attacks but gradually. For example first the attack difficulty is reduced from
2^128 to 2^100, then 2^64, etc.
This would make scenario A more likely.
Now while B sounds more dangerous, I think in fact A is:
Consider how A would happen in real life: Someone publishes a paper of a
theoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will
consider this as a serious attack and create a lot of riot.
If no plan is made early enough, as in now, the Bitcoin Core team might then
probably want to just do the easiest approach of replacing the hash function
after a certain block number, i.e. a hard fork.
But what about the Bitcoin miners, those who need to actually accept a change
of mining algorithm which renders their hardware which cost MILLIONS
completely worthless?
Over the years they have gotten used to exponential growth of the Bitcoin
networks hashrate, and therefore exponential devaluation of their mining
hardware. Even if the attack on SHA256d causes a significant growth of
difficulty, the miners will not *believe* that it is an actual attack on SHA256d
- - maybe it is just some new large mining operation? They are used to this
happening! Why should they believe this and switch to a new hash function
which requires completely new hardware and therefore costs them millions?
They will just keep mining SHA256d. Thats why this is more dangerous, because
changing the hash funciton won't be accepted by the miners even though it is
broken.
Something smarter needs to be thought of.
Now I must admit that I am not good at cryptography at all, but I had the
following idea: Use the altcoin concept of having multiple hash functions in a
chain. If SHA256d is broken, it is chained with a new hash function.
Thereby, people who want to mine the new replacement hash function still will
need ASICs which can solve the old SHA proof of work. So existing ASIC owners
can amend their code to do SHA256d using the ASIC, and then the second hash
function using a general purpose CPU.
This would also allow a smooth migration of difficulty - I don't even know how
difficulty would react with the naive approach of just replacing SHA with
something else: It would probably be an unsolvable problem to define new rules
to make it decrease enough so new blocks can actually be mined by the now
several orders of magnitude slower CPU-only mining community but still be high
enough to be able to deal with the fact that millions of people will try their
luck with mining at the release date.
While this sounds simple in theory, it might be a lot of work to implement, so
you guys might want to take precautions for it soon :)
Greetings,
xor - A Freenet project developer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF
E759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL
Ltkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk
n7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV
y/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek
9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD
oXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/
YpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2
Tjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K
/oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y
Yq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+
YnUYiyzreJ8ofHhNBs4/
=dkuk
-----END PGP SIGNATURE-----
xor [ARCHIVE] /
npub14a…g6tv3
2023-06-07 15:22:13
in reply to nevent1q…sdfs
Author Public Key
npub14a7v3r4ppfy007s0tk2h0ujh38h9x4t6jyrndev9qmmazd2vrsvqxg6tv3Published at
2023-06-07 15:22:13Event JSON
{
"id": "dc206d136c2d9cbb67b24728471b4688c48597306ba74f230cfed7f04d992807",
"pubkey": "af7cc88ea10a48f7fa0f5d9577f25789ee53557a910736e58506f7d1354c1c18",
"created_at": 1686151333,
"kind": 1,
"tags": [
[
"e",
"c3178a7c4915528f303d2155708d8624269c29cc1fae2cb68cf22f7c476bad58",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2014-06-03\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA256\n\nHi,\n\nI thought a lot about the worst case scenario of SHA256d being broken in a way \nwhich could be abused to \nA) reduce the work of mining a block by some significant amount\nB) reduce the work of mining a block to zero, i.e. allow instant mining.\n\nBitcoin needs to be prepared for this as any hash function has a limited \nlifetime. Usually crypto stuff is not completely broken instantly by new \nattacks but gradually. For example first the attack difficulty is reduced from \n2^128 to 2^100, then 2^64, etc.\nThis would make scenario A more likely.\n\nNow while B sounds more dangerous, I think in fact A is:\nConsider how A would happen in real life: Someone publishes a paper of a \ntheoretical reduction of SHA256d attacks to 2^96 bit. Mathematicians will \nconsider this as a serious attack and create a lot of riot.\nIf no plan is made early enough, as in now, the Bitcoin Core team might then \nprobably want to just do the easiest approach of replacing the hash function \nafter a certain block number, i.e. a hard fork.\nBut what about the Bitcoin miners, those who need to actually accept a change \nof mining algorithm which renders their hardware which cost MILLIONS \ncompletely worthless?\nOver the years they have gotten used to exponential growth of the Bitcoin \nnetworks hashrate, and therefore exponential devaluation of their mining \nhardware. Even if the attack on SHA256d causes a significant growth of \ndifficulty, the miners will not *believe* that it is an actual attack on SHA256d \n- - maybe it is just some new large mining operation? They are used to this \nhappening! Why should they believe this and switch to a new hash function \nwhich requires completely new hardware and therefore costs them millions?\nThey will just keep mining SHA256d. Thats why this is more dangerous, because \nchanging the hash funciton won't be accepted by the miners even though it is \nbroken.\nSomething smarter needs to be thought of.\n\nNow I must admit that I am not good at cryptography at all, but I had the \nfollowing idea: Use the altcoin concept of having multiple hash functions in a \nchain. If SHA256d is broken, it is chained with a new hash function.\nThereby, people who want to mine the new replacement hash function still will \nneed ASICs which can solve the old SHA proof of work. So existing ASIC owners \ncan amend their code to do SHA256d using the ASIC, and then the second hash \nfunction using a general purpose CPU.\nThis would also allow a smooth migration of difficulty - I don't even know how \ndifficulty would react with the naive approach of just replacing SHA with \nsomething else: It would probably be an unsolvable problem to define new rules \nto make it decrease enough so new blocks can actually be mined by the now \nseveral orders of magnitude slower CPU-only mining community but still be high \nenough to be able to deal with the fact that millions of people will try their \nluck with mining at the release date.\n\nWhile this sounds simple in theory, it might be a lot of work to implement, so \nyou guys might want to take precautions for it soon :)\n\nGreetings,\n\txor - A Freenet project developer\n\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.14 (GNU/Linux)\n\niQIcBAEBCAAGBQJTjU9DAAoJEMtmZ+8tjWt5pNEP/2460eHu7ujrUSxinJXY7+wF\nE759/NcpNuakqu4NsS3ndi8lSiVIeixiOWZxPwLYkzC0pgPd5JrK5hdrYewsgreL\nLtkh6LKB4YZLYrV3jm62ZPMTzCopYQ1l872xbN3PJQJoXhEp4fKu99++LDzVg9Gk\nn7rvrk6Iy/nSsZ1IMANpKghbU8/Gtn6ppCJv9rxRE//CZdTso1tTyOXXkEEMTHcV\ny/iv6CHXtTXPvOgEgciU0oCPq0NOUKdIAOD//ybcKzncOoHSmwr1rZdreCTH6/Ek\n9uwq/HaQnseHPrq9qrIkIKrZDlnjKu7Tqw1BlbyBeCrWdJPCeDJg2kyCXgTvIzFD\noXwZ6r16tb2QPR4ByyO1lZy9G2Pp26thk12BnadnPYTf1rMvsY15BjfUrCU9ppt/\nYpFAZSFlXUGOuOBKUznUeO8U1bXJylcTTnyER/cudOpcKR8Jt9l5tfm5LTHCB6Q2\nTjmvsmd0BzwafLEhHD5FHoTZFNVdXWvEUO/w4I/2UWTS7CacbE1qk0rVpsF/4L1K\n/oFVnZIUKqsm5mMMb6WTQq+MjP2TF/eAAwm2UtFYmj0FVML9HBNwyiAc5UKwnD4Y\nYq3Pl5QfRobwu6pgT3zO7vK+saOl8sePWbU8Skj41OTEDrJM4QIQGAqs1U8xke8+\nYnUYiyzreJ8ofHhNBs4/\n=dkuk\n-----END PGP SIGNATURE-----",
"sig": "f061016e00ab85a8a3ec7ace8e5af403ef4193f4d18a6f7064cbc6af311bae9d13f03acec09b6d49ddeef69ea0f53596130b70b6367b3d342e7d95e21ef7be4c"
}