From: Ashley Holman <dscvlt@gmail•com>
To: Ethan Heilman <eth3rs@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Lets discuss what to do if SHA256d is actually broken
Date: Wed, 4 Jun 2014 00:42:12 +0930 [thread overview]
Message-ID: <CAOXABZqJL=Qe5bTbPB9LvLPUCdEca9eP9CHhPjd+eq1ZyLLyqA@mail.gmail.com> (raw)
In-Reply-To: <CAEM=y+WFofZV-DbqEhkMT477jKdV35daoc+f3RWpCk=Vgy8ONA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]
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@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@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@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@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
[-- Attachment #2: Type: text/html, Size: 5507 bytes --]
next prev parent reply other threads:[~2014-06-03 15:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-03 4:29 xor
2014-06-03 4:52 ` Luke Dashjr
2014-06-03 11:51 ` Ethan Heilman
2014-06-03 15:12 ` Ashley Holman [this message]
2014-06-03 12:45 ` Rusty Russell
2014-06-04 1:38 ` Charlie 'Charles' Shrem
2014-06-05 6:09 ` Rusty Russell
2014-06-03 14:43 ` Kevin
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='CAOXABZqJL=Qe5bTbPB9LvLPUCdEca9eP9CHhPjd+eq1ZyLLyqA@mail.gmail.com' \
--to=dscvlt@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=eth3rs@gmail$(echo .)com \
/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