From: Natanael <natanael.l@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] We need to fix the block withholding attack
Date: Sun, 20 Dec 2015 13:42:10 +0100 [thread overview]
Message-ID: <CAAt2M19QwL1AyH=pVARGa0zYKUtRM9hz8vXUzyZb05E5EhQMeA@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OU=18VuV+9U9meg5fRxQt3MZnAnQ2jPN5QBNk+ZtSoJXw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org>:
>
> On Sun, Dec 20, 2015 at 5:12 AM, Emin Gün Sirer <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> An attacker pool (A) can take a certain portion of its hashpower,
>> use it to mine on behalf of victim pool (B), furnish partial proofs of
work
>> to B, but discard any full blocks it discovers.
>
> I wonder if part of the problem here is that there is no pool identity
linked to mining pools.
>
> If the mining protocols were altered so that miners had to indicate their
identity, then a pool couldn't forward hashing power to their victim.
Our approaches can be combined.
Each pool (or solo miner) has a public key included in their blocks that
identifies them to their miners (solo miners can use their own unique
random keys every time). This public key may be registered with DNSSEC+DANE
and the pool could point to their domain in the block template as an
identifier.
For each block the pool generates a nonce, and for each of every miner's
workers it double-hashes that nonce with their own public key and that
miner's worker ID and the previous block hash (to ensure no accidental
overlapping work is done).
The double-hash is a commitment hash, the first hash is the committed value
to be used by the pool as described below. Publishing the nonce reveals how
the hashes were derived to their miners.
Each miner puts this commitment hash in their blocks, and also the public
key of the pool separately as mentioned above.
Here's where it differs from standard mining: both the candidate block PoW
hash and the pool's commitment value above determines block validity
together.
If total difficulty is X and the ratio for full blocks to candidate blocks
shared with the pool is Y, then the candidate block PoW now has to meet X/Y
while hashing the candidate block PoW + the pool's commitment hash must
meet Y, which together makes for X/Y*Y and thus the same total difficulty.
So now miners don't know if their blocks are valid before the pool does, so
withholding isn't effective, and the public key identifiers simultaneously
stops a pool from telling honest but naive miners to attack other pools
using whatever other schemes one might come up with.
The main differences are that there's a public key identifier the miners
are told about in advance and expect to see in block templates, and that
that now the pool has to publish this commitment value together with the
block that also contains the commitment hash, and that this is verified
together with the PoW.
[-- Attachment #2: Type: text/html, Size: 3043 bytes --]
next prev parent reply other threads:[~2015-12-20 12:42 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
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 [this message]
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='CAAt2M19QwL1AyH=pVARGa0zYKUtRM9hz8vXUzyZb05E5EhQMeA@mail.gmail.com' \
--to=natanael.l@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tier.nolan@gmail$(echo .)com \
/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