Ashley Holman [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-03 📝 Original message:There is a relevant post ...
📅 Original date posted:2014-06-03
📝 Original message:There is a relevant post from Satoshi on this:
https://bitcointalk.org/index.php?topic=191.msg1585#msg1585
Quote:
"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in
an orderly way. The software would be programmed to start using a new hash
after a certain block number. Everyone would have to upgrade by that time.
The software could save the new hash of all the old blocks to make sure a
different block with the same old hash can't be used."
On Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman <eth3rs at gmail.com> wrote:
> An attack on the mining difficulty algorithm does not imply violation of
> the typical security properties of a cryptographic hash function*.
>
> Assume someone discovers a method which makes it far easier to discover
> new blocks, this method: may or may not be implementable by the current
> SHA256 ASIC hardware.
>
> 1. If it is usable by the mining hardware, then there will be brief period
> of overproduction and then difficulty will adjust. If the attack is so bad
> that difficulty can't scale and we run out of a leading zero's, then the
> SHA256 collision resistance is broken and we have bigger problems. Under
> this scenario, everyone would see the need to immediately switch to new
> hardware as people could create cycles and irreconcilable forks in the
> block chain
>
> 2. If the attack is not usable by the mining hardware, then the miners
> will need to switch to new ASICs anyways and the hash function can be
> changed without resistance.
>
> But lets ignore all that and say, for some unspecified reason, the bitcoin
> community wants to switch hash functions and has some lead time to do so.
> One could require that miners find two blocks, one computed using SHA256
> and one computed using the new hash function. We could then slowly shift
> the difficulty from SHA256 to the new hash function. This would allow
> miners a semi-predicable roadmap to switch their infrastructure away from
> SHA256.
>
> * It would be a distinguisher which would be bad, but collision resistance
> could be merely weakened.
>
>
> On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> > 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.
>>
>> C) fabricate past blocks entirely.
>>
>> If SHA256d is broken, Bitcoin as it is fails entirely.
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/287312fb/attachment.html>;
📝 Original message:There is a relevant post from Satoshi on this:
https://bitcointalk.org/index.php?topic=191.msg1585#msg1585
Quote:
"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in
an orderly way. The software would be programmed to start using a new hash
after a certain block number. Everyone would have to upgrade by that time.
The software could save the new hash of all the old blocks to make sure a
different block with the same old hash can't be used."
On Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman <eth3rs at gmail.com> wrote:
> An attack on the mining difficulty algorithm does not imply violation of
> the typical security properties of a cryptographic hash function*.
>
> Assume someone discovers a method which makes it far easier to discover
> new blocks, this method: may or may not be implementable by the current
> SHA256 ASIC hardware.
>
> 1. If it is usable by the mining hardware, then there will be brief period
> of overproduction and then difficulty will adjust. If the attack is so bad
> that difficulty can't scale and we run out of a leading zero's, then the
> SHA256 collision resistance is broken and we have bigger problems. Under
> this scenario, everyone would see the need to immediately switch to new
> hardware as people could create cycles and irreconcilable forks in the
> block chain
>
> 2. If the attack is not usable by the mining hardware, then the miners
> will need to switch to new ASICs anyways and the hash function can be
> changed without resistance.
>
> But lets ignore all that and say, for some unspecified reason, the bitcoin
> community wants to switch hash functions and has some lead time to do so.
> One could require that miners find two blocks, one computed using SHA256
> and one computed using the new hash function. We could then slowly shift
> the difficulty from SHA256 to the new hash function. This would allow
> miners a semi-predicable roadmap to switch their infrastructure away from
> SHA256.
>
> * It would be a distinguisher which would be bad, but collision resistance
> could be merely weakened.
>
>
> On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> > 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.
>>
>> C) fabricate past blocks entirely.
>>
>> If SHA256d is broken, Bitcoin as it is fails entirely.
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140604/287312fb/attachment.html>;