public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Timo Hanke <timo.hanke@web.de>
To: Bryan Bishop <kanzure@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function
Date: Thu, 6 Apr 2017 10:43:56 -0700	[thread overview]
Message-ID: <CAH6h1Lt=PKYxw-cWWeQGaTyLh2KAqU-o7eY9_WQbpanHJBxB7A@mail.gmail.com> (raw)
In-Reply-To: <CABaSBawbufi0p89OqRb57UoH51NxZxnZ7EcsJcQYAA8Tq3Qdfg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3684 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 5597 bytes --]

  reply	other threads:[~2017-04-06 17:43 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-05 21:37 [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function Gregory Maxwell
2017-04-05 23:05 ` theymos
2017-04-06  0:17   ` Gregory Maxwell
2017-04-06  0:39     ` Joseph Poon
2017-04-06  0:40       ` Joseph Poon
2017-04-06  1:32       ` Gregory Maxwell
2017-04-06  2:09         ` Joseph Poon
2017-04-05 23:25 ` Anthony Towns
2017-04-05 23:42 ` Joseph Poon
2017-04-06  2:10 ` Jonathan Toomim
2017-04-06 20:21   ` Jared Lee Richardson
2017-04-06  2:31 ` Peter Todd
2017-04-06  2:39   ` Bram Cohen
2017-04-06  2:49     ` Peter Todd
2017-04-06  3:11       ` Erik Aronesty
2017-04-06  3:23         ` Peter Todd
2017-04-06  3:23       ` David Vorick
2017-04-06  3:42         ` Peter Todd
2017-04-06  5:46         ` Thomas Daede
2017-04-06  6:24         ` Jonathan Toomim
2017-04-06 12:04           ` David Vorick
     [not found]           ` <CAMZUoK=oDAD9nhFAHkgncWtYxjBNh3qXbUffOH57QMnqjhmN6g@mail.gmail.com>
     [not found]             ` <CAMZUoKn8tr3LGbks0TnaCx9NTP6MZUzQ8PE6jDq1xiqpYyYwow@mail.gmail.com>
2017-04-06 13:55               ` Russell O'Connor
2017-04-06 16:49           ` Marco
2017-04-06 17:04           ` Alex Mizrahi
2017-04-06 17:13           ` Alex Mizrahi
2017-04-07 12:59             ` Jannes Faber
2017-04-07 13:28               ` Erik Aronesty
2017-04-06 17:31           ` Jared Lee Richardson
2017-04-06 17:26         ` Jared Lee Richardson
2017-04-06 15:36       ` Alex Mizrahi
2017-04-06 17:51     ` Jorge Timón
2017-04-06  7:24 ` bfd
2017-04-06  9:17 ` Luke Dashjr
2017-04-06 12:02 ` Luv Khemani
2017-04-06 12:11   ` Bryan Bishop
2017-04-06 17:43     ` Timo Hanke [this message]
2017-04-06 12:30   ` Luv Khemani
2017-04-06 15:15     ` Jorge Timón
2017-04-06 15:41       ` Daniel Robinson
2017-04-06 16:13 ` Andreas Schildbach
2017-04-06 21:38 ` Gregory Maxwell
2017-04-06  4:47 Oliver Petruzel
2017-04-06  4:49 Raystonn .
2017-04-06  7:47 ` praxeology_guy
2017-04-06 12:13   ` David Vorick
2017-04-07  1:34 Daniele Pinna
2017-04-07  6:46 ` Emilian Ursu
2017-04-07  7:44 ` Alex Mizrahi
2017-04-07  8:08 ` praxeology_guy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6h1Lt=PKYxw-cWWeQGaTyLh2KAqU-o7eY9_WQbpanHJBxB7A@mail.gmail.com' \
    --to=timo.hanke@web.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=kanzure@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox