Bryan,

Interesting argument, but I think it is not an accurate comparison. People
usually mean that, for example, say 2^80 of the original operations are
needed rather than the intended 2^128 to find a collision. This could be
the case in a broken algorithms such as a toy SHA variant with too small
states and too few rounds. These kind of attacks usually refer to that
something is learned from prior evaluations that be should't be possible to
be learned. For example, if someone could somehow construct a pre-image in
256 evaluations, getting one additional bit right at a time. Similar to a
cheap combination lock where you can figure out the correct 4 digits in a
worst case of 4*10 attempts by "feeling" it, rather than having to do the
intended 10,000 attempts. That's the kind of thing that would be called an
"attack".

Here, however, we are talking about making the individual operations
cheaper by a constant of ~20%, not changing the number of operations. That
doesn't qualify as an attack in the sense that you mean.

Best,
Timo




On Thu, Apr 6, 2017 at 5:11 AM, Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Apr 6, 2017 at 7:02 AM, Luv Khemani via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Could you elaborate on why you consider ASICBOOST to be an attack? Attack
>> here implies ill-intent by the practitioner towards the network as a
>> primary motivating factor.
>>
>>
> See https://www.reddit.com/r/Bitcoin/comments/63otrp/
> gregory_maxwell_major_asic_manufacturer_is/dfwcki3/
>
> """
> I think that it is an attack is a completely unambiguous technical
> description of what it is. If a signature is supposed to resist forgery
> against 2^128 operations, but you find a way to do it with 2^80 instead,
> this is an attack. It is, perhaps, not a very concerning attack and you may
> or may not change your signature scheme to avoid it or may just instead say
> the scheme has 2^80 security. But there is no doubt that it would be called
> an attack, especially if it was not described in the original proposal.
>
> In Bitcoin's Proof of Work, you are attempting to prove a certain amount
> of work has been done. This shortcut significantly reduces the amount of
> work. It's an attack. Normally it wouldn't be a serious attack-- it would
> just get appended to the defacto definition of what the Bitcoin Proof of
> work is-- similar to the signature system just getting restarted as having
> 2^80 security-- but in it's covert form it cannot just be adopted because
> it blocks many further improvements (not just segwit, but the vast majority
> of other proposals), and additional the licensing restrictions inhibit
> adoption.
>
> The proposal I posted does not prevent the technique, only the covert
> form: That is, it doesn't even attempt to solve the patented tech
> eventually will centralize the system problem. It is narrowly targeted at
> the interference with upgrades.
>
> Taking a step back-- even ignoring my geeking out about the technical
> definition of 'attack' in crypographic contexts, we have a set of issues
> here that left addressed will seriously harm the system going forward for
> the the significant monetary benefit of an exploiting party. I think that
> also satisfies a lay definition of the term: Something someone does, that
> none one expected, that makes them money at everyone elses expense.
> """
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>