From: Watson Ladd <wbl@uchicago•edu>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] Fwd: Defeating the block withholding attack
Date: Sat, 2 Jun 2012 22:40:41 -0500 [thread overview]
Message-ID: <CACsn0cmvpY49R_nt=LhPaiOSFkL=Zywd-ZkUtOR9BK=hr2h1DQ@mail.gmail.com> (raw)
In-Reply-To: <CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr <luke@dashjr•org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following:
>
> ==Background==
> At present, an attacker can harm a pool by intentionally NOT submitting shares
> that are also valid blocks. All pools are vulnerable to this attack, whether
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrate to
> the rest of the pool.
This attack has an obvious signature: getting outworked on the same
block as the pool was trying to verify, and always by the same person.
>
> There are obvious solutions that can be used to defeat this attack on
> centralized pools. For example, including a secret in the coinbase transaction
> that is accepted by the network as a partial preimage proof-of-work. All these
> solutions require changes to Bitcoin's proof-of-work acceptance terms, and
> since centralized pools can be harmful to the network's security, these rule
> changes are not likely to gain enough acceptance among the greater Bitcoin
> community.
>
> ==Proposed Solution==
> Please comment on the viability of this new proof-of-work algorithm, which I
> think should be viable for even decentralized pools:
>
> Blocks are accepted at a lower difficulty N (choosable by the pool; eg, the
> share difficulty) iff they are submitted with a candidate for the next block
> and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficulty M.
> The relationship between M and N must be comparable to the normal network
> difficulty; details on the specifics of this can be figured out later, ideally
> by someone more qualified than me. M and N must be chosen prior to searching
> for the block: it should be safe to steal some always-zero bytes from the
> prevblock header for this.
So the goal is to prevent the attacker double-dipping by submitting
cycles to the pool, which if he
found a correct answer he could submit himself. I don't see how this
does that: if he finds a valid
block he finds a valid block. Only if the operator has a secret is
this prevented.
>
> This algorithm should guarantee that every share has an equal chance of being
> a valid block at the time it is found, and that which ones are actually blocks
> cannot be known until the subsequent block is found. Thus, attackers have no
> way to identify which shares to withhold even while they have full knowledge
> of the shares/blocks themselves.
This further delays the finalization of a transaction. That's not a good thing.
>
> ==Backward Compatibility==
> Obviously, this change creates a hard-fork in the blockchain. I propose that
> if it solves the block withholding risk, the gain is sufficient that the
> community may approve a hard-fork to take place 1-2 years from consensus.
>
> Since mining continues to use a double-SHA256 on a fixed 80 byte header,
> existing miners, FPGAs, etc should work unmodified. Poolservers will need to
> adapt significantly.
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
next prev parent reply other threads:[~2012-06-03 3:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-03 0:52 [Bitcoin-development] " Luke-Jr
[not found] ` <CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
2012-06-03 3:40 ` Watson Ladd [this message]
2012-06-04 1:43 ` Peter Vessenes
2012-06-04 2:04 ` Luke-Jr
2012-06-04 20:49 ` Mike Koss
2012-06-04 21:05 ` Luke-Jr
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='CACsn0cmvpY49R_nt=LhPaiOSFkL=Zywd-ZkUtOR9BK=hr2h1DQ@mail.gmail.com' \
--to=wbl@uchicago$(echo .)edu \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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