Charlie 'Charles' Shrem [ARCHIVE] on Nostr: 📅 Original date posted:2014-06-03 📝 Original message:Hey Rusty, This is ...
📅 Original date posted:2014-06-03
📝 Original message:Hey Rusty,
This is intriguing, do you have a writeup somewhere I can read more about ?
Thanks,
Charlie
CharlieShrem.com | *Please **encrypt messages with my PGP key
<http://charlieshrem.com/contact/>;*
On Tue, Jun 3, 2014 at 8:45 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Luke Dashjr <luke at dashjr.org> writes:
> > 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.
>
> I normally just lurk, but I looked at this issue last year, so thought
> I'd chime in. I never finished my paper though...
>
> In the event of an *anticipated* weakening of SHA256, a gradual
> transition is possible which avoids massive financial disruption.
>
> My scheme used a similar solve-SHA256-then-solve-SHA3 (requiring an
> extra nonce for the SHA3), with the difficulty of SHA256 ramping down
> and SHA3 ramping up over the transition (eg for a 1 year transition,
> start with 25/26 SHA2 and 1/26 SHA3).
>
> The hard part is to estimate what the SHA3 difficulty should be over
> time. My solution was to adjust only the SHA3 target on every *second*
> difficulty change (otherwise assume that SHA2 and SHA3 have equally
> changed rate and adjust targets on both).
>
> This works reasonably well even if the initial SHA3 difficulty is way
> off, and also if SHA2 breaks completely halfway through the transition.
>
> I can provide more details if anyone is interested.
>
> Cheers,
> Rusty.
>
>
> ------------------------------------------------------------------------------
> 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/20140603/1b65e2fd/attachment.html>;
📝 Original message:Hey Rusty,
This is intriguing, do you have a writeup somewhere I can read more about ?
Thanks,
Charlie
CharlieShrem.com | *Please **encrypt messages with my PGP key
<http://charlieshrem.com/contact/>;*
On Tue, Jun 3, 2014 at 8:45 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
> Luke Dashjr <luke at dashjr.org> writes:
> > 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.
>
> I normally just lurk, but I looked at this issue last year, so thought
> I'd chime in. I never finished my paper though...
>
> In the event of an *anticipated* weakening of SHA256, a gradual
> transition is possible which avoids massive financial disruption.
>
> My scheme used a similar solve-SHA256-then-solve-SHA3 (requiring an
> extra nonce for the SHA3), with the difficulty of SHA256 ramping down
> and SHA3 ramping up over the transition (eg for a 1 year transition,
> start with 25/26 SHA2 and 1/26 SHA3).
>
> The hard part is to estimate what the SHA3 difficulty should be over
> time. My solution was to adjust only the SHA3 target on every *second*
> difficulty change (otherwise assume that SHA2 and SHA3 have equally
> changed rate and adjust targets on both).
>
> This works reasonably well even if the initial SHA3 difficulty is way
> off, and also if SHA2 breaks completely halfway through the transition.
>
> I can provide more details if anyone is interested.
>
> Cheers,
> Rusty.
>
>
> ------------------------------------------------------------------------------
> 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/20140603/1b65e2fd/attachment.html>;