public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bram Cohen <bram@chia.net>
To: theartlav@gmail.com,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible?
Date: Mon, 18 Jun 2018 13:40:26 -0700	[thread overview]
Message-ID: <CAHUJnBAU2exMFgPTQx_+h_bktL3Z3B3rsh09aciVtRnGrHJBEw@mail.gmail.com> (raw)
In-Reply-To: <CAJRVQkDM390Y4sVzA8WwM93PY4UqUa8gvPKkT-iA2UcYL6FQ+g@mail.gmail.com>

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

Not sure what you're saying here. The block rate can't be particularly
increased or decreased in the long run due to the work difficulty
adjustment getting you roughly back where you started no matter what.
Someone could DOS the system by producing empty blocks, sure, that's a
central attack of what can happen when someone does a 51% attack with no
special countermeasures other than everything that Bitcoin does at its
core. An attacker or group of attackers could conspire to reduce block
sizes in order to increase transaction fees, in fact they could do that
with a miner activated soft fork. That appears both doable and given past
things which have happened with transaction fees in the past potentially
lucrative, particularly as block rewards fall in the future. Please don't
tell the big mining pools about it.

On Mon, Jun 18, 2018 at 11:39 AM Артём Литвинович via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dilution is a potential attack i randomly came up with in a Twitter
> arguement and couldn't find any references to or convincing arguments of it
> being implausible.
>
> Suppose a malicious actor were to acquire a majority of hash power, and
> proceed to use that hash power to produce valid, but empty blocks.
>
> As far as i understand it, this would effectively reduce the block rate by
> half or more and since nodes can't differentiate block relay and block
> production there would be nothing they can do to adjust difficulty or black
> list the attacker.
>
> At a rough estimate of $52 per TH equipment cost (Antminer pricing) and
> 12.5 BTC per 10 minutes power cost we are looking at an order of $2 billion
> of equipment and $0.4 billion a month of power costs (ignoring block
> reward) to maintain an attack - easily within means of even a minor
> government-scale actor.
>
> Is that a plausible scenario, or am i chasing a mirage? If it is
> plausible, what could be done to mitigate it?
>
>
> -Artem
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

  parent reply	other threads:[~2018-06-18 20:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-18 18:34 [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible? Артём Литвинович
2018-06-18 18:47 ` Alexander Leishman
2018-06-19 13:54   ` Eric Voskuil
2018-06-18 18:49 ` Laszlo Hanyecz
2018-06-18 20:40 ` Bram Cohen [this message]
2018-06-18 20:51   ` Bryan Bishop
2018-06-19 18:58 ` Richard Hein

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=CAHUJnBAU2exMFgPTQx_+h_bktL3Z3B3rsh09aciVtRnGrHJBEw@mail.gmail.com \
    --to=bram@chia.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=theartlav@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