📅 Original date posted:2017-04-17
📝 Original message:Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org>:
It's too bad we can't make the POW somehow dynamic so that any specialized
hardware is impossible, and only GPU / FPGA is possible.
Maybe a variant of Keccak where the size of the sponge is increased along
with additional zero bits required. Seems like this would either have to
resist specialized hardware or imply sha3 is compromised such that the size
of the sponge does not incerase the number of possible output bits as
expected.
Technically SHA3 (keccak) already has the SHAKE mode, an extensible output
function (XOF). It's basically a hash with arbitary output length (with
fixed state size, 256 bits is the common choice). A little bit like hooking
a hash straight into a stream cipher.
The other modes should *probably* not allow the same behavior, though. I
can't guarantee that however.
You may be interested in looking at parameterizable ciphers and if any of
them might be applicable to PoW.
IMHO the best option if we change PoW is an algorithm that's moderately
processing heavy (we still need reasonably fast verification) and which
resists partial state reuse (not fast or fully "linear" in processing like
SHA256) just for the sake of invalidating asicboost style attacks, and it
should also have an existing reference implementation for hardware that's
provably close in performance to the theoretical ideal implementation of
the algorithm (in other words, one where we know there's no hidden
optimizations).
Anything relying on memory or other such expensive components is likely to
fall flat eventually as fast memory is made more compact, cheaper and moves
closer to the cores.
That should be approximately what it takes to level out the playing field
in ASIC manufacturing, because then we would know there's no fancy tricks
to deploy that would give one player unfair advantage. The competition
would mostly be about packing similar gate designs closely and energy
efficiency. (Now that I think about it, the proof MAY have to consider
energy use too, as a larger and slower but more efficient chip still is
competitive in mining...)
We should also put a larger nonce in the header if possible, to reduce the
incentive to mess with the entropy elsewhere in blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/d2274892/attachment-0001.html>;
Natanael [ARCHIVE] /
npub179…lpmjt
2023-06-07 18:00:16
in reply to nevent1q…dzgc
Author Public Key
npub1798ncudyucap9jzzujjsgufx8tdykm8auzfledjcs6f6wf4ekqvq8lpmjtPublished at
2023-06-07 18:00:16Event JSON
{
"id": "ab8242f3b17bf5b6e2f6529c0470a16387f48d59e9956137487e52b173fdccab",
"pubkey": "f14f3c71a4e63a12c842e4a50471263ada4b6cfde093fcb6588693a726b9b018",
"created_at": 1686160816,
"kind": 1,
"tags": [
[
"e",
"e9ba696c99ee6820e71d8ee1eb9ad649e0173f1238858a9306a19f5461c3857f",
"",
"root"
],
[
"e",
"e8e02df54198a8e44dbb5e0de5f7c1c0efdf6065da41a3ab5fb10f6dbb9df9de",
"",
"reply"
],
[
"p",
"22944ce1e29904e3826d25013a614e4665693ec514003efacc1b7586e8e5d0aa"
]
],
"content": "📅 Original date posted:2017-04-17\n📝 Original message:Den 17 apr. 2017 16:14 skrev \"Erik Aronesty via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\nIt's too bad we can't make the POW somehow dynamic so that any specialized\nhardware is impossible, and only GPU / FPGA is possible.\n\n\n\nMaybe a variant of Keccak where the size of the sponge is increased along\nwith additional zero bits required. Seems like this would either have to\nresist specialized hardware or imply sha3 is compromised such that the size\nof the sponge does not incerase the number of possible output bits as\nexpected.\n\n\nTechnically SHA3 (keccak) already has the SHAKE mode, an extensible output\nfunction (XOF). It's basically a hash with arbitary output length (with\nfixed state size, 256 bits is the common choice). A little bit like hooking\na hash straight into a stream cipher.\n\nThe other modes should *probably* not allow the same behavior, though. I\ncan't guarantee that however.\n\nYou may be interested in looking at parameterizable ciphers and if any of\nthem might be applicable to PoW.\n\nIMHO the best option if we change PoW is an algorithm that's moderately\nprocessing heavy (we still need reasonably fast verification) and which\nresists partial state reuse (not fast or fully \"linear\" in processing like\nSHA256) just for the sake of invalidating asicboost style attacks, and it\nshould also have an existing reference implementation for hardware that's\nprovably close in performance to the theoretical ideal implementation of\nthe algorithm (in other words, one where we know there's no hidden\noptimizations).\n\nAnything relying on memory or other such expensive components is likely to\nfall flat eventually as fast memory is made more compact, cheaper and moves\ncloser to the cores.\n\nThat should be approximately what it takes to level out the playing field\nin ASIC manufacturing, because then we would know there's no fancy tricks\nto deploy that would give one player unfair advantage. The competition\nwould mostly be about packing similar gate designs closely and energy\nefficiency. (Now that I think about it, the proof MAY have to consider\nenergy use too, as a larger and slower but more efficient chip still is\ncompetitive in mining...)\n\nWe should also put a larger nonce in the header if possible, to reduce the\nincentive to mess with the entropy elsewhere in blocks.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170418/d2274892/attachment-0001.html\u003e",
"sig": "42ab85ad879786b0846825eaa192e054f845a5ec000253d4d973c48ff31c980618383c24c1deeb731858efc1112db287f848b968297e39b848284a4577a08db7"
}