From: "Luke-Jr" <luke@dashjr•org>
To: Mike Koss <mike@coinlab•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Defeating the block withholding attack
Date: Mon, 4 Jun 2012 21:05:25 +0000 [thread overview]
Message-ID: <201206042105.27064.luke@dashjr.org> (raw)
In-Reply-To: <CAErK2CjpSb=Rb+evWg+_fs0brBfTDe3_HM1z-an0picb_8tzpQ@mail.gmail.com>
On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> As I understand the attack, the attacker gets compensated for the shares
> they earn, but the pool will be denied any valid blocks found. The
> attacker DOES NOT have access to the Bitcoins earned in the unreported
> block (only the mining pool has access to the Coinbase address and
> transactions in the block).
With decentralized pools, the attacker does have access to the block, and can
potentially submit it to the Bitcoin network directly bypassing the pool if it
benefits them to do so.
> So it's a zero-net-cost attack for the attacker (but no chance of making a
> profit) to hurt the pool operator.
Because of the above, there is a possibility an attacker can make a profit.
> The only way to detect such an attack now is to look for "unlucky" miners;
> at the current difficulty, you can't detect this cheat until many millions
> of shares have been earned w/o a qualifying block. Since an attacker can
> also create many fake identities, they can avoid detection indefinitely by
> abandoning each account after a million earned shares.
There are other modes of detection, but nobody has bothered to implement them
since attackers can easily do a simple workaround in an arms race.
> I don't understand your proposal for fixing this. You would have to come
> up with a scheme where:
>
> - The miner can detect a qualifying hash to earn a share.
> - Not be able to tell if the hash is for a valid block.
With my proposal, miners can find shares, but won't know if it's a valid block
until the subsequent block is also found (that subsequent block might not end
up being a real block in the big picture).
> The way I would do this is to have a secret part (not shared with the
> miners) of a block that is part of the merkle hash, which is also used in a
> secondary hash. Difficulty is then divide into two parts: the first,
> solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes). And
> a second, solved by the pool (1 in Difficulty shares). A valid block would
> have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
> accepted.
This only works for centralized pools, which are contrary to the health of the
Bitcoin network. Decentralized pools cannot have a secret.
next prev parent reply other threads:[~2012-06-04 21:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-03 0:52 Luke-Jr
[not found] ` <CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
2012-06-03 3:40 ` [Bitcoin-development] Fwd: " Watson Ladd
2012-06-04 1:43 ` [Bitcoin-development] " Peter Vessenes
2012-06-04 2:04 ` Luke-Jr
2012-06-04 20:49 ` Mike Koss
2012-06-04 21:05 ` Luke-Jr [this message]
2012-06-05 0:00 ` Mike Koss
2012-06-05 1:05 ` Luke-Jr
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=201206042105.27064.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@coinlab$(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