From: David Vorick <david.vorick@gmail•com>
To: praxeology_guy <praxeology_guy@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
Date: Thu, 6 Apr 2017 08:13:23 -0400 [thread overview]
Message-ID: <CAFVRnyrQPRj_aLtovxoAqHmDJb5Jh7nm1YvCx7p5QWBFBfXrRA@mail.gmail.com> (raw)
In-Reply-To: <hGMlexjBJD3vlKg-_mmzAc6Qrth3zfL0hd5hfKllNHkgr4FQzXnuawXizgCFu-5d_cBs6zxwI4LxNNr-nMaZYl1gFzU8XU3sW2TwRQF1PdU=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 1724 bytes --]
>
> Another thing that could be done is increase the number of times SHA256 is
> performed... but now we are really talking about altering the PoW
> algorithm. Correct me if I'm wrong: The more number of times its
> performed, the less any patent-able pre or post calculation
> skipping/caching have an effect on efficiency.
>
The more complex that the PoW algorithm is, the more likely it is that
someone finds a unique and special method for optimizing it that they are
able to patent. And the more difficult it is to create specialized hardware
to run that algorithm, meaning that there will be fewer players who are
able to do so profitably (higher fixed costs).
If you want to talk about changing the PoW algorithm, you really want to be
looking to simplify it so that it's more obvious (not that you can ever be
completely sure) that there are no hidden or unexpected optimizations that
someone could patent.
We can even do a lot better than SHA. Cryptographic hash functions need to
be collision resistant, and collision resistance is the property that
usually breaks. Preimage resistance and partial preimage resistance (and
second preimage resistance) is generally easier to protect - to the best of
our knowledge, md5 would actually still be a secure PoW function today.
It's bitterly ironic to me that so much research and effort has been put
into making asic-resistant PoW algorithms when in the long run
asic-resistance only leads to problems like these - single parties who have
found significant optimizations and not shared them, completely destroying
any chance of a level playing field and giving themselves a centralized
monopoly - a result that is supremely unhealthy for the rest of the
community.
[-- Attachment #2: Type: text/html, Size: 2012 bytes --]
next prev parent reply other threads:[~2017-04-06 12:13 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 4:49 Raystonn .
2017-04-06 7:47 ` praxeology_guy
2017-04-06 12:13 ` David Vorick [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-04-07 1:34 Daniele Pinna
2017-04-07 6:46 ` Emilian Ursu
2017-04-07 7:44 ` Alex Mizrahi
2017-04-07 8:08 ` praxeology_guy
2017-04-06 4:47 Oliver Petruzel
2017-04-05 21:37 Gregory Maxwell
2017-04-05 23:05 ` theymos
2017-04-06 0:17 ` Gregory Maxwell
2017-04-06 0:39 ` Joseph Poon
2017-04-06 0:40 ` Joseph Poon
2017-04-06 1:32 ` Gregory Maxwell
2017-04-06 2:09 ` Joseph Poon
2017-04-05 23:25 ` Anthony Towns
2017-04-05 23:42 ` Joseph Poon
2017-04-06 2:10 ` Jonathan Toomim
2017-04-06 20:21 ` Jared Lee Richardson
2017-04-06 2:31 ` Peter Todd
2017-04-06 2:39 ` Bram Cohen
2017-04-06 2:49 ` Peter Todd
2017-04-06 3:11 ` Erik Aronesty
2017-04-06 3:23 ` Peter Todd
2017-04-06 3:23 ` David Vorick
2017-04-06 3:42 ` Peter Todd
2017-04-06 5:46 ` Thomas Daede
2017-04-06 6:24 ` Jonathan Toomim
2017-04-06 12:04 ` David Vorick
[not found] ` <CAMZUoK=oDAD9nhFAHkgncWtYxjBNh3qXbUffOH57QMnqjhmN6g@mail.gmail.com>
[not found] ` <CAMZUoKn8tr3LGbks0TnaCx9NTP6MZUzQ8PE6jDq1xiqpYyYwow@mail.gmail.com>
2017-04-06 13:55 ` Russell O'Connor
2017-04-06 16:49 ` Marco
2017-04-06 17:04 ` Alex Mizrahi
2017-04-06 17:13 ` Alex Mizrahi
2017-04-07 12:59 ` Jannes Faber
2017-04-07 13:28 ` Erik Aronesty
2017-04-06 17:31 ` Jared Lee Richardson
2017-04-06 17:26 ` Jared Lee Richardson
2017-04-06 15:36 ` Alex Mizrahi
2017-04-06 17:51 ` Jorge Timón
2017-04-06 7:24 ` bfd
2017-04-06 9:17 ` Luke Dashjr
2017-04-06 12:02 ` Luv Khemani
2017-04-06 12:11 ` Bryan Bishop
2017-04-06 17:43 ` Timo Hanke
2017-04-06 12:30 ` Luv Khemani
2017-04-06 15:15 ` Jorge Timón
2017-04-06 15:41 ` Daniel Robinson
2017-04-06 16:13 ` Andreas Schildbach
2017-04-06 21:38 ` Gregory Maxwell
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=CAFVRnyrQPRj_aLtovxoAqHmDJb5Jh7nm1YvCx7p5QWBFBfXrRA@mail.gmail.com \
--to=david.vorick@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=praxeology_guy@protonmail$(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