📅 Original date posted:2017-04-10
📝 Original message:On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term. I've heard the
> term "level playing field" bandied about quite a bit. And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware. Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
>
Whatever your hashing function the bottleneck for mining will be power.
Equihash and Cuckoo are serious attempts at making custom hardware have no
benefit over commodity hardware, but that's more about getting rid of
custom hardware manufacturers than it is about mining decentralization,
although arguably if successful it might let botnets back in, which would
improve decentralization. While those have been surprisingly successful at
resisting hardware so far, they might eventually fall as well, and if they
do they'll have even worse properties of centralizing around a mining
hardware manufacturer than sha256 does.
It would be much safer to go the other way, to a PoW function whose best
hardware implementation is particularly straightforward and well
understood. In that case it would be best to go with sha3. Sha3 also has
the benefit of using the sponge construction, which makes it particularly
resistant to asciboost-type attacks. It was picked out specifically because
its design from a security standpoint was particularly
confidence-inspiring, and in this case it actually makes a difference.
Arguably you could also go with blake2b, whose 1024 bit block size
completely obviates the asicboost concern entirely by cramming everything
into a single block. That also might have an even simpler design in
hardware than sha3, but a real expert would need to opine on that one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170410/3ff44513/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:59:52
in reply to nevent1q…9y2n
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:59:52Event JSON
{
"id": "bfac70ad487a3bd57023c6399009bf43a313aeb3cb3a16fdc27bfe8ca8a0fee0",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160792,
"kind": 1,
"tags": [
[
"e",
"b3abda28c58fcdd36a7f3d79347d12387effc8cb5f326fca3c05e821d4348755",
"",
"root"
],
[
"e",
"961553aa047b4c95b98eca3eddc110eba14721c0c224eb52082d77448ae970a9",
"",
"reply"
],
[
"p",
"64beca12fc5b44756bf598083c159e53a420bdb1954e4f36aa2a6d72981ccbab"
]
],
"content": "📅 Original date posted:2017-04-10\n📝 Original message:On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\n\u003e Clearly a level-playing field is critical to keeping centralization from\n\u003e being a \"defining feature\" of Bitcoin over the long term. I've heard the\n\u003e term \"level playing field\" bandied about quite a bit. And it seems to me\n\u003e that the risk of state actor control and botnet attacks is less than\n\u003e state-actor manipulation of specialized manufacturing of \"SHA-256 forever\"\n\u003e hardware. Indeed, the reliance on a fairly simple hash seems less and\n\u003e less likely a \"feature\" and more of a baggage.\n\u003e\n\u003e\nWhatever your hashing function the bottleneck for mining will be power.\nEquihash and Cuckoo are serious attempts at making custom hardware have no\nbenefit over commodity hardware, but that's more about getting rid of\ncustom hardware manufacturers than it is about mining decentralization,\nalthough arguably if successful it might let botnets back in, which would\nimprove decentralization. While those have been surprisingly successful at\nresisting hardware so far, they might eventually fall as well, and if they\ndo they'll have even worse properties of centralizing around a mining\nhardware manufacturer than sha256 does.\n\nIt would be much safer to go the other way, to a PoW function whose best\nhardware implementation is particularly straightforward and well\nunderstood. In that case it would be best to go with sha3. Sha3 also has\nthe benefit of using the sponge construction, which makes it particularly\nresistant to asciboost-type attacks. It was picked out specifically because\nits design from a security standpoint was particularly\nconfidence-inspiring, and in this case it actually makes a difference.\nArguably you could also go with blake2b, whose 1024 bit block size\ncompletely obviates the asicboost concern entirely by cramming everything\ninto a single block. That also might have an even simpler design in\nhardware than sha3, but a real expert would need to opine on that one.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170410/3ff44513/attachment.html\u003e",
"sig": "e592537f60b3fdfbf2c7eb6172c4a5983a7f6ab80ea4ab641e6ed419c3c541776d2f58420c71672c24ac88611f3583849fc85f565e2c11625a64b8c5371588f9"
}