<div dir="auto"><div data-smartmail="gmail_signature" dir="auto"><br></div><div class="gmail_extra" dir="auto"><div class="gmail_quote">Den 17 apr. 2017 16:14 skrev "Erik Aronesty via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>:<br type="attribution"><blockquote class="m_8645300429802790440quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div class="m_8645300429802790440quoted-text"><div class="gmail_extra" dir="auto"><div class="gmail_quote"><br><blockquote class="m_8645300429802790440m_-5360631722375867952quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">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.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_8645300429802790440m_-5360631722375867952m_6005315452753799385quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div><br></div></div></div>
</blockquote></div><br></div></div><div class="gmail_extra" dir="auto">Maybe a variant of <span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:"helvetica neue",helvetica,"nimbus sans l",arial,"liberation sans",sans-serif;font-size:16px">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. </span></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">The other modes should *probably* not allow the same behavior, though. I can't guarantee that however. </div><div dir="auto"><br></div><div dir="auto">You may be interested in looking at parameterizable ciphers and if any of them might be applicable to PoW. </div><div dir="auto"><br></div><div dir="auto">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). </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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...) </div><div dir="auto"><br></div><div dir="auto">We should also put a larger nonce in the header if possible, to reduce the incentive to mess with the entropy elsewhere in blocks. </div><div class="gmail_extra" dir="auto"></div></div>