public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andrew <onelineproof@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Selfish Mining Prevention
Date: Sat, 1 Sep 2018 00:11:19 +0000	[thread overview]
Message-ID: <CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com> (raw)

As I understand, selfish mining is an attack where miners collude to
mine at a lower hashrate then with all miners working independently.
What are the current strategies used to prevent this and what are the
future plans?

One idea I have is to let the block reward get "modulated" according
to peak hashrate. Say p is the peak hashrate for 365 periods (1 year)
consisting of 144 blocks, h is the hashrate of the last 144 block (1
day) period, and r is the base subsidy (12.5 BTC currently). You can
then make the max block reward 0.5 r (1 + h/p). So if hashrate is at
peak you get the full reward. Otherwise you get less, down to a min of
0.5 r.

If miners were to collude to mine at a lower than peak hashrate, then
they may be able to do it profitably for 144 blocks, but after that,
the reward would get modulated and it wouldn't be so much in their
interest to continue mining at the lower hashrate.

What flaws are there with this? I know it could be controversial due
to easier mining present for early miners, so maybe it would have to
be done in combination with a new more dynamic difficulty adjustment
algorithm. But I don't see how hashrate can continue rising
indefinitely, so a solution should be made for selfish mining.

Also when subsidies stop and a fee market is needed, I guess a portion
of the fees can be withheld for later if hashrate is not at peak.


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647


             reply	other threads:[~2018-09-01  0:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-01  0:11 Andrew [this message]
2018-09-13 23:19 ` [bitcoin-dev] Selfish Mining Prevention Andrew
2018-09-14 14:49   ` Moral Agent
2018-09-14 17:30     ` Andrew
2018-09-14 18:00       ` Moral Agent
2018-09-15  5:29   ` Damian Williamson
2018-09-15 16:01     ` Andrew
2018-09-15 22:45       ` Damian Williamson
2018-09-16 23:20         ` Eric Voskuil
2018-09-17 13:18           ` Andrew
2018-09-17 15:40             ` Eric Voskuil
2018-09-17 19:36             ` Eric Voskuil
2018-09-17 14:09 Zawy
2018-09-18 20:26 ` Andrew

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='CAL8tG=k+kXHMbQdUXO3BXKv7fQwp5t2QuaQut7sPUtEYgwzn0A@mail.gmail.com' \
    --to=onelineproof@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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