diff options
| author | Mike Koss <mike@coinlab.com> | 2012-06-04 13:49:48 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-06-04 21:20:48 +0000 |
| commit | 1f9f372f488a756315dc1a56c8295b16f6ae598d (patch) | |
| tree | 1624a36213db594c4cfff47fc12523ba8fe8108b | |
| parent | 7c15ff0a3af1e572509cd70c4eb970e224d376d9 (diff) | |
| download | pi-bitcoindev-1f9f372f488a756315dc1a56c8295b16f6ae598d.tar.gz pi-bitcoindev-1f9f372f488a756315dc1a56c8295b16f6ae598d.zip | |
Re: [Bitcoin-development] Defeating the block withholding attack
| -rw-r--r-- | 92/311c2e647e22763bb4ad2126340d4af8a0416f | 261 |
1 files changed, 261 insertions, 0 deletions
diff --git a/92/311c2e647e22763bb4ad2126340d4af8a0416f b/92/311c2e647e22763bb4ad2126340d4af8a0416f new file mode 100644 index 000000000..5da36d5d6 --- /dev/null +++ b/92/311c2e647e22763bb4ad2126340d4af8a0416f @@ -0,0 +1,261 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mike@coinlab.com>) id 1Sbehk-0004zz-Jz + for bitcoin-development@lists.sourceforge.net; + Mon, 04 Jun 2012 21:20:48 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of coinlab.com + designates 209.85.216.175 as permitted sender) + client-ip=209.85.216.175; envelope-from=mike@coinlab.com; + helo=mail-qc0-f175.google.com; +Received: from mail-qc0-f175.google.com ([209.85.216.175]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Sbehj-0007YW-Hq + for bitcoin-development@lists.sourceforge.net; + Mon, 04 Jun 2012 21:20:48 +0000 +Received: by qcso7 with SMTP id o7so2668859qcs.34 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 04 Jun 2012 14:20:42 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=google.com; s=20120113; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type:x-gm-message-state; + bh=dzwqEUpxg7X9hNTd4KUbcFqONgkcSD+iPtl/NfxSovk=; + b=XjUn0oiHIaaE1NMtaxwC/zdPOQtDDJWCDWV4LsVsghRwvJL06gTDdDk9ULjkwo794h + RS1I7yc4EgLuqdMpQBScg4hvod/VgqqKzrAih23q3O/eTrbqMPsG2eSIKSpPqnEO2mIh + QWDWpAlMMnYw72pGtxHq31brhG4x7KrBQoTEYU7U/fumaC0NyBwDZwZuFeeQYy7k+IGo + LwIIyN3mFVNBm9EPLVDReWqeTemaWimx84xB2SBcYMrR9NGoN95/J9zMX7FAK1bdEzyh + eeITQdsUB+dmFN3E7t99n5+Kxl0f7zST7SNQqyWpSfHH5pQV6NdxD8STZ6G2HbJmVFrz + 4BaA== +MIME-Version: 1.0 +Received: by 10.224.96.82 with SMTP id g18mr14764553qan.0.1338842988647; Mon, + 04 Jun 2012 13:49:48 -0700 (PDT) +Received: by 10.229.242.14 with HTTP; Mon, 4 Jun 2012 13:49:48 -0700 (PDT) +In-Reply-To: <201206040204.57503.luke@dashjr.org> +References: <201206030052.17128.luke@dashjr.org> + <CAMGNxUu7SbnfpU8L+qp7KUmFLSU=VqcYGu2GhzRaYhkTT3Nz7A@mail.gmail.com> + <201206040204.57503.luke@dashjr.org> +Date: Mon, 4 Jun 2012 13:49:48 -0700 +Message-ID: <CAErK2CjpSb=Rb+evWg+_fs0brBfTDe3_HM1z-an0picb_8tzpQ@mail.gmail.com> +From: Mike Koss <mike@coinlab.com> +To: Luke-Jr <luke@dashjr.org> +Content-Type: multipart/alternative; boundary=20cf3074b3ecbf96db04c1abac4c +X-Gm-Message-State: ALoCoQmtUufDx3+1UveQ1SwmOyfcgGvPfwytQupk6hMavDR3S7bL0AU4EEaxgWNwEcKs3i3AvCB7 +X-Spam-Score: -0.5 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message +X-Headers-End: 1Sbehj-0007YW-Hq +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] Defeating the block withholding attack +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 04 Jun 2012 21:20:48 -0000 + +--20cf3074b3ecbf96db04c1abac4c +Content-Type: text/plain; charset=ISO-8859-1 + +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). + +So it's a zero-net-cost attack for the attacker (but no chance of making a +profit) to hurt the pool operator. 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. + +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. + +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 would be a very major change to the Block structure. Given that +attackers do not have direct monetary gain from this attack, I'm not sure +we can justify it at this point. + +On Sun, Jun 3, 2012 at 7:04 PM, Luke-Jr <luke@dashjr.org> wrote: + +> On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote: +> > Does it have asymmetric payoff for an attacker, that is, over time does +> it +> > pay them more to spend their hashes attacking than just mining? +> +> That depends on the pool's reward scheme. Some complicated forms are +> capable +> of getting "bonus" earnings out of the pool. Under all systems, the +> attacker +> at least gains the "hurt the pool" benefit. Given the frequency of DDoS +> attacks on pools, it is clear there are people who will even pay for +> attacks +> that provide no other benefit than harming pools. Under all systems, the +> attacker doesn't lose out in any significant way. +> +> > My gut is that it pays less well than mining, meaning I think this is +> > likely a small problem in the aggregate, and certainly not something we +> > should try and fork the blockchain for until there's real pain. +> +> If we wait until there's real pain, it will be a painful fork. If we plan +> it +> 1-2 years out, people have time to upgrade on their own before it breaks. +> +> > Consider, for instance, whether it pays better than just mining bitcoins +> > and spending those on 'bonuses' for getting users to switch from a pool +> you +> > hate. +> +> With this attack, attackers can hurt the pool's "luck factor" *and* spend +> the +> bitcoins they earn to bribe users away. +> +> +> ------------------------------------------------------------------------------ +> 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 +> + + + +-- +Mike Koss +CTO, CoinLab +(425) 246-7701 (m) + +A Bitcoin Primer <http://coinlab.com/a-bitcoin-primer.pdf> - What you need +to know about Bitcoins. + +--20cf3074b3ecbf96db04c1abac4c +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +As I understand the attack, the attacker gets compensated for the shares th= +ey earn, but the pool will be denied any valid blocks found. =A0The attacke= +r 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).<div> +<br></div><div>So it's a zero-net-cost attack for the attacker (but no = +chance of making a profit) to hurt the pool operator. =A0The only way to de= +tect such an attack now is to look for "unlucky" miners; at the c= +urrent difficulty, you can't detect this cheat until many millions of s= +hares have been earned w/o a qualifying block. =A0Since an attacker can als= +o create many fake identities, they can avoid detection indefinitely by aba= +ndoning each account after a million earned shares.</div> +<div><br></div><div>I don't understand your proposal for fixing this. = +=A0You would have to come up with a scheme where:</div><div><br></div><div>= +- The miner can detect a qualifying hash to earn a share.</div><div>- Not b= +e able to tell if the hash is for a valid block.</div> +<div><br></div><div>The way I would do this is to have a secret part (not s= +hared with the miners) of a block that is part of the merkle hash, which is= + also used in a secondary hash. =A0Difficulty is then divide into two parts= +: the first, solved by the miner (earning a "share" - e.g., 1 in = +4 Billion hashes). =A0And a second, solved by the pool (1 in Difficulty sha= +res). =A0A valid block would have to exhibit a valid Share Hash AND a valid= + Pool Hash in order to be accepted.</div> +<div><br></div><div>This would be a very major change to the Block structur= +e. =A0Given that attackers do not have direct monetary gain from this attac= +k, I'm not sure we can justify it at this point.</div><div><br><div cla= +ss=3D"gmail_quote"> +On Sun, Jun 3, 2012 at 7:04 PM, Luke-Jr <span dir=3D"ltr"><<a href=3D"ma= +ilto:luke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrot= +e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= +eft:1px #ccc solid;padding-left:1ex"> +<div class=3D"im">On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote:= +<br> +> Does it have asymmetric payoff for an attacker, that is, over time doe= +s it<br> +> pay them more to spend their hashes attacking than just mining?<br> +<br> +</div>That depends on the pool's reward scheme. Some complicated forms = +are capable<br> +of getting "bonus" earnings out of the pool. Under all systems, t= +he attacker<br> +at least gains the "hurt the pool" benefit. Given the frequency o= +f DDoS<br> +attacks on pools, it is clear there are people who will even pay for attack= +s<br> +that provide no other benefit than harming pools. Under all systems, the<br= +> +attacker doesn't lose out in any significant way.<br> +<div class=3D"im"><br> +> My gut is that it pays less well than mining, meaning I think this is<= +br> +> likely a small problem in the aggregate, and certainly not something w= +e<br> +> should try and fork the blockchain for until there's real pain.<br= +> +<br> +</div>If we wait until there's real pain, it will be a painful fork. If= + we plan it<br> +1-2 years out, people have time to upgrade on their own before it breaks.<b= +r> +<div class=3D"im"><br> +> Consider, for instance, whether it pays better than just mining bitcoi= +ns<br> +> and spending those on 'bonuses' for getting users to switch fr= +om a pool you<br> +> hate.<br> +<br> +</div>With this attack, attackers can hurt the pool's "luck factor= +" *and* spend the<br> +bitcoins they earn to bribe users away.<br> +<div class=3D"HOEnZb"><div class=3D"h5"><br> +---------------------------------------------------------------------------= +---<br> +Live Security Virtual Conference<br> +Exclusive live event will cover all the ways today's security and<br> +threat landscape has changed and how IT managers can respond. Discussions<b= +r> +will include endpoint security, mobile security and the latest in malware<b= +r> +threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226= +3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122= +263/</a><br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br> +</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>= +Mike Koss<div>CTO, CoinLab</div><div>(425) 246-7701 (m)</div><div><br></div= +><div><a href=3D"http://coinlab.com/a-bitcoin-primer.pdf" target=3D"_blank"= +>A Bitcoin Primer</a>=A0- What you need to know about Bitcoins.</div> +<br> +</div> + +--20cf3074b3ecbf96db04c1abac4c-- + + |