Verify destabilizing SHA256 hashing shortcuts if possible, create POW hash algo migration path #375

issue midnightmagic opened this issue on July 3, 2011
  1. midnightmagic commented at 8:48 AM on July 3, 2011: contributor

    -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160

    Logfile: #bitcoin-mining_20110702.log Retrieved: 20110703011120 GMT-0800 Tags: sha256-preimage Participants: midnightmagic;mrb_;Diablo-D3

    [01:07:47] <midnightmagic> i totally just doubled my hashrate and.. it doesn't matter. still peanuts. jesus.. hey screw you enormous mining public in general!!!1! [01:53:03] <mrb_> midnightmagic: using that SHA-256 optim ? ;-) [01:54:19] <midnightmagic> mrb_: no, I just brought in a pile of fresh 6970 and got them set up. [01:55:08] <midnightmagic> mrb_: you're teasing me; what sha-256 optim are you talking about? the maj() instruction saves? [01:55:18] <mrb_> no [01:56:21] <mrb_> something else. but I should probably not disclose. some in the [...] elided embarrassing chatter [...] [02:02:57] <mrb_> let's just say that if Bitcoin keeps being successful, within 5-10 years SHA-256 will be completely broken with pre-image attacks. [02:02:32] <Diablo-D3> mrb_: is the optimization workable in opencl? [02:04:43] <mrb_> Diablo-D3: yes. it is an algorithmic optim. [02:04:53] <Diablo-D3> mrb_: how big of one? [02:05:20] <mrb_> 1+ Ghash/s on one 5970. [02:05:38] <Diablo-D3> I was asking in percentage [02:05:46] <mrb_> basically 2x [02:05:53] <Diablo-D3> .... you are full of shit. [02:06:08] <mrb_> yes I am. [02:06:36] <mrb_> how do I get out of this discussion, other than "good night guys"? [02:07:39] <mrb_> alright. night guys ;)

    mrb_ is a BlackHat Sec Briefings presenter; designer of whitepixel, one of the fastest brute-force crackers that exists; writes his mining kernels in CAL/IL directly; and designs faster MD5 crackers in assembly.. for fun:

    http://www.zorinaq.com/papers/md5-amd64.html

    Suffice to say, mrb_ is not an idiot, and writes software that surprisingly backs up his claims—claims that would be outlandish if random nobodies spouted them. mrb_ is not a random nobody.

    If such an optimization exists, it is critically important that a migration path to a more modern hash algorithm be designed into bitcoind now so that, should 2x or 10x speed increases be created and published, bitcoind would not taken out as part of the collateral damage, through destabilization of mining efforts and the hit to confidence in the underlying crypto.

    This isn't a question of whether I personally believe him. I personally think he's full of crap. It doesn't matter. We are locked into one hashing algorithm and this sort of rumour exposes a weakness that we needn't have. -----BEGIN PGP SIGNATURE-----

    iEYEAREDAAYFAk4QLG8ACgkQ2p+H2HZY90HiEgCfYvQZYdsHJUT4aEasuqLlEFHi rVwAmwcSs9WyumpJq4y8bnRXOXOsq+x8 =TCoE -----END PGP SIGNATURE-----

  2. TheBlueMatt commented at 7:32 PM on July 3, 2011: member

    So, Bitcoin can handle 2x, 4x, 1000x, 10000x its current hash power with no problem, difficulty will increase, so what? If SHA256 is reasonably hacked (which I still very much doubt will happen in any reasonable time, even if someone who has some experience cracking MD5 claims it will be) we do need to switch off of it for transactions. But seriously, this is something that can be dealt with in a matter of a day or less if there is a need to. It seems like this bug report keeps showing up on a very regular basis.

  3. gavinandresen commented at 1:43 PM on July 4, 2011: contributor

    ... so we switch to another hashing algorithm and the rumors start again.

    I'm going to close this, it is not an issue right now.

  4. gavinandresen closed this on Jul 4, 2011

  5. midnightmagic commented at 5:10 PM on July 4, 2011: contributor

    My point is that without a POW hash migration path, there does not appear to be a way to easily and rapidly switch in the event a weakness or vulnerability becoming evident. Like I said, I personally think he's full of crap, but that doesn't mean that bitcoind currently hasn't all its eggs in one basket for the POW blockchain. I'm not advocating we switch immediately, I'm requesting we get the infrastructure in-place to do the switch, or at least publish the plan for it.

    If you're saying it's fine in your mind to have miners who are operating at four orders of base-10 magnitude apart from one another, then perhaps this is a non-issue. Is this the stance from the devs?

    The thought and designwork behind "switching within a day" is precisely what I'm talking about. What is that path? How would it be done? I'm not a dev, I don't know what you guys have been talking about in whatever channels you guys talk about it in. Document it, at least, please, even if there's no code to it. What is the plan, specifically, for switching if it becomes necessary? And, if that plan doesn't actually exist and you're just saying it would be easy, then please reopen this request and consider it a reasonable venue for tracking that work which will eventually be done.

    The other part of the point is that this manner of response isn't as informative as I am requesting it to be for miners like myself who are spending considerable capital on mining equipment. Is there a purpose for this apparently opaque designwork?

    I'm not saying you should jump and issue panicky statements at the first sign of idiotic rumour-mongering. I'm just asking for a measured, honest, and transparent response to molehills like this, even if it takes a while, so we can participate in, poke holes in, and otherwise help with, the solution to problems which will materialize in the future.

    Finally, the last part is that some of us who are spending considerable capital on mining equipment want to hear from the horse's mouth, specifically: do you know anything about this, at all? If you have, I am asking you to please document that. Do you know of this, have you heard anything substantive, and what will you do when it does (as it inevitably will) become substantive?

  6. dexX7 referenced this in commit c1522238e0 on May 24, 2016
  7. CodeShark referenced this in commit 406974acf2 on Sep 10, 2017
  8. DrahtBot locked this on Sep 8, 2021

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-29 03:16 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me