Cuckoo Cycle insecure use of Siphash.
Cuckoo Cycle doesn't rely on cryptographic security of its underlying hash function,
and Dan Bernstein himself attested to its use in Cuckoo Cycle being perfectly sound.
Please provide me a copy of that discussion, because I believe I have already shown it is potentially unsound in some logic I have written down and not yet revealed.
I think perhaps you have misunderstood Dan or (more unlikely given how smart he is) Dan has misunderstood something. It can happen.
I also expect that given Cuckoo Cycle is parallelizable
No need to expect. This is clearly stated in the white paper.
I presume based on your birthplace, that English is not your native language. Please don't ignore then word 'given'. The 'expect' is referring to the remainder of the statement that you elided.
necessary to make Cuckoo Cycle's proving time reasonable for instant transactions
The white paper also explains that Cuckoo Cycle is not suitable for short block intervals,
and works best for intervals even longer than bitcoin's.
Yes but you have interleaved other reasons for that, afair not mentioning the reason that I added. So I am just adding analysis.
By no means was I indicating your work is worthless. There is something very important that will come from this.
Instant transactions are best handled with off-chain payment channels, reserving the main chain for settlement.
Technically incorrect.
tromp thinks that Cuckoo Cycle has very low computation relative to memory latency. But this depends on only one 32-bit bucket being read in each memory page/row. With massive number of h/w threads, can get them all synced up (or sorted) so that we read 1024 of 32-bit buckets in one memory latency cycle
Cuckoo Cycle randomly accesses 2-bit counters, not 32-bit buckets.
Are you referring to the latest version of your code, because I am referring to the code that was in the Appendix of your
December 31. 2014February 1, 2014 white paper which references
int buckets.
Is this edge trimming coming from a suggestion from Dave Andersen?
In one round of edge trimming, Cuckoo Cycle typically updates 2^29 counters
spread over 2^8 memory banks. Each memory bank thus holds 2^21 counters,
only 2^14 of which typically fit in a single row. This is where the latency comes in.
To avoid latency, you could increase the number of memory banks by a factor of 2^7,
but this similarly increases die area, hardware costs, and energy usage.
Or increase the number of h/w threads to 2^15 (2^8 multiplied by 2^21 bits for 2-bit counters divided by 2^14 bits per row) which have some efficient h/w mechanism for waiting to be synchronized on a memory page/row.
Alternatively, the algorithm parameter PART_BITS allows for a reduction in the number
of counters in use at the same time, which is what your proposal essentially amounts to.
Setting this to 21 will require only 2^8 counters,
one per memory bank. But now your hash computations have increased by a factor 2^21,
over 2 million.
No that is not equivalent to increasing the number of h/w threads and syncing them to pause until 2^13 of them are queued up to read a shared memory page/row.
Both of these approaches are rather cost prohibitive. You might as well avoid DRAM latency
by using SRAM instead. But that is also two orders of magnitude more expensive, while the
performance increase is closer to one order of magnitude.
Btw, electrical power cost of SRAM is only one order-of-magnitude increase:
Magnus Moreau. Estimating the Energy Consumption of Emerging Random Access Memory Technologies
Cuckoo Cycle may not be ASIC-proof, but it certainly seems to resist...
So far, I disagree. I appreciate your discussion, because I want to make sure my analysis is correct. I also have to strike a balance between full publishing and secrecy, because unlike you, I have objectives around releasing a Bitcoin killer altcoin.