Topic: Make Bitcoin sha256 future proof (Read 1638 times)
If SHA256 is ever weakened, mining is the last thing we need to worry because there is difficulty adjustment, unless it is a collision attack
There is no need to designate the hash system used anywhere. By design, hashes are easy to verify, so each node can just iterate all allowed hashes until it finds one that gives a result under target, or reject the block if none fit.
Adding a hash could be as simple as adding /MH:SHA3/ to the coinbase (or whatever string is appropriate) and allowing that hash once 95% of miners support it. As long as the hash produces a 256 bit output (or more, we can discard part) and has a nearly random distribution, the difficulty mechanism can remain unchanged.
Disabling an old hash would be harder, probably best done by picking a block number 2 or 4 years into the future and patching the software to stop checking that hash starting with that block. A sudden break in SHA is extremely unlikely, so a few years will not open up any security problems, and we could shorten it if really necessary.
Adding a hash could be as simple as adding /MH:SHA3/ to the coinbase (or whatever string is appropriate) and allowing that hash once 95% of miners support it. As long as the hash produces a 256 bit output (or more, we can discard part) and has a nearly random distribution, the difficulty mechanism can remain unchanged.
Disabling an old hash would be harder, probably best done by picking a block number 2 or 4 years into the future and patching the software to stop checking that hash starting with that block. A sudden break in SHA is extremely unlikely, so a few years will not open up any security problems, and we could shorten it if really necessary.
Just a non detailed suggestion to modify the standard bitcoin client to support multiple hash mechanisms and multiple block headers.
At some point in the future (yeah I'm suggesting planning ahead again ...) we will need to change the sha256 hash to something more robust.
Currently sha256 is robust enough, however, that could change some time in the future.
It could be the far future or it could be the near future.
Of course no one knows as yet.
So what I'm simply suggesting is to incorporate in the bitcoin client already, the ability to support multiple hash mechanisms, other than just the current sha256 with the standard header as is currently used.
Obviously this represents a hard fork to actually accept these different hashes/headers into the block chain, so I'm not advocating doing that now.
In fact I would suggest to set some time control (set to the far future) on accepting the extra hash functions or headers - and set any newly defined hash or header to be supported far in the future. One could always do something similar to the /P2SH/ to determine client support for a new hash mechanism before enabling it - to enable it sooner.
But the point of this is of course, as I've said, to plan ahead for when sha256 can no longer be used.
If the code all already existed and supported multiple different hash functions and headers, but of course only the current sha256 and header were enabled, we could still use the code in testing by simply modifying the control date of another hash mechanism or header.
My first suggested hash addition would be sha3.
Having the code all there ready and working but just not available to be accepted in the block chain immediately would indeed be a very good plan ahead - rather than one day in the future suddenly finding that sha256 had to be replaced and the whole bitcoin world scrambling to hack a fix into bitcoin.
Instead it would simply be to enable a different hash mechanism already present and disable the no longer secure hash mechanism - and a hard fork that day (like happened earlier this year) and then the problem would be solved.
i.e. I'm suggesting something that also plans ahead for a catastrophic failure found in sha256 and being able to switch that as quickly as possible
We could also consider a sooner future date to enable sha3 but not disable the current sha256 and thus the huge network power of the current bitcoind network would not be switched off overnight and make bitcoin severely at risk of a 51% attack.
A design in the hash of sha3 could also be used to make it equally difficult to hash both has256 and sha3, so as to stear future hardware design to take on the new sha3 ... once sha3 was enabled.
A simple example, that may not be a viable solution, but simply a suggestion, would be to use the 'first' byte of the hash to determine the hash mechanism used. Currently all sha256 block hashes must have 0 in the 'first' 4 bytes, so that might be possible to be used to differentiate the hash mechanisms used.
Of course I'd also suggest another hash/header addition as detailed here:
https://bitcointalksearch.org/topic/handle-much-larger-mhs-rigs-simply-increase-the-nonce-size-89278
to be considered a near future code addition and possibly to be enabled in the not too distant future also.
Of course I've no idea if any of the bitcoin devs are planning anything like this, but I feel that it is something that needs to be taken into consideration to help secure the future of bitcoin.
At some point in the future (yeah I'm suggesting planning ahead again ...) we will need to change the sha256 hash to something more robust.
Currently sha256 is robust enough, however, that could change some time in the future.
It could be the far future or it could be the near future.
Of course no one knows as yet.
So what I'm simply suggesting is to incorporate in the bitcoin client already, the ability to support multiple hash mechanisms, other than just the current sha256 with the standard header as is currently used.
Obviously this represents a hard fork to actually accept these different hashes/headers into the block chain, so I'm not advocating doing that now.
In fact I would suggest to set some time control (set to the far future) on accepting the extra hash functions or headers - and set any newly defined hash or header to be supported far in the future. One could always do something similar to the /P2SH/ to determine client support for a new hash mechanism before enabling it - to enable it sooner.
But the point of this is of course, as I've said, to plan ahead for when sha256 can no longer be used.
If the code all already existed and supported multiple different hash functions and headers, but of course only the current sha256 and header were enabled, we could still use the code in testing by simply modifying the control date of another hash mechanism or header.
My first suggested hash addition would be sha3.
Having the code all there ready and working but just not available to be accepted in the block chain immediately would indeed be a very good plan ahead - rather than one day in the future suddenly finding that sha256 had to be replaced and the whole bitcoin world scrambling to hack a fix into bitcoin.
Instead it would simply be to enable a different hash mechanism already present and disable the no longer secure hash mechanism - and a hard fork that day (like happened earlier this year) and then the problem would be solved.
i.e. I'm suggesting something that also plans ahead for a catastrophic failure found in sha256 and being able to switch that as quickly as possible
We could also consider a sooner future date to enable sha3 but not disable the current sha256 and thus the huge network power of the current bitcoind network would not be switched off overnight and make bitcoin severely at risk of a 51% attack.
A design in the hash of sha3 could also be used to make it equally difficult to hash both has256 and sha3, so as to stear future hardware design to take on the new sha3 ... once sha3 was enabled.
A simple example, that may not be a viable solution, but simply a suggestion, would be to use the 'first' byte of the hash to determine the hash mechanism used. Currently all sha256 block hashes must have 0 in the 'first' 4 bytes, so that might be possible to be used to differentiate the hash mechanisms used.
Of course I'd also suggest another hash/header addition as detailed here:
https://bitcointalksearch.org/topic/handle-much-larger-mhs-rigs-simply-increase-the-nonce-size-89278
to be considered a near future code addition and possibly to be enabled in the not too distant future also.
Of course I've no idea if any of the bitcoin devs are planning anything like this, but I feel that it is something that needs to be taken into consideration to help secure the future of bitcoin.
Jump to: