Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.47 as permitted sender)
	client-ip=209.85.160.47; envelope-from=watsonbladd@gmail.com;
	helo=mail-pb0-f47.google.com; 
MIME-Version: 1.0
Sender: watsonbladd@gmail.com
In-Reply-To: <CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
References: <201206030052.17128.luke@dashjr.org>
	<CACsn0c=+xrVvGMAkPZffpVhRcAc09RuOW7LeOwi0TOD88VbuqQ@mail.gmail.com>
Date: Sat, 2 Jun 2012 22:40:41 -0500
Message-ID: <CACsn0cmvpY49R_nt=LhPaiOSFkL=Zywd-ZkUtOR9BK=hr2h1DQ@mail.gmail.com>
From: Watson Ladd <wbl@uchicago.edu>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [Bitcoin-development] Fwd: Defeating the block withholding attack
Precedence: list

On Sat, Jun 2, 2012 at 7:52 PM, Luke-Jr <luke@dashjr.org> wrote:
> Analysis, comments, constructive criticism, etc welcome for the following=
:
>
> =3D=3DBackground=3D=3D
> At present, an attacker can harm a pool by intentionally NOT submitting s=
hares
> that are also valid blocks. All pools are vulnerable to this attack, whet=
her
> centralized or decentralized and regardless of reward system used. The
> attack's effectiveness is proportional to ratio of the attacker's hashrat=
e 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 transa=
ction
> 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, an=
d
> since centralized pools can be harmful to the network's security, these r=
ule
> changes are not likely to gain enough acceptance among the greater Bitcoi=
n
> community.
>
> =3D=3DProposed Solution=3D=3D
> Please comment on the viability of this new proof-of-work algorithm, whic=
h I
> think should be viable for even decentralized pools:
>
> Blocks are accepted at a lower difficulty N (choosable by the pool; eg, t=
he
> share difficulty) iff they are submitted with a candidate for the next bl=
ock
> and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficult=
y 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, id=
eally
> by someone more qualified than me. M and N must be chosen prior to search=
ing
> 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 b=
eing
> a valid block at the time it is found, and that which ones are actually b=
locks
> 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 knowle=
dge
> of the shares/blocks themselves.
This further delays the finalization of a transaction. That's not a good th=
ing.
>
> =3D=3DBackward Compatibility=3D=3D
> Obviously, this change creates a hard-fork in the blockchain. I propose t=
hat
> 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=C2=A0 Liberty nor Safety."
-- Benjamin Franklin


--=20
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin