Quote from: dga on July 29, 2014, 12:26:36 AM

Quote from: rethink-your-strategy on July 29, 2014, 12:06:02 AM

AnonyMint has made his position on BBR clear:

...

He's confirmed that BBR's PoW "seems to lack entropy"

I've posted in other threads about the comparison between XMR and BBR's proof of work schemes. The bottom line is that they're optimizing for fundamentally different things. I have a hunch that in the long term, both will turn into DRAM bandwidth-limited currencies, but for very different reasons, but that's an attribute that places ASIC-accelerated approaches on a reasonably similar bar. The GPUs will be faster than the CPUs. The ASICs will be faster than the GPUs. But the ratio will be less large than it is with Bitcoin. In the short term, BBR will be relatively more GPU-friendly than XMR is, but I don't think that there's much difference for them with ASIC-based implementations.

Disagree.

I explained (start of discussion) how it is possible that Cryptonote's default (i.e. Monero's) PoW might possibly be reduced to a faster more optimized cache in the ASIC by trading computation for space.

Quote from: dga on July 29, 2014, 12:26:36 AM

The statement about the "seems to lack entropy" is as vague as AnonyMint's other attacks against the XMR proof of work for having weaknesses related to its use of AES.

Note my statement about misuse of AES round as a one-way hash function has cryptanalysis support (1 round only diffuses over 32-bits and less than 12 rounds is known to have attacks). Nevertheless it is an orthogonal point to the point I made above about optimization for ASICs.

Quote from: dga on July 29, 2014, 12:26:36 AM

Remember - he doesn't like either of them, if you're going to start dredging all this crap up. I'm in the opposite boat - I suspect they're both fine for now, but I make that statement cautiously for both, with the understanding that they may need to be modified (in relatively small ways) at some point in the next few years.

You may never know that someone is getting a disproportionate amount of coins because they cracked the PoW and didn't tell you. Wink

What 'caution' and what 'crap' again?

You've already demonstrated your laziness upthread with failure to apply sufficient reading comprehension. Get control of your emotions please. This is a rational discussion.

I assume you have intellectual insight to add here, if you can somehow sieve your emotions out of the way.

Quote from: dga on July 29, 2014, 12:26:36 AM

There is one known "weakness" in the BBR proof-of-work that should be fixed at some point in the future, but it's similar in importance to the way AES is used in XMR:

Disagree if you are also implying there is only one weakness in XMR's PoW. I explained potential vulnerability to ASICs. And worse I worry that such an ASIC would be highly proprietary if it ever comes and thus perhaps only available to a few.

BBR doesn't use AES-NI.

Quote from: dga on July 29, 2014, 12:26:36 AM

Both might make a serious cryptographer nervous if the function was being used **as a hash function** that needed all of the strong properties of a hash function,

Agreed and afaik I was the first person to point that out about Cryptonote on May 6.

Quote from: dga on July 29, 2014, 12:26:36 AM

but neither is overly-flawed as a *proof-of-work* function, barring future analysis.

In XMR's PoW, the use of the AES round as a random oracle to lookup memory locations within the scratchpad is likely not a uniform distribution, thus it potentially subjects the hash to a crack which employs a smaller scratchpad which statistically yields the solution at a sufficient success rate to justify the optimization. This is essentially related to a Birthday attack.

In BBR's PoW, it is employing entropy from the blockchain to replace the computation of confusion and diffusion that a hash function (AES in XBR) does to achieve random uniform lookups within the scratchpad. If this entropy is insufficient, then similar crack can be applied.

If I didn't have something much more potentially lucrative that is keeping me fully preoccupied, I would endeavor to go attempt to crack these PoW and keep it secret to make a lot of money mining. Maybe someone already has. And you don't know!

Quote from: dga on July 29, 2014, 12:26:36 AM

The truth about them both is that they've both used well-studied cryptographic primitives (good) and changed the *inside* of them to achieve a goal of memory hardness. It's always dangerous to poke around inside the algorithms, but proof-of-work leaves a lot more breathing room as far as we know -- this is still a fairly under-studied field.

DunningKruger effect. You don't know!

Quote from: dga on July 29, 2014, 12:26:36 AM

All of this misquoting of the mythical man month is silly, and ignores a more important point: 1-2 developers can do great things. So can 7. So can a dozen -- that's Amazon's preferred team size, for example.

You entirely missed the point of distinction between innovation and refinement. You continuously demonstrate lax reading comprehension.

Quote from: AnonyMint on July 29, 2014, 01:09:43 AM

P.S. I never wrote that the ideal team size is 1 or 2 for all scenarios. Rather I said that for raw innovation, the ideal is 1 or 2 and for refinement via open source, the core team size should be larger (with hopefully a Benevolent Dictator to keep innovation from being stifled by consensus gridlock or chaos) and the community of eyeballs should be unbounded.

Quote from: dga on July 29, 2014, 12:26:36 AM

Stop grasping at bull$#!#.

It is spewed all over your mirror.

(links will be added shortly to this post, come back in a few minutes)

Edit: dga is hard-headed, because I told him all of this before and he prefers his Dunning-Kruger effect...

Quote from: AnonyMint on July 23, 2014, 01:41:19 AM

Quote from: dga on July 22, 2014, 08:11:11 PM

Update: I also read your linked thread's comments about the use of AES. You're not looking at the big picture. In the context of a proof-of-work scheme (NOT as the hash to verify integrity), the limitation of 128 bits at each step is unimportant.

In terms of you missing the 'big picture' see my points up-post.

CryptoNote employs AES encryption as a random oracle so that all possible cache table elements should be equally probable at each random access. But AES encryption isn't designed to be a random oracle. Thus there may exist attacks on the structure of the probabilities of random accesses in the table.

Note the AES vulnerability isn't required to implement an ASIC that out peforms. It is an orthogonal potential attack. There might be a way to trade computation for space within some structure that deviates from uniform random distribution given by the misuse of AES encryption.