From: Peter Todd <pete@petertodd•org>
To: Multipool Admin <admin@multipool•us>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Date: Mon, 28 Dec 2015 11:12:28 -0800 [thread overview]
Message-ID: <20151228191228.GC12298@muck> (raw)
In-Reply-To: <CAP3QyGJD3SaM6Bvvw66jAvVFkQhrfJfRQTxbbe8a=O1zK_P6tw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote:
> Any attempt to 'fix' this problem, would most likely require changes to all
> mining software, why not just make mining more decentralized in general?
>
> For example, allow anyone to submit proofs of work to Bitcoind that are
> some fraction of the network difficulty and receive payment for them if
> they're valid. This would also encourage the proliferation of full nodes
> since anyone could solo mine again. Then, the next coinbase transaction
> could be split among, say, the top 100 proofs of work.
That's certainly be a good place to be, but the design of Bitcoin
currently makes achieving that goal fundementally difficult.
> Eligius already does their miner payouts like this.
>
> If you want to fix an issue with mining, fix the selfish mining issue first
> as it's a much larger and more dangerous potential issue.
Do you specifically mean selfish mining as defined in Emin Gün
Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant
issue in a scenario - one malicious miner with >30% hashing power -
where you're already very close to the margins anyway; the difference
between a 50% attack threshold and a 30% attack threshold isn't very
significant.
Far more concerning is network propagation effects between large and
small miners. For that class of issues, if you are in an environemnt
where selfish mining is possible - a fairly flat, easily DoS/sybil
attacked network topology - the profitability difference between small
and large miners even *without* attacks going on is a hugely worrying
problem. OTOH, if you're blocksize is small enough that propagation time
is negligable to profitability, then selfish mining attacks with <30%
hashing power aren't much of a concern - they'll be naturally defeated
by anti-DoS/anti-sybil measures.
> I don't believe it was ever clearly established whether Eligius suffered a
> block withholding attack or was just the victim of a miner with (what was,
> at the time) a large amount of faulty hardware, however, from the
> Bitcointalk threads at the time I believe it was assumed to be the latter.
I think the latter was assumed as well, although ruling out of the
former is impossible.
Note though that Eligius is *not* the only pool to have had problems
with block withholding, though AFAIK Eligius is the only one who has
gone on record so far. (as I said in my original post, I'm relaying
information given to me under condition of confidentiality)
--
'peter'[:-1]@petertodd.org
000000000000000004a36565fb282c4bd06dda61329fda2465b0bfeaf7241dab
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-12-28 19:12 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-19 18:42 Peter Todd
2015-12-19 19:30 ` Bob McElrath
2015-12-19 20:03 ` jl2012
2015-12-20 3:34 ` Chris Priest
2015-12-20 3:36 ` Matt Corallo
2015-12-20 3:43 ` Chris Priest
2015-12-20 4:44 ` Peter Todd
2015-12-26 8:12 ` Multipool Admin
2015-12-27 4:10 ` Geir Harald Hansen
2015-12-28 19:12 ` Peter Todd [this message]
2015-12-28 19:30 ` Emin Gün Sirer
2015-12-28 19:35 ` Multipool Admin
2015-12-28 19:33 ` Multipool Admin
2015-12-28 20:26 ` Ivan Brightly
2015-12-29 18:59 ` Dave Scotese
2015-12-29 19:08 ` Jonathan Toomim
2015-12-29 19:25 ` Allen Piscitello
2015-12-29 21:51 ` Dave Scotese
2015-12-20 3:40 ` jl2012
2015-12-20 3:47 ` Chris Priest
2015-12-20 4:24 ` jl2012
2015-12-20 5:12 ` Emin Gün Sirer
2015-12-20 7:39 ` Chris Priest
2015-12-20 7:56 ` Emin Gün Sirer
2015-12-20 8:30 ` Natanael
2015-12-20 11:38 ` Tier Nolan
2015-12-20 12:42 ` Natanael
2015-12-20 15:30 ` Tier Nolan
2015-12-20 13:28 ` Peter Todd
2015-12-20 17:00 ` Emin Gün Sirer
2015-12-21 11:39 ` Jannes Faber
2015-12-25 11:15 ` Ittay
2015-12-25 12:00 ` Jonathan Toomim
2015-12-25 12:02 ` benevolent
2015-12-25 16:11 ` Jannes Faber
2015-12-26 0:38 ` Geir Harald Hansen
2015-12-28 20:02 ` Peter Todd
2015-12-26 8:23 ` Eric Lombrozo
2015-12-26 8:26 ` Eric Lombrozo
2015-12-26 15:33 ` Jorge Timón
2015-12-26 17:38 ` Eric Lombrozo
2015-12-26 18:01 ` Jorge Timón
2015-12-26 16:09 ` Tier Nolan
2015-12-26 18:30 ` Eric Lombrozo
2015-12-26 19:34 ` Jorge Timón
2015-12-26 21:22 ` Jonathan Toomim
2015-12-27 4:33 ` Emin Gün Sirer
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=20151228191228.GC12298@muck \
--to=pete@petertodd$(echo .)org \
--cc=admin@multipool$(echo .)us \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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