* [bitcoin-dev] We need to fix the block withholding attack
@ 2015-12-19 18:42 Peter Todd
2015-12-19 19:30 ` Bob McElrath
` (2 more replies)
0 siblings, 3 replies; 47+ messages in thread
From: Peter Todd @ 2015-12-19 18:42 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2125 bytes --]
At the recent Scaling Bitcoin conference in Hong Kong we had a chatham
house rules workshop session attending by representitives of a super
majority of the Bitcoin hashing power.
One of the issues raised by the pools present was block withholding
attacks, which they said are a real issue for them. In particular, pools
are receiving legitimate threats by bad actors threatening to use block
withholding attacks against them. Pools offering their services to the
general public without anti-privacy Know-Your-Customer have little
defense against such attacks, which in turn is a threat to the
decentralization of hashing power: without pools only fairly large
hashing power installations are profitable as variance is a very real
business expense. P2Pool is often brought up as a replacement for pools,
but it itself is still relatively vulnerable to block withholding, and
in any case has many other vulnerabilities and technical issues that has
prevented widespread adoption of P2Pool.
Fixing block withholding is relatively simple, but (so far) requires a
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should
do this hard-fork in conjunction with any blocksize increase, which will
have the desirable side effect of clearly show consent by the entire
ecosystem, SPV clients included.
Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block
witholding attacks are a good thing, as in their model they can be used
by small pools against larger pools, disincentivising large pools.
However this argument is academic and not applicable to the real world,
as a much simpler defense against block withholding attacks is to use
anti-privacy KYC and the legal system combined with the variety of
withholding detection mechanisms only practical for large pools.
Equally, large hashing power installations - a dangerous thing for
decentralization - have no block withholding attack vulnerabilities.
1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/
--
'peter'[:-1]@petertodd.org
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 47+ messages in thread* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-19 18:42 [bitcoin-dev] We need to fix the block withholding attack Peter Todd @ 2015-12-19 19:30 ` Bob McElrath 2015-12-19 20:03 ` jl2012 2015-12-20 3:34 ` Chris Priest 2 siblings, 0 replies; 47+ messages in thread From: Bob McElrath @ 2015-12-19 19:30 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev Peter Todd via bitcoin-dev [bitcoin-dev@lists•linuxfoundation.org] wrote: > One of the issues raised by the pools present was block withholding > attacks, which they said are a real issue for them. In particular, pools > are receiving legitimate threats by bad actors threatening to use block > withholding attacks against them. The only possible other bad actors are other miners. So who are the "bad actor" miners? It's a short list of candidates. > P2Pool is often brought up as a replacement for pools, but it itself is still > relatively vulnerable to block withholding, and in any case has many other > vulnerabilities and technical issues that has prevented widespread adoption of > P2Pool. I've been trying to understand this source of "vulnerabilities and technical issues" with p2pool and have received a lot of contradictory information. Can someone in the know summarize what the problems with p2pool are? The economic situation where miners can be deprived of profit due to the lack of synchronicity in block updates is a physics problem due to the size of the Earth and will never be removed. This is a design flaw in Bitcoin. Therefore a different, more comprehensive solution is called for. My solution to this is somewhat longer term and needs more simulation but fundamentally removes the source of contention and fixes the design flaw, while remaining as close "in spirit" to bitcoin as possible: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/2_breaking_the_chain_1_mcelrath.pdf Not only does block withholding simply not work to deny other miners income due to the absence of orphans, but I explicitly added a dis-incentive against withholding blocks in terms of the "cohort difficulty". Other graph-theoretic quantities are in general possible in the reward function to better align the incentives of miners with the correct operation of the system. Also by lowering the target difficulty and increasing the block (bead) rate, one lowers the variance of miner income. Part of the reason I ask is that there has been some interest in testing my ideas in p2pool itself (or a new similar share pool), but I'm failing to understand the source of all the complaints about p2pool. -- Cheers, Bob McElrath "For every complex problem, there is a solution that is simple, neat, and wrong." -- H. L. Mencken ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-19 18:42 [bitcoin-dev] We need to fix the block withholding attack Peter Todd 2015-12-19 19:30 ` Bob McElrath @ 2015-12-19 20:03 ` jl2012 2015-12-20 3:34 ` Chris Priest 2 siblings, 0 replies; 47+ messages in thread From: jl2012 @ 2015-12-19 20:03 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev After the meeting I find a softfork solution. It is very inefficient and I am leaving it here just for record. 1. In the first output of the second transaction of a block, mining pool will commit a random nonce with an OP_RETURN. 2. Mine as normal. When a block is found, the hash is concatenated with the committed random nonce and hashed. 3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the block is invalid. That means about 1% of blocks are discarded. 4. For each difficulty retarget, the secondary target is decreased by 2 ^ 1/64. 5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ 252. Therefore only 1 in 16 hash returned by hasher is really valid. This should make the detection of block withholding attack much easier. All miners have to sacrifice 1% reward for 10 years. Confirmation will also be 1% slower than it should be. If a node (full or SPV) is not updated, it becomes more vulnerable as an attacker could mine a chain much faster without following the new rules. But this is still a softfork, by definition. --------------- ok, back to topic. Do you mean this? http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html Peter Todd via bitcoin-dev 於 2015-12-19 13:42 寫到: > At the recent Scaling Bitcoin conference in Hong Kong we had a chatham > house rules workshop session attending by representitives of a super > majority of the Bitcoin hashing power. > > One of the issues raised by the pools present was block withholding > attacks, which they said are a real issue for them. In particular, > pools > are receiving legitimate threats by bad actors threatening to use block > withholding attacks against them. Pools offering their services to the > general public without anti-privacy Know-Your-Customer have little > defense against such attacks, which in turn is a threat to the > decentralization of hashing power: without pools only fairly large > hashing power installations are profitable as variance is a very real > business expense. P2Pool is often brought up as a replacement for > pools, > but it itself is still relatively vulnerable to block withholding, and > in any case has many other vulnerabilities and technical issues that > has > prevented widespread adoption of P2Pool. > > Fixing block withholding is relatively simple, but (so far) requires a > SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should > do this hard-fork in conjunction with any blocksize increase, which > will > have the desirable side effect of clearly show consent by the entire > ecosystem, SPV clients included. > > > Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block > witholding attacks are a good thing, as in their model they can be used > by small pools against larger pools, disincentivising large pools. > However this argument is academic and not applicable to the real world, > as a much simpler defense against block withholding attacks is to use > anti-privacy KYC and the legal system combined with the variety of > withholding detection mechanisms only practical for large pools. > Equally, large hashing power installations - a dangerous thing for > decentralization - have no block withholding attack vulnerabilities. > > 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-19 18:42 [bitcoin-dev] We need to fix the block withholding attack 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:40 ` jl2012 2 siblings, 2 replies; 47+ messages in thread From: Chris Priest @ 2015-12-20 3:34 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-dev Block witholding attacks are only possible if you have a majority of hashpower. If you only have 20% hashpower, you can't do this attack. Currently, this attack is only a theoretical attack, as the ones with all the hashpower today are not engaging in this behavior. Even if someone who had a lot of hashpower decided to pull off this attack, they wouldn't be able to disrupt much. Once that time comes, then I think this problem should be solved, until then it should be a low priority. There are more important things to work on in the meantime. On 12/19/15, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > At the recent Scaling Bitcoin conference in Hong Kong we had a chatham > house rules workshop session attending by representitives of a super > majority of the Bitcoin hashing power. > > One of the issues raised by the pools present was block withholding > attacks, which they said are a real issue for them. In particular, pools > are receiving legitimate threats by bad actors threatening to use block > withholding attacks against them. Pools offering their services to the > general public without anti-privacy Know-Your-Customer have little > defense against such attacks, which in turn is a threat to the > decentralization of hashing power: without pools only fairly large > hashing power installations are profitable as variance is a very real > business expense. P2Pool is often brought up as a replacement for pools, > but it itself is still relatively vulnerable to block withholding, and > in any case has many other vulnerabilities and technical issues that has > prevented widespread adoption of P2Pool. > > Fixing block withholding is relatively simple, but (so far) requires a > SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should > do this hard-fork in conjunction with any blocksize increase, which will > have the desirable side effect of clearly show consent by the entire > ecosystem, SPV clients included. > > > Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block > witholding attacks are a good thing, as in their model they can be used > by small pools against larger pools, disincentivising large pools. > However this argument is academic and not applicable to the real world, > as a much simpler defense against block withholding attacks is to use > anti-privacy KYC and the legal system combined with the variety of > withholding detection mechanisms only practical for large pools. > Equally, large hashing power installations - a dangerous thing for > decentralization - have no block withholding attack vulnerabilities. > > 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 3:34 ` Chris Priest @ 2015-12-20 3:36 ` Matt Corallo 2015-12-20 3:43 ` Chris Priest 2015-12-20 3:40 ` jl2012 1 sibling, 1 reply; 47+ messages in thread From: Matt Corallo @ 2015-12-20 3:36 UTC (permalink / raw) To: Chris Priest; +Cc: bitcoin-dev Peter was referring to pool-block-withholding, not selfish mining. On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >Block witholding attacks are only possible if you have a majority of >hashpower. If you only have 20% hashpower, you can't do this attack. >Currently, this attack is only a theoretical attack, as the ones with >all the hashpower today are not engaging in this behavior. Even if >someone who had a lot of hashpower decided to pull off this attack, >they wouldn't be able to disrupt much. Once that time comes, then I >think this problem should be solved, until then it should be a low >priority. There are more important things to work on in the meantime. > >On 12/19/15, Peter Todd via bitcoin-dev ><bitcoin-dev@lists•linuxfoundation.org> wrote: >> At the recent Scaling Bitcoin conference in Hong Kong we had a >chatham >> house rules workshop session attending by representitives of a super >> majority of the Bitcoin hashing power. >> >> One of the issues raised by the pools present was block withholding >> attacks, which they said are a real issue for them. In particular, >pools >> are receiving legitimate threats by bad actors threatening to use >block >> withholding attacks against them. Pools offering their services to >the >> general public without anti-privacy Know-Your-Customer have little >> defense against such attacks, which in turn is a threat to the >> decentralization of hashing power: without pools only fairly large >> hashing power installations are profitable as variance is a very real >> business expense. P2Pool is often brought up as a replacement for >pools, >> but it itself is still relatively vulnerable to block withholding, >and >> in any case has many other vulnerabilities and technical issues that >has >> prevented widespread adoption of P2Pool. >> >> Fixing block withholding is relatively simple, but (so far) requires >a >> SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We >should >> do this hard-fork in conjunction with any blocksize increase, which >will >> have the desirable side effect of clearly show consent by the entire >> ecosystem, SPV clients included. >> >> >> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block >> witholding attacks are a good thing, as in their model they can be >used >> by small pools against larger pools, disincentivising large pools. >> However this argument is academic and not applicable to the real >world, >> as a much simpler defense against block withholding attacks is to use >> anti-privacy KYC and the legal system combined with the variety of >> withholding detection mechanisms only practical for large pools. >> Equally, large hashing power installations - a dangerous thing for >> decentralization - have no block withholding attack vulnerabilities. >> >> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ >> >> -- >> 'peter'[:-1]@petertodd.org >> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d >> >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists•linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 3:36 ` Matt Corallo @ 2015-12-20 3:43 ` Chris Priest 2015-12-20 4:44 ` Peter Todd 0 siblings, 1 reply; 47+ messages in thread From: Chris Priest @ 2015-12-20 3:43 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-dev Then shouldn't this be something the pool deals with, not the bitcoin protocol? On 12/19/15, Matt Corallo <lf-lists@mattcorallo•com> wrote: > Peter was referring to pool-block-withholding, not selfish mining. > > On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: >>Block witholding attacks are only possible if you have a majority of >>hashpower. If you only have 20% hashpower, you can't do this attack. >>Currently, this attack is only a theoretical attack, as the ones with >>all the hashpower today are not engaging in this behavior. Even if >>someone who had a lot of hashpower decided to pull off this attack, >>they wouldn't be able to disrupt much. Once that time comes, then I >>think this problem should be solved, until then it should be a low >>priority. There are more important things to work on in the meantime. >> >>On 12/19/15, Peter Todd via bitcoin-dev >><bitcoin-dev@lists•linuxfoundation.org> wrote: >>> At the recent Scaling Bitcoin conference in Hong Kong we had a >>chatham >>> house rules workshop session attending by representitives of a super >>> majority of the Bitcoin hashing power. >>> >>> One of the issues raised by the pools present was block withholding >>> attacks, which they said are a real issue for them. In particular, >>pools >>> are receiving legitimate threats by bad actors threatening to use >>block >>> withholding attacks against them. Pools offering their services to >>the >>> general public without anti-privacy Know-Your-Customer have little >>> defense against such attacks, which in turn is a threat to the >>> decentralization of hashing power: without pools only fairly large >>> hashing power installations are profitable as variance is a very real >>> business expense. P2Pool is often brought up as a replacement for >>pools, >>> but it itself is still relatively vulnerable to block withholding, >>and >>> in any case has many other vulnerabilities and technical issues that >>has >>> prevented widespread adoption of P2Pool. >>> >>> Fixing block withholding is relatively simple, but (so far) requires >>a >>> SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We >>should >>> do this hard-fork in conjunction with any blocksize increase, which >>will >>> have the desirable side effect of clearly show consent by the entire >>> ecosystem, SPV clients included. >>> >>> >>> Note that Ittay Eyal and Emin Gun Sirer have argued(1) that block >>> witholding attacks are a good thing, as in their model they can be >>used >>> by small pools against larger pools, disincentivising large pools. >>> However this argument is academic and not applicable to the real >>world, >>> as a much simpler defense against block withholding attacks is to use >>> anti-privacy KYC and the legal system combined with the variety of >>> withholding detection mechanisms only practical for large pools. >>> Equally, large hashing power installations - a dangerous thing for >>> decentralization - have no block withholding attack vulnerabilities. >>> >>> 1) http://hackingdistributed.com/2014/12/03/the-miners-dilemma/ >>> >>> -- >>> 'peter'[:-1]@petertodd.org >>> 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d >>> >>_______________________________________________ >>bitcoin-dev mailing list >>bitcoin-dev@lists•linuxfoundation.org >>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 3:43 ` Chris Priest @ 2015-12-20 4:44 ` Peter Todd 2015-12-26 8:12 ` Multipool Admin 0 siblings, 1 reply; 47+ messages in thread From: Peter Todd @ 2015-12-20 4:44 UTC (permalink / raw) To: Chris Priest; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 437 bytes --] On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via bitcoin-dev wrote: > Then shouldn't this be something the pool deals with, not the bitcoin protocol? There is no known way for pools - especially ones that allow anonymous hashers - to effectively prevent block withholding attacks without changing the Bitcoin protocol. -- 'peter'[:-1]@petertodd.org 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 0 siblings, 2 replies; 47+ messages in thread From: Multipool Admin @ 2015-12-26 8:12 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1731 bytes --] Any attempt to 'fix' this problem, would most likely require changes to all mining software, why not just make mining more decentralized in general? For example, allow anyone to submit proofs of work to Bitcoind that are some fraction of the network difficulty and receive payment for them if they're valid. This would also encourage the proliferation of full nodes since anyone could solo mine again. Then, the next coinbase transaction could be split among, say, the top 100 proofs of work. Eligius already does their miner payouts like this. If you want to fix an issue with mining, fix the selfish mining issue first as it's a much larger and more dangerous potential issue. I don't believe it was ever clearly established whether Eligius suffered a block withholding attack or was just the victim of a miner with (what was, at the time) a large amount of faulty hardware, however, from the Bitcointalk threads at the time I believe it was assumed to be the latter. --Adam On Sat, Dec 19, 2015 at 8:44 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via bitcoin-dev > wrote: > > Then shouldn't this be something the pool deals with, not the bitcoin > protocol? > > There is no known way for pools - especially ones that allow anonymous > hashers - to effectively prevent block withholding attacks without > changing the Bitcoin protocol. > > -- > 'peter'[:-1]@petertodd.org > 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2562 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 8:12 ` Multipool Admin @ 2015-12-27 4:10 ` Geir Harald Hansen 2015-12-28 19:12 ` Peter Todd 1 sibling, 0 replies; 47+ messages in thread From: Geir Harald Hansen @ 2015-12-27 4:10 UTC (permalink / raw) To: bitcoin-dev Last I heard it was believed the miner had made their own mining client and that the block withholding was a bug, not an intended feature. On 26.12.2015 09:12, Multipool Admin via bitcoin-dev wrote: > Any attempt to 'fix' this problem, would most likely require changes to > all mining software, why not just make mining more decentralized in general? > > For example, allow anyone to submit proofs of work to Bitcoind that are > some fraction of the network difficulty and receive payment for them if > they're valid. This would also encourage the proliferation of full > nodes since anyone could solo mine again. Then, the next coinbase > transaction could be split among, say, the top 100 proofs of work. > > Eligius already does their miner payouts like this. > > If you want to fix an issue with mining, fix the selfish mining issue > first as it's a much larger and more dangerous potential issue. > > I don't believe it was ever clearly established whether Eligius suffered > a block withholding attack or was just the victim of a miner with (what > was, at the time) a large amount of faulty hardware, however, from the > Bitcointalk threads at the time I believe it was assumed to be the latter. > > --Adam > > > On Sat, Dec 19, 2015 at 8:44 PM, Peter Todd via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org>> wrote: > > On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via > bitcoin-dev wrote: > > Then shouldn't this be something the pool deals with, not the bitcoin protocol? > > There is no known way for pools - especially ones that allow anonymous > hashers - to effectively prevent block withholding attacks without > changing the Bitcoin protocol. > > -- > 'peter'[:-1]@petertodd.org <http://petertodd.org> > 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Peter Todd @ 2015-12-28 19:12 UTC (permalink / raw) To: Multipool Admin; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2658 bytes --] On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote: > Any attempt to 'fix' this problem, would most likely require changes to all > mining software, why not just make mining more decentralized in general? > > For example, allow anyone to submit proofs of work to Bitcoind that are > some fraction of the network difficulty and receive payment for them if > they're valid. This would also encourage the proliferation of full nodes > since anyone could solo mine again. Then, the next coinbase transaction > could be split among, say, the top 100 proofs of work. That's certainly be a good place to be, but the design of Bitcoin currently makes achieving that goal fundementally difficult. > Eligius already does their miner payouts like this. > > If you want to fix an issue with mining, fix the selfish mining issue first > as it's a much larger and more dangerous potential issue. Do you specifically mean selfish mining as defined in Emin Gün Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant issue in a scenario - one malicious miner with >30% hashing power - where you're already very close to the margins anyway; the difference between a 50% attack threshold and a 30% attack threshold isn't very significant. Far more concerning is network propagation effects between large and small miners. For that class of issues, if you are in an environemnt where selfish mining is possible - a fairly flat, easily DoS/sybil attacked network topology - the profitability difference between small and large miners even *without* attacks going on is a hugely worrying problem. OTOH, if you're blocksize is small enough that propagation time is negligable to profitability, then selfish mining attacks with <30% hashing power aren't much of a concern - they'll be naturally defeated by anti-DoS/anti-sybil measures. > I don't believe it was ever clearly established whether Eligius suffered a > block withholding attack or was just the victim of a miner with (what was, > at the time) a large amount of faulty hardware, however, from the > Bitcointalk threads at the time I believe it was assumed to be the latter. I think the latter was assumed as well, although ruling out of the former is impossible. Note though that Eligius is *not* the only pool to have had problems with block withholding, though AFAIK Eligius is the only one who has gone on record so far. (as I said in my original post, I'm relaying information given to me under condition of confidentiality) -- 'peter'[:-1]@petertodd.org 000000000000000004a36565fb282c4bd06dda61329fda2465b0bfeaf7241dab [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 2 siblings, 1 reply; 47+ messages in thread From: Emin Gün Sirer @ 2015-12-28 19:30 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2307 bytes --] On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Do you specifically mean selfish mining as defined in Emin Gün > Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant > issue in a scenario - one malicious miner with >30% hashing power - > where you're already very close to the margins anyway; the difference > between a 50% attack threshold and a 30% attack threshold isn't very > significant. > This is not quite right: we know that selfish mining is a guaranteed win at 34%. We do not know when exactly it begins to pay off. The more consolidated and centralized the other mining pools, the less of a threat it is below 34%; the more decentralized, the more likely it is to pay off at lower thresholds. Far more concerning is network propagation effects between large and > small miners. On a related note, the Bitcoin-NG paper took a big step towards moving these kinds of concerns out of the realm of gut-feelings and wavy hands into science. In particular, it introduced metrics for fairness (i.e. differential rate in orphans experienced by small and large miners), hash power efficiency, as well as consensus delay. > For that class of issues, if you are in an environemnt > where selfish mining is possible - a fairly flat, easily DoS/sybil > attacked network topology - the profitability difference between small > and large miners even *without* attacks going on is a hugely worrying > problem. Indeed, there is a slight, quantifiable benefit to larger pools. Which is why we need to be diligent about not letting pools get too big. > Note though that Eligius is *not* the only pool to have had problems > with block withholding, though AFAIK Eligius is the only one who has > gone on record so far. (as I said in my original post, I'm relaying > information given to me under condition of confidentiality) > I can see why they don't want to go public with this: it means that they are less profitable than other pools. It still looks to me like Ittay's discovery is doing exactly the right thing: this pool will need to be more careful when signing up new people, curbing its otherwise steady march towards the 51% boundary. - egs - egs [-- Attachment #2: Type: text/html, Size: 3453 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-28 19:30 ` Emin Gün Sirer @ 2015-12-28 19:35 ` Multipool Admin 0 siblings, 0 replies; 47+ messages in thread From: Multipool Admin @ 2015-12-28 19:35 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2731 bytes --] On Mon, Dec 28, 2015 at 11:30 AM, Emin Gün Sirer < bitcoin-dev@lists•linuxfoundation.org> wrote: > > > On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Do you specifically mean selfish mining as defined in Emin Gün >> Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant >> issue in a scenario - one malicious miner with >30% hashing power - >> where you're already very close to the margins anyway; the difference >> between a 50% attack threshold and a 30% attack threshold isn't very >> significant. >> > > This is not quite right: we know that selfish mining is a guaranteed win > at 34%. We do not know when exactly it begins to pay off. The more > consolidated and centralized the other mining pools, the less of a threat > it is below 34%; the more decentralized, the more likely it is to pay off > at lower thresholds. > Exactly. > Far more concerning is network propagation effects between large and >> small miners. > > > On a related note, the Bitcoin-NG paper took a big step towards moving > these kinds of concerns out of the realm of gut-feelings and wavy hands > into science. In particular, it introduced metrics for fairness (i.e. > differential > rate in orphans experienced by small and large miners), hash power > efficiency, as well as consensus delay. > > >> For that class of issues, if you are in an environemnt >> where selfish mining is possible - a fairly flat, easily DoS/sybil >> attacked network topology - the profitability difference between small >> and large miners even *without* attacks going on is a hugely worrying >> problem. > > > Indeed, there is a slight, quantifiable benefit to larger pools. Which is > why > we need to be diligent about not letting pools get too big. > > >> Note though that Eligius is *not* the only pool to have had problems >> > with block withholding, though AFAIK Eligius is the only one who has >> gone on record so far. (as I said in my original post, I'm relaying >> information given to me under condition of confidentiality) >> > > I can see why they don't want to go public with this: it means that they > are less profitable than other pools. > This I disagree with -- if they know that they have been attacked, then there is every reason to come forward with this information. First of all, it offers an explanation for poor profits (this is better than unexplained poor profits). Second of all, if one pool can be attacked then any pool can be attacked -- this is not a reason not to mine on a particular pool. If anything, it's a reason to diversify hashrate among many pools. --Adam [-- Attachment #2: Type: text/html, Size: 4374 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-28 19:12 ` Peter Todd 2015-12-28 19:30 ` Emin Gün Sirer @ 2015-12-28 19:33 ` Multipool Admin 2015-12-28 20:26 ` Ivan Brightly 2 siblings, 0 replies; 47+ messages in thread From: Multipool Admin @ 2015-12-28 19:33 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3937 bytes --] On Mon, Dec 28, 2015 at 11:12 AM, Peter Todd <pete@petertodd•org> wrote: > On Sat, Dec 26, 2015 at 12:12:13AM -0800, Multipool Admin wrote: > > Any attempt to 'fix' this problem, would most likely require changes to > all > > mining software, why not just make mining more decentralized in general? > > > > For example, allow anyone to submit proofs of work to Bitcoind that are > > some fraction of the network difficulty and receive payment for them if > > they're valid. This would also encourage the proliferation of full nodes > > since anyone could solo mine again. Then, the next coinbase transaction > > could be split among, say, the top 100 proofs of work. > > That's certainly be a good place to be, but the design of Bitcoin > currently makes achieving that goal fundementally difficult. > Agreed, however I don't think it would be impossible or even really that difficult, and would be a great way to increase decentralization while simultaneously fixing other issues with mining. Proofs of work would be valid if they're built on top of the current block hash, and we could require (difficulty/N) proofs of work that are >= (difficulty/N) to assemble a valid block. Same as mining shares work. The block assembler who finds the final diff/N 'share' could get a small bonus as an incentive to complete the block as quickly as possible. Or alternatively, a checksum could be computed of all the current diff/N shares in the mempool and that way only the final share would need to be broadcasted to the entire network, and clients with the correct checksum could assemble the block themselves without having to download the entire block. This would drastically decrease data usage on the network. > Eligius already does their miner payouts like this. > > > > If you want to fix an issue with mining, fix the selfish mining issue > first > > as it's a much larger and more dangerous potential issue. > > Do you specifically mean selfish mining as defined in Emin Gün > Sirer/Ittay Eyal's paper? Keep in mind that attack is only a significant > issue in a scenario - one malicious miner with >30% hashing power - > where you're already very close to the margins anyway; the difference > between a 50% attack threshold and a 30% attack threshold isn't very > significant. > Yes, that's what I'm talking about. > Far more concerning is network propagation effects between large and > small miners. For that class of issues, if you are in an environemnt > where selfish mining is possible - a fairly flat, easily DoS/sybil > attacked network topology - the profitability difference between small > and large miners even *without* attacks going on is a hugely worrying > problem. OTOH, if you're blocksize is small enough that propagation time > is negligable to profitability, then selfish mining attacks with <30% > hashing power aren't much of a concern - they'll be naturally defeated > by anti-DoS/anti-sybil measures. > The possibility that a previously 'good' actor with 30% of the hashpower going 'rogue' becomes more and more of a concern as the block subsidy decreases. > > I don't believe it was ever clearly established whether Eligius suffered > a > > block withholding attack or was just the victim of a miner with (what > was, > > at the time) a large amount of faulty hardware, however, from the > > Bitcointalk threads at the time I believe it was assumed to be the > latter. > > I think the latter was assumed as well, although ruling out of the > former is impossible. > > Note though that Eligius is *not* the only pool to have had problems > with block withholding, though AFAIK Eligius is the only one who has > gone on record so far. (as I said in my original post, I'm relaying > information given to me under condition of confidentiality) > What is the incentive not to go on record about this? --Adam [-- Attachment #2: Type: text/html, Size: 5019 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-28 19:12 ` Peter Todd 2015-12-28 19:30 ` Emin Gün Sirer 2015-12-28 19:33 ` Multipool Admin @ 2015-12-28 20:26 ` Ivan Brightly 2015-12-29 18:59 ` Dave Scotese 2 siblings, 1 reply; 47+ messages in thread From: Ivan Brightly @ 2015-12-28 20:26 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1205 bytes --] > > On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > Far more concerning is network propagation effects between large and > small miners. For that class of issues, if you are in an environemnt > where selfish mining is possible - a fairly flat, easily DoS/sybil > attacked network topology - the profitability difference between small > and large miners even *without* attacks going on is a hugely worrying > problem. OTOH, if you're blocksize is small enough that propagation time > is negligable to profitability, then selfish mining attacks with <30% > hashing power aren't much of a concern - they'll be naturally defeated > by anti-DoS/anti-sybil measures. > Let's agree that one factor in mining profitability is bandwidth/network reliability/stability. Why focus on that vs electricity contracts or vertically integrated chip manufacturers? Surely, sufficient network bandwidth is a more broadly available commodity than <$0.02/kwh electricity, for example. I'm not sure that your stranded hydroelectric miner is any more desirable than thousands of dorm room miners with access to 10gbit university connections and free electricity. [-- Attachment #2: Type: text/html, Size: 1643 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 0 siblings, 2 replies; 47+ messages in thread From: Dave Scotese @ 2015-12-29 18:59 UTC (permalink / raw) To: Ivan Brightly; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3026 bytes --] There have been no decent objections to altering the block-selection mechanism (when two block solutions appear at nearly the same time) as described at http://bitcoin.stackexchange.com/questions/39226 Key components are: - Compute BitcoinDaysDestroyed using only transactions that have been in your mempool for some time as oBTCDD ("old BTCDD"). - Use "nearly the same time" to mean separated in time by your guess of the average duration of block propagation times. - When two block solutions come in at nearly the same time, build on the one that has the most oBTCDD, rather than the one that came in first. The goal of this change is to reduce the profitability of withholding block solutions by severely reducing the chances that a block solved a while ago can orphan one solved recently. "Came in first" seems more easily gamed than "most oBTCDD". As I wrote there, "*old coins* is always a dwindling resource and *global nodes willing to help cheat* is probably a growing one." I will write a BIP if anyone agrees it's a good idea. On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> Far more concerning is network propagation effects between large and >> small miners. For that class of issues, if you are in an environemnt >> where selfish mining is possible - a fairly flat, easily DoS/sybil >> attacked network topology - the profitability difference between small >> and large miners even *without* attacks going on is a hugely worrying >> problem. OTOH, if you're blocksize is small enough that propagation time >> is negligable to profitability, then selfish mining attacks with <30% >> hashing power aren't much of a concern - they'll be naturally defeated >> by anti-DoS/anti-sybil measures. >> > > Let's agree that one factor in mining profitability is bandwidth/network > reliability/stability. Why focus on that vs electricity contracts or > vertically integrated chip manufacturers? Surely, sufficient network > bandwidth is a more broadly available commodity than <$0.02/kwh > electricity, for example. I'm not sure that your stranded hydroelectric > miner is any more desirable than thousands of dorm room miners with access > to 10gbit university connections and free electricity. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto [-- Attachment #2: Type: text/html, Size: 4367 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-29 18:59 ` Dave Scotese @ 2015-12-29 19:08 ` Jonathan Toomim 2015-12-29 19:25 ` Allen Piscitello 1 sibling, 0 replies; 47+ messages in thread From: Jonathan Toomim @ 2015-12-29 19:08 UTC (permalink / raw) To: Dave Scotese; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 4043 bytes --] Ultimately, a self-interested miner will chose to build on the block that leaves the most transaction fees up for grabs. (This usually means the smallest block.) It's an interesting question whether the default behavior for Core should be the rational behavior (build on the "smallest" block in terms of fees) or some other supposedly altruistic behavior (most BTCDD). This also applies to the decision of the "same time" threshold -- a selfish miner will not care if the blocks arrived at about the same time or not. I currently do not have a strong opinion on what that behavior should be, although if the blocksize limit were increased substantially, I may prefer the selfish behavior because it ends up also being fail-safe (punishes selfish mining using large blocks or fee-stealing attempts). On Dec 29, 2015, at 10:59 AM, Dave Scotese via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > There have been no decent objections to altering the block-selection mechanism (when two block solutions appear at nearly the same time) as described at > > http://bitcoin.stackexchange.com/questions/39226 > > Key components are: > Compute BitcoinDaysDestroyed using only transactions that have been in your mempool for some time as oBTCDD ("old BTCDD"). > Use "nearly the same time" to mean separated in time by your guess of the average duration of block propagation times. > When two block solutions come in at nearly the same time, build on the one that has the most oBTCDD, rather than the one that came in first. > The goal of this change is to reduce the profitability of withholding block solutions by severely reducing the chances that a block solved a while ago can orphan one solved recently. "Came in first" seems more easily gamed than "most oBTCDD". As I wrote there, "old coins is always a dwindling resource and global nodes willing to help cheat is probably a growing one." > > I will write a BIP if anyone agrees it's a good idea. > > > On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Far more concerning is network propagation effects between large and > small miners. For that class of issues, if you are in an environemnt > where selfish mining is possible - a fairly flat, easily DoS/sybil > attacked network topology - the profitability difference between small > and large miners even *without* attacks going on is a hugely worrying > problem. OTOH, if you're blocksize is small enough that propagation time > is negligable to profitability, then selfish mining attacks with <30% > hashing power aren't much of a concern - they'll be naturally defeated > by anti-DoS/anti-sybil measures. > > Let's agree that one factor in mining profitability is bandwidth/network reliability/stability. Why focus on that vs electricity contracts or vertically integrated chip manufacturers? Surely, sufficient network bandwidth is a more broadly available commodity than <$0.02/kwh electricity, for example. I'm not sure that your stranded hydroelectric miner is any more desirable than thousands of dorm room miners with access to 10gbit university connections and free electricity. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > -- > I like to provide some work at no charge to prove my value. Do you need a techie? > I own Litmocracy and Meme Racing (in alpha). > I'm the webmaster for The Voluntaryist which now accepts Bitcoin. > I also code for The Dollar Vigilante. > "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #1.2: Type: text/html, Size: 5875 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 1 sibling, 1 reply; 47+ messages in thread From: Allen Piscitello @ 2015-12-29 19:25 UTC (permalink / raw) To: Dave Scotese; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3459 bytes --] How could this possibly be enforced? On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > There have been no decent objections to altering the block-selection > mechanism (when two block solutions appear at nearly the same time) as > described at > > http://bitcoin.stackexchange.com/questions/39226 > > Key components are: > > - Compute BitcoinDaysDestroyed using only transactions that have been > in your mempool for some time as oBTCDD ("old BTCDD"). > - Use "nearly the same time" to mean separated in time by your guess > of the average duration of block propagation times. > - When two block solutions come in at nearly the same time, build on > the one that has the most oBTCDD, rather than the one that came in first. > > The goal of this change is to reduce the profitability of withholding > block solutions by severely reducing the chances that a block solved a > while ago can orphan one solved recently. "Came in first" seems more > easily gamed than "most oBTCDD". As I wrote there, "*old coins* is > always a dwindling resource and *global nodes willing to help cheat* is > probably a growing one." > > I will write a BIP if anyone agrees it's a good idea. > > On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < >>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>> Far more concerning is network propagation effects between large and >>> small miners. For that class of issues, if you are in an environemnt >>> where selfish mining is possible - a fairly flat, easily DoS/sybil >>> attacked network topology - the profitability difference between small >>> and large miners even *without* attacks going on is a hugely worrying >>> problem. OTOH, if you're blocksize is small enough that propagation time >>> is negligable to profitability, then selfish mining attacks with <30% >>> hashing power aren't much of a concern - they'll be naturally defeated >>> by anti-DoS/anti-sybil measures. >>> >> >> Let's agree that one factor in mining profitability is bandwidth/network >> reliability/stability. Why focus on that vs electricity contracts or >> vertically integrated chip manufacturers? Surely, sufficient network >> bandwidth is a more broadly available commodity than <$0.02/kwh >> electricity, for example. I'm not sure that your stranded hydroelectric >> miner is any more desirable than thousands of dorm room miners with access >> to 10gbit university connections and free electricity. >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > > -- > I like to provide some work at no charge to prove my value. Do you need a > techie? > I own Litmocracy <http://www.litmocracy.com> and Meme Racing > <http://www.memeracing.net> (in alpha). > I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> > which now accepts Bitcoin. > I also code for The Dollar Vigilante <http://dollarvigilante.com/>. > "He ought to find it more profitable to play by the rules" - Satoshi > Nakamoto > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 5343 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-29 19:25 ` Allen Piscitello @ 2015-12-29 21:51 ` Dave Scotese 0 siblings, 0 replies; 47+ messages in thread From: Dave Scotese @ 2015-12-29 21:51 UTC (permalink / raw) To: Allen Piscitello; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4540 bytes --] It cannot possibly be enforced. Enforcement is not important when you're setting defaults. In fact, you don't want to enforce defaults, but rather allow anyone who cares to deviate from them to do so. The importance of default behavior is proportional to the number of folks who mess with the defaults, and that, among miners, is pretty small as far as I know, at least in the area of deciding how to decide which block to build on when two show up at nearly the same time. On Tue, Dec 29, 2015 at 11:25 AM, Allen Piscitello < allen.piscitello@gmail•com> wrote: > How could this possibly be enforced? > > On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> There have been no decent objections to altering the block-selection >> mechanism (when two block solutions appear at nearly the same time) as >> described at >> >> http://bitcoin.stackexchange.com/questions/39226 >> >> Key components are: >> >> - Compute BitcoinDaysDestroyed using only transactions that have been >> in your mempool for some time as oBTCDD ("old BTCDD"). >> - Use "nearly the same time" to mean separated in time by your guess >> of the average duration of block propagation times. >> - When two block solutions come in at nearly the same time, build on >> the one that has the most oBTCDD, rather than the one that came in first. >> >> The goal of this change is to reduce the profitability of withholding >> block solutions by severely reducing the chances that a block solved a >> while ago can orphan one solved recently. "Came in first" seems more >> easily gamed than "most oBTCDD". As I wrote there, "*old coins* is >> always a dwindling resource and *global nodes willing to help cheat* is >> probably a growing one." >> >> I will write a BIP if anyone agrees it's a good idea. >> >> On Mon, Dec 28, 2015 at 12:26 PM, Ivan Brightly via bitcoin-dev < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >>> On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev < >>>> bitcoin-dev@lists•linuxfoundation.org> wrote: >>>> Far more concerning is network propagation effects between large and >>>> small miners. For that class of issues, if you are in an environemnt >>>> where selfish mining is possible - a fairly flat, easily DoS/sybil >>>> attacked network topology - the profitability difference between small >>>> and large miners even *without* attacks going on is a hugely worrying >>>> problem. OTOH, if you're blocksize is small enough that propagation time >>>> is negligable to profitability, then selfish mining attacks with <30% >>>> hashing power aren't much of a concern - they'll be naturally defeated >>>> by anti-DoS/anti-sybil measures. >>>> >>> >>> Let's agree that one factor in mining profitability is bandwidth/network >>> reliability/stability. Why focus on that vs electricity contracts or >>> vertically integrated chip manufacturers? Surely, sufficient network >>> bandwidth is a more broadly available commodity than <$0.02/kwh >>> electricity, for example. I'm not sure that your stranded hydroelectric >>> miner is any more desirable than thousands of dorm room miners with access >>> to 10gbit university connections and free electricity. >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >> >> >> -- >> I like to provide some work at no charge to prove my value. Do you need a >> techie? >> I own Litmocracy <http://www.litmocracy.com> and Meme Racing >> <http://www.memeracing.net> (in alpha). >> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> >> which now accepts Bitcoin. >> I also code for The Dollar Vigilante <http://dollarvigilante.com/>. >> "He ought to find it more profitable to play by the rules" - Satoshi >> Nakamoto >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > -- I like to provide some work at no charge to prove my value. Do you need a techie? I own Litmocracy <http://www.litmocracy.com> and Meme Racing <http://www.memeracing.net> (in alpha). I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which now accepts Bitcoin. I also code for The Dollar Vigilante <http://dollarvigilante.com/>. "He ought to find it more profitable to play by the rules" - Satoshi Nakamoto [-- Attachment #2: Type: text/html, Size: 6910 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 3:34 ` Chris Priest 2015-12-20 3:36 ` Matt Corallo @ 2015-12-20 3:40 ` jl2012 2015-12-20 3:47 ` Chris Priest 1 sibling, 1 reply; 47+ messages in thread From: jl2012 @ 2015-12-20 3:40 UTC (permalink / raw) To: Chris Priest; +Cc: bitcoin-dev Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: > Block witholding attacks are only possible if you have a majority of > hashpower. If you only have 20% hashpower, you can't do this attack. > Currently, this attack is only a theoretical attack, as the ones with > all the hashpower today are not engaging in this behavior. Even if > someone who had a lot of hashpower decided to pull off this attack, > they wouldn't be able to disrupt much. Once that time comes, then I > think this problem should be solved, until then it should be a low > priority. There are more important things to work on in the meantime. > This is not true. For a pool with 5% total hash rate, an attacker only needs 0.5% of hash rate to sabotage 10% of their income. It's already enough to kill the pool ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 3:40 ` jl2012 @ 2015-12-20 3:47 ` Chris Priest 2015-12-20 4:24 ` jl2012 0 siblings, 1 reply; 47+ messages in thread From: Chris Priest @ 2015-12-20 3:47 UTC (permalink / raw) To: jl2012; +Cc: bitcoin-dev On 12/19/15, jl2012 <jl2012@xbt•hk> wrote: > Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: >> Block witholding attacks are only possible if you have a majority of >> hashpower. If you only have 20% hashpower, you can't do this attack. >> Currently, this attack is only a theoretical attack, as the ones with >> all the hashpower today are not engaging in this behavior. Even if >> someone who had a lot of hashpower decided to pull off this attack, >> they wouldn't be able to disrupt much. Once that time comes, then I >> think this problem should be solved, until then it should be a low >> priority. There are more important things to work on in the meantime. >> > > This is not true. For a pool with 5% total hash rate, an attacker only > needs 0.5% of hash rate to sabotage 10% of their income. It's already > enough to kill the pool > > This begs the question: If this is such a devastating attack, then why hasn't this attack brought down every pool in existence? As far as I'm aware, there are many pools in operation despite this possibility. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 3:47 ` Chris Priest @ 2015-12-20 4:24 ` jl2012 2015-12-20 5:12 ` Emin Gün Sirer 0 siblings, 1 reply; 47+ messages in thread From: jl2012 @ 2015-12-20 4:24 UTC (permalink / raw) To: Chris Priest; +Cc: bitcoin-dev, nbvfour Chris Priest 於 2015-12-19 22:47 寫到: > On 12/19/15, jl2012 <jl2012@xbt•hk> wrote: >> Chris Priest via bitcoin-dev 於 2015-12-19 22:34 寫到: >>> Block witholding attacks are only possible if you have a majority of >>> hashpower. If you only have 20% hashpower, you can't do this attack. >>> Currently, this attack is only a theoretical attack, as the ones with >>> all the hashpower today are not engaging in this behavior. Even if >>> someone who had a lot of hashpower decided to pull off this attack, >>> they wouldn't be able to disrupt much. Once that time comes, then I >>> think this problem should be solved, until then it should be a low >>> priority. There are more important things to work on in the meantime. >>> >> >> This is not true. For a pool with 5% total hash rate, an attacker only >> needs 0.5% of hash rate to sabotage 10% of their income. It's already >> enough to kill the pool >> >> > > This begs the question: If this is such a devastating attack, then why > hasn't this attack brought down every pool in existence? As far as I'm > aware, there are many pools in operation despite this possibility. It did happen: https://www.reddit.com/r/Bitcoin/comments/28242v/eligius_falls_victim_to_blocksolution_withholding/ The worst thing is that the proof for such attack is probabilistic, not deterministic. A smarter attacker may even pretend to be many small miners, make it even more difficult or impossible to prove who are attacking. > Then shouldn't this be something the pool deals with, not the bitcoin > protocol? The only solution is to ask for KYC registration, unless one could propose a cryptographic solution that does not require a consensus fork. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 4:24 ` jl2012 @ 2015-12-20 5:12 ` Emin Gün Sirer 2015-12-20 7:39 ` Chris Priest ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Emin Gün Sirer @ 2015-12-20 5:12 UTC (permalink / raw) To: jl2012; +Cc: Bitcoin Dev, nbvfour [-- Attachment #1: Type: text/plain, Size: 3416 bytes --] There's quite a bit of confusion in this thread. Peter is referring to block withholding attacks. Ittay Eyal (as sole author -- I was not involved in this paper [1]) was the first to analyze these attacks and to discover a fascinating, paradoxical result. 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. If A picks the amount of attacking hashpower judiciously, it can make more money using this attack, than it would if it were to use 100% of its hashpower for its own mining. This last sentence should sound non-sensical to most of you, at least, it did to me. Ittay did the math, and his paper can tell you exactly how much of your hashpower you need to peel off and use to attack another open pool, and you will come out ahead. Chris Priest is confusing these attacks with selfish mining, and further, his characterization of selfish mining is incorrect. Selfish Mining is guaranteed to yield profits for any pool over 33% (as a result, Nick Szabo has dubbed this the "34% attack") and it may pay off even below that point if the attacker is well-positioned in the network; or it may not, depending on the makeup of the rest of the pools as well as the network characteristics (the more centralized and bigger the other pools are, the less likely it is to pay off). There was a lot of noise in the community when the SM paper came out, so there are tons of incorrect response narrative out there. By now, everyone who seems to be Bitcoin competent sees SM as a concern, and Ethereum has already adopted our fix. I'd have hoped that a poster to this list would be better informed than to repeat the claim that "majority will protect Bitcoin" to refute a paper whose title is "majority is not enough." Back to Ittay's paradoxical discovery: We have seen pool-block withholding attacks before; I believe Eligius caught one case. I don't believe that any miners will deploy strong KYC measures, and even if they did, I don't believe that these measures will be effective, at least, as long as the attacker is somewhat savvy. The problem with these attacks are that statistics favor the attackers. Is someone really discarding the blocks they find, or are they just unlucky? This is really hard to tell for small miners. Even with KYC, one could break up one's servers, register them under different people's names, and tunnel them through VPNs. Keep in mind that when an open pool gets big, like GHash did and two other pools did before them, the only thing at our disposal used to be to yell at people about centralization until they left the big pools and reformed into smaller groups. Not only was such yelling kind of desperate looking, it wasn't incredibly effective, either. We had no protocol mechanisms that put pressure on big pools to stop signing up people. Ittay's discovery changed that: pools that get to be very big by indiscriminately signing up miners are likely to be infiltrated and their profitability will drop. And Peter's post is evidence that this is, indeed, happening as predicted. This is a good outcome, it puts pressure on the big pools to not grow. Peter, you allude to a specific suggestion from Luke-Jr. Can you please describe what it is? Hope this is useful, - egs [1] https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf [-- Attachment #2: Type: text/html, Size: 4291 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 11:38 ` Tier Nolan 2015-12-20 13:28 ` Peter Todd 2 siblings, 1 reply; 47+ messages in thread From: Chris Priest @ 2015-12-20 7:39 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: Bitcoin Dev On 12/19/15, Emin Gün Sirer <el33th4x0r@gmail•com> wrote: > > Chris Priest is confusing these attacks with selfish mining, and further, > his characterization of selfish mining is incorrect. Selfish Mining is > guaranteed to yield profits for any pool over 33% (as a result, Nick > Szabo has dubbed this the "34% attack") and it may pay off even > below that point if the attacker is well-positioned in the network; > or it may not, depending on the makeup of the rest of the pools > as well as the network characteristics (the more centralized > and bigger the other pools are, the less likely it is to pay off). There > was a lot of noise in the community when the SM paper came out, > so there are tons of incorrect response narrative out there. By now, > everyone who seems to be Bitcoin competent sees SM as a > concern, and Ethereum has already adopted our fix. I'd have hoped > that a poster to this list would be better informed than to repeat the > claim that "majority will protect Bitcoin" to refute a paper whose title > is "majority is not enough." http://www.coindesk.com/bitcoin-mining-network-vulnerability/ just sayin'... But anyways, I agree with you on the rest of your email. This is only really an attack from the perspective of the mining pool. From the user's perspective, its not an attack at all. Imagine your aunt who has bitcoin on a SPV wallet on her iphone. Does she care that two mining pools are attacking each other? Its has nothing to do with her, and it has nothing to do with most users or bitcoin either. From the bitcoin user's perspective, the mining pool landscape *should* be constantly changing. Fixing this "attack" is promoting mining pool statism. Existing mining pools will have an advantage over up and coming mining pools. That is not an advantage that is best for bitcoin from the user's perspective. Now, on the other hand, if this technique is used so much, it results in too many pools getting shut down such that the difficulty starts to decrease, *then* maybe it might be time to start thinking about fixing this issue. The difficulty dropping means the security of the network is decreased, which *does* have an effect on every user. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 7:39 ` Chris Priest @ 2015-12-20 7:56 ` Emin Gün Sirer 2015-12-20 8:30 ` Natanael 0 siblings, 1 reply; 47+ messages in thread From: Emin Gün Sirer @ 2015-12-20 7:56 UTC (permalink / raw) To: Chris Priest; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 715 bytes --] Initial reactions aren't always accurate, people's views change, and science has its insurmountable way of convincing people. Gavin [1] and others [2] now cite selfish mining as a concern in the block size debate, and more importantly, the paper has been peer-reviewed, cited, and even built-upon [3]. Let's elevate the discussion, shall we? [1] Here's Gavin concerned about selfish mining: http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners [2] Here's Adam: http://bitcoin-development.narkive.com/mvI8Wpjp/dynamic-limit-to-the-block-size-bip-draft-discussion [3] This is a very nice extension of our work: Ayelet Sapirshtein, Yonatan Sompolinsky, Aviv Zohar: http://arxiv.org/abs/1507.06183 [-- Attachment #2: Type: text/html, Size: 1259 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 7:56 ` Emin Gün Sirer @ 2015-12-20 8:30 ` Natanael 0 siblings, 0 replies; 47+ messages in thread From: Natanael @ 2015-12-20 8:30 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 858 bytes --] Wouldn't block withhold be fixed by not letting miners in pools know which block candidates are valid before the pool knows? (Note: I haven't read any other proposals for how to fix it, this may already be known) As an example, by having the pool use the unique per-miner nonces sent to each miner for effective division of labor as a kind of seed / commitment value, where one in X block candidates will be valid, where X is the current ratio between partial PoW blocks sent as mining proofs and the full difficulty? The computational work of the pool remains low (checking this isn't harder than the partial PoW validation already performed), they pool simply looks at which commitment value from the pool that the miner used, looks up the correct committed value and hashes that together with the partial PoW. If it hits the target, the block is valid. [-- Attachment #2: Type: text/html, Size: 925 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 5:12 ` Emin Gün Sirer 2015-12-20 7:39 ` Chris Priest @ 2015-12-20 11:38 ` Tier Nolan 2015-12-20 12:42 ` Natanael 2015-12-20 13:28 ` Peter Todd 2 siblings, 1 reply; 47+ messages in thread From: Tier Nolan @ 2015-12-20 11:38 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1862 bytes --] 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. If the various mining protocols were updated, they could allow checking that the work has the domain name of the pool included. Pools would have to include their domain name in the block header. A pool which provides this service is publicly saying that they will not use the block withholding attack. Any two pools which are doing it cannot attack each other (since they have different domain names). This creates an incentive for pools to start supporting the feature. Owners of hashing power also have an incentive to operate with pools which offer this identity. It means that they can ensure that they get a payout from any blocks found. Hosted mining is weaker, but even then, it is possible for mining hosts to provide proof that they performed mining. This proof would include the identity of the mining pool. Even if the pool was run by the host, it would still need to have the name embedded. Mining hosts might be able to figure out which of their customers actually check the identity info, and then they could redirect the mining power of those who generally don't check. If customers randomly ask for all of the hashing power, right back to when they joined, then this becomes expensive. Mining power directly owned by the pool is also immune to this effect. [-- Attachment #2: Type: text/html, Size: 2330 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 11:38 ` Tier Nolan @ 2015-12-20 12:42 ` Natanael 2015-12-20 15:30 ` Tier Nolan 0 siblings, 1 reply; 47+ messages in thread From: Natanael @ 2015-12-20 12:42 UTC (permalink / raw) To: Tier Nolan; +Cc: Bitcoin Dev [-- 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 --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 12:42 ` Natanael @ 2015-12-20 15:30 ` Tier Nolan 0 siblings, 0 replies; 47+ messages in thread From: Tier Nolan @ 2015-12-20 15:30 UTC (permalink / raw) Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1661 bytes --] On Sun, Dec 20, 2015 at 12:42 PM, Natanael <natanael.l@gmail•com> wrote: > 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. This gives the same total difficulty but miners are throwing away otherwise valid blocks. This means that it is technically a soft fork. All new blocks are valid according to the old rule. In practice, it is kind of a hard fork. If Y is 10, then all upgraded miners are throwing away 90% of the blocks that are valid under the old rules. From the perspective of non-upgraded clients, the upgraded miners operate at a 10X disadvantage. This means that someone with 15% of the network power has a majority of the effective hashing power, since 15% is greater than 8.5% (85% * 0.1). The slow roll-out helps mitigate this though. It gives non-upgraded clients time to react. If there is only a 5% difference initially, then the attacker doesn't get much benefit. 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. I don't think public keys are strictly required. Registering them with DNSSEC is way over the top. They can just publish the key on their website and then use that for their identity. [-- Attachment #2: Type: text/html, Size: 2401 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 5:12 ` Emin Gün Sirer 2015-12-20 7:39 ` Chris Priest 2015-12-20 11:38 ` Tier Nolan @ 2015-12-20 13:28 ` Peter Todd 2015-12-20 17:00 ` Emin Gün Sirer 2015-12-26 8:23 ` Eric Lombrozo 2 siblings, 2 replies; 47+ messages in thread From: Peter Todd @ 2015-12-20 13:28 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: nbvfour, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5348 bytes --] On Sun, Dec 20, 2015 at 12:12:49AM -0500, Emin Gün Sirer via bitcoin-dev wrote: > There's quite a bit of confusion in this thread. > > Peter is referring to block withholding attacks. Ittay Eyal (as sole > author -- I was not involved in this paper [1]) was the first Ah, thanks for the correction. > to analyze these attacks and to discover a fascinating, paradoxical > result. 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. If A picks the amount of > attacking hashpower judiciously, it can make more money using this > attack, than it would if it were to use 100% of its hashpower for its own > mining. This last sentence should sound non-sensical to most of you, > at least, it did to me. Ittay did the math, and his paper can tell you > exactly how much of your hashpower you need to peel off and use > to attack another open pool, and you will come out ahead. Now to be clear, I'm not saying any of the above isn't true - it's a fascinating result. But the hashing/mining ecosystem is significantly more complex than just pools. > Back to Ittay's paradoxical discovery: > > We have seen pool-block withholding attacks before; I believe Eligius > caught one case. I don't believe that any miners will deploy strong KYC > measures, and even if they did, I don't believe that these measures > will be effective, at least, as long as the attacker is somewhat savvy. > The problem with these attacks are that statistics favor the attackers. > Is someone really discarding the blocks they find, or are they just > unlucky? This is really hard to tell for small miners. Even with KYC, > one could break up one's servers, register them under different > people's names, and tunnel them through VPNs. There are a number of techniques that can be used to detect block withholding attacks that you are not aware of. These techniques usually have the characteristic that if known they can be avoided, so obviously those who know about them are highly reluctant to reveal what exactly they are. I personally know about some of them and have been asked to keep that information secret, which I will. In the context of KYC, this techniques would likely hold up in court, which means that if this stuff becomes a more serious problem it's perfectly viable for large, well-resourced, pools to prevent block withholding attacks, in part by removing anonymity of hashing power. This would not be a positive development for the ecosystem. Secondly, DRM tech can also easily be used to prevent block withholding attacks by attesting to the honest of the hashing power. This is being discussed in the industry, and again, this isn't a positive development for the ecosystem. > Keep in mind that when an open pool gets big, like GHash did and > two other pools did before them, the only thing at our disposal used > to be to yell at people about centralization until they left the big > pools and reformed into smaller groups. Not only was such yelling > kind of desperate looking, it wasn't incredibly effective, either. > We had no protocol mechanisms that put pressure on big pools to > stop signing up people. Ittay's discovery changed that: pools that > get to be very big by indiscriminately signing up miners are likely to > be infiltrated and their profitability will drop. And Peter's post is > evidence that this is, indeed, happening as predicted. This is a > good outcome, it puts pressure on the big pools to not grow. GHash.io was not a pure pool - they owned and operated a significant amount of physical hashing power, and it's not at all clear that their % of the network actually went down following that 51% debacle. Currently a significant % of the hashing power - possibly a majority - is in the form of large hashing installations whose owners individually, and definitely in trusting groups, have enough hashing power to solo mine. Eyal's results indicate those miners have incentives to attack pools, and additionally they have the incentive of killing off pools to make it difficult for new competition to get established, yet they themselves are not vulnerable to that attack. Moving to a state where new hashing power can't be brought online except in large quantities is not a positive development for the ecosystem. This is also way I described the suggestion that Eyal's results are a good thing as academic - while the idea hypothetically works in a pure open pool vs. open pool scenario, the real world is significantly more complex than that simple model. > Peter, you allude to a specific suggestion from Luke-Jr. Can you > please describe what it is? Basically you have the pool pick a secret k for each share, and commit to H(k) in the share. Additionally the share commits to a target divider D. The PoW validity rule is then changed from H(block header) < T, to be H(block header) < T * D && H(H(block header) + k) < max_int / D Because the hasher doesn't know what k is, they don't know which shares are valid blocks and thus can't selectively discard those shares. -- 'peter'[:-1]@petertodd.org 00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 13:28 ` Peter Todd @ 2015-12-20 17:00 ` Emin Gün Sirer 2015-12-21 11:39 ` Jannes Faber ` (2 more replies) 2015-12-26 8:23 ` Eric Lombrozo 1 sibling, 3 replies; 47+ messages in thread From: Emin Gün Sirer @ 2015-12-20 17:00 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 6419 bytes --] On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete@petertodd•org> wrote: > There are a number of techniques that can be used to detect block > withholding attacks that you are not aware of. These techniques usually > have the characteristic that if known they can be avoided, so obviously > those who know about them are highly reluctant to reveal what exactly > they are. I personally know about some of them and have been asked to > keep that information secret, which I will. > Indeed, there are lots of weak measures that one could employ against an uninformed attacker. As I mentioned before, these are unlikely to be effective against a savvy attacker, and this is a good thing. > In the context of KYC, this techniques would likely hold up in court, > which means that if this stuff becomes a more serious problem it's > perfectly viable for large, well-resourced, pools to prevent block > withholding attacks, in part by removing anonymity of hashing power. > This would not be a positive development for the ecosystem. > KYC has a particular financial-regulation connotation in Bitcoin circles, of which I'm sure you're aware, and which you're using as a spectre. You don't mean government-regulated-KYC a la FINCEN and Bitcoin exchanges like Coinbase, you are just referring to a pool operator demanding to know that its customer is not coming from its competitors' data centers. And your prediction doesn't seem well-motivated or properly justified. There are tons of conditionals in your prediction, starting with the premise that every single open pool would implement some notion of identity checking. I don't believe that will happen. Instead, we will have the bigger pools become more suspicious of signing up new hash power, which is a good thing. And we will have small groups of people who have some reason for trusting each other (e.g. they know each other from IRC, conferences, etc) band together into small pools. These are fantastic outcomes for decentralization. Secondly, DRM tech can also easily be used to prevent block withholding > attacks by attesting to the honest of the hashing power. This is being > discussed in the industry, and again, this isn't a positive development > for the ecosystem. > DRM is a terrible application. Once again, I see that you're trying to use those three letters as a spectre as well, knowing that most people hate DRM, but keep in mind that DRM is just an application -- it's like pointing to Adobe Flash to taint all browser plugins. The tech behind DRM is called "attestation," and it provides a technical capability not possible by any other means. In essence, attestation can ensure that a remote node is indeed running the code that it purports to be running. Since most problems in computer security and distributed systems stem from not knowing what protocol the attacker is going to follow, attestation is the only technology we have that lets us step around this limitation. It can ensure, for instance, - that a node purporting to be Bitcoin Core (vLatest) is indeed running an unadulterated, latest version of Bitcoin Core - that a node claiming that it does not harvest IP addresses from SPV clients indeed does not harvest IP addresses. - that a cloud hashing outfit that rented out X terahashes to a user did indeed rent out X terahashes to that particular user, - that a miner operating on behalf of some pool P will not misbehave and discard perfectly good blocks and so forth. All of these would be great for the ecosystem. Just getting rid of the cloudhashing scams would put an end to a lot of heartache. > Keep in mind that when an open pool gets big, like GHash did and > > two other pools did before them, the only thing at our disposal used > > to be to yell at people about centralization until they left the big > > pools and reformed into smaller groups. Not only was such yelling > > kind of desperate looking, it wasn't incredibly effective, either. > > We had no protocol mechanisms that put pressure on big pools to > > stop signing up people. Ittay's discovery changed that: pools that > > get to be very big by indiscriminately signing up miners are likely to > > be infiltrated and their profitability will drop. And Peter's post is > > evidence that this is, indeed, happening as predicted. This is a > > good outcome, it puts pressure on the big pools to not grow. > > GHash.io was not a pure pool - they owned and operated a significant > amount of physical hashing power, and it's not at all clear that their % > of the network actually went down following that 51% debacle. > Right, it's not clear at all that yelling at people has much effect. As much fun as I had going to that meeting with GHash in London to ask them to back down off of the 51% boundary, I am pretty sure that yelling at large open pools will not scale. We needed better mechanisms for keeping pools in check. And Miner's Dilemma (MD) attacks are clearly quite effective. This is a time when we should count our blessings, not work actively to render them inoperable. Currently a significant % of the hashing power - possibly a majority - > is in the form of large hashing installations whose owners individually, > and definitely in trusting groups, have enough hashing power to solo > mine. Eyal's results indicate those miners have incentives to attack > pools, and additionally they have the incentive of killing off pools to > make it difficult for new competition to get established, yet they > themselves are not vulnerable to that attack. > There are indeed solo miners out there who can attack the big open pools. The loss of the biggest open pools would not be a bad outcome. Pools >25% pose a danger, and the home miner doesn't need a pool >25% for protection against variance. > Peter, you allude to a specific suggestion from Luke-Jr. Can you > > please describe what it is? > > Basically you have the pool pick a secret k for each share, and commit > to H(k) in the share. Additionally the share commits to a target divider > D. The PoW validity rule is then changed from H(block header) < T, to be > H(block header) < T * D && H(H(block header) + k) < max_int / D > Thanks, this requires a change to the Bitcoin PoW. Good luck with that! Once again, this suggestion would make the GHash-at-51% situation possible again. Working extra hard to re-enable those painful days sounds like a terrible idea. - egs [-- Attachment #2: Type: text/html, Size: 8447 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 17:00 ` Emin Gün Sirer @ 2015-12-21 11:39 ` Jannes Faber 2015-12-25 11:15 ` Ittay 2015-12-26 0:38 ` Geir Harald Hansen 2015-12-28 20:02 ` Peter Todd 2 siblings, 1 reply; 47+ messages in thread From: Jannes Faber @ 2015-12-21 11:39 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 7546 bytes --] If you're saying a block withholding attack is a nice weapon to have to dissuade large pools, isn't that easily defeated by large pools simply masquerading as multiple small pools? As, for all we know, ghash may have done? If you don't know who to attack there's no point in having the weapon. While that weapon is still dangerous in the hands of others that are indiscriminate, like the solo miners example of Peter Todd. Sorry if i misunderstood your point. -- Jannes On 20 December 2015 at 18:00, Emin Gün Sirer < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete@petertodd•org> wrote: > >> There are a number of techniques that can be used to detect block >> withholding attacks that you are not aware of. These techniques usually >> have the characteristic that if known they can be avoided, so obviously >> those who know about them are highly reluctant to reveal what exactly >> they are. I personally know about some of them and have been asked to >> keep that information secret, which I will. >> > > Indeed, there are lots of weak measures that one could employ against > an uninformed attacker. As I mentioned before, these are unlikely to be > effective against a savvy attacker, and this is a good thing. > > >> In the context of KYC, this techniques would likely hold up in court, >> which means that if this stuff becomes a more serious problem it's >> perfectly viable for large, well-resourced, pools to prevent block >> withholding attacks, in part by removing anonymity of hashing power. >> This would not be a positive development for the ecosystem. >> > > KYC has a particular financial-regulation connotation in Bitcoin circles, > of which I'm sure you're aware, and which you're using as a spectre. > You don't mean government-regulated-KYC a la FINCEN and Bitcoin > exchanges like Coinbase, you are just referring to a pool operator > demanding to know that its customer is not coming from its competitors' > data centers. > > And your prediction doesn't seem well-motivated or properly justified. > There are tons of conditionals in your prediction, starting with the > premise > that every single open pool would implement some notion of identity > checking. I don't believe that will happen. Instead, we will have the > bigger > pools become more suspicious of signing up new hash power, which is a > good thing. And we will have small groups of people who have some reason > for trusting each other (e.g. they know each other from IRC, conferences, > etc) band together into small pools. These are fantastic outcomes for > decentralization. > > Secondly, DRM tech can also easily be used to prevent block withholding >> attacks by attesting to the honest of the hashing power. This is being >> discussed in the industry, and again, this isn't a positive development >> for the ecosystem. >> > > DRM is a terrible application. Once again, I see that you're trying to use > those > three letters as a spectre as well, knowing that most people hate DRM, but > keep in mind that DRM is just an application -- it's like pointing to > Adobe Flash > to taint all browser plugins. > > The tech behind DRM is called "attestation," and it provides a technical > capability not possible by any other means. In essence, attestation can > ensure that > a remote node is indeed running the code that it purports to be running. > Since > most problems in computer security and distributed systems stem from not > knowing what protocol the attacker is going to follow, attestation is the > only > technology we have that lets us step around this limitation. > > It can ensure, for instance, > - that a node purporting to be Bitcoin Core (vLatest) is indeed running > an > unadulterated, latest version of Bitcoin Core > - that a node claiming that it does not harvest IP addresses from SPV > clients indeed does not harvest IP addresses. > - that a cloud hashing outfit that rented out X terahashes to a user did > indeed rent out X terahashes to that particular user, > - that a miner operating on behalf of some pool P will not misbehave and > discard perfectly good blocks > and so forth. All of these would be great for the ecosystem. Just getting > rid > of the cloudhashing scams would put an end to a lot of heartache. > > > Keep in mind that when an open pool gets big, like GHash did and >> > two other pools did before them, the only thing at our disposal used >> > to be to yell at people about centralization until they left the big >> > pools and reformed into smaller groups. Not only was such yelling >> > kind of desperate looking, it wasn't incredibly effective, either. >> > We had no protocol mechanisms that put pressure on big pools to >> > stop signing up people. Ittay's discovery changed that: pools that >> > get to be very big by indiscriminately signing up miners are likely to >> > be infiltrated and their profitability will drop. And Peter's post is >> > evidence that this is, indeed, happening as predicted. This is a >> > good outcome, it puts pressure on the big pools to not grow. >> >> GHash.io was not a pure pool - they owned and operated a significant >> amount of physical hashing power, and it's not at all clear that their % >> of the network actually went down following that 51% debacle. >> > > Right, it's not clear at all that yelling at people has much effect. As > much > fun as I had going to that meeting with GHash in London to ask them to > back down off of the 51% boundary, I am pretty sure that yelling at large > open pools will not scale. We needed better mechanisms for keeping pools > in check. > > And Miner's Dilemma (MD) attacks are clearly quite effective. This is a > time when we should count our blessings, not work actively to render > them inoperable. > > Currently a significant % of the hashing power - possibly a majority - >> is in the form of large hashing installations whose owners individually, >> and definitely in trusting groups, have enough hashing power to solo >> mine. Eyal's results indicate those miners have incentives to attack >> pools, and additionally they have the incentive of killing off pools to >> make it difficult for new competition to get established, yet they >> themselves are not vulnerable to that attack. >> > > There are indeed solo miners out there who can attack the big open > pools. The loss of the biggest open pools would not be a bad outcome. > Pools >25% pose a danger, and the home miner doesn't need a pool > >25% for protection against variance. > > > Peter, you allude to a specific suggestion from Luke-Jr. Can you >> > please describe what it is? >> >> Basically you have the pool pick a secret k for each share, and commit >> to H(k) in the share. Additionally the share commits to a target divider >> D. The PoW validity rule is then changed from H(block header) < T, to be >> H(block header) < T * D && H(H(block header) + k) < max_int / D >> > > Thanks, this requires a change to the Bitcoin PoW. Good luck with that! > > Once again, this suggestion would make the GHash-at-51% situation > possible again. Working extra hard to re-enable those painful days > sounds like a terrible idea. > > - egs > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 9972 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-21 11:39 ` Jannes Faber @ 2015-12-25 11:15 ` Ittay 2015-12-25 12:00 ` Jonathan Toomim ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Ittay @ 2015-12-25 11:15 UTC (permalink / raw) To: Jannes Faber; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 8807 bytes --] Treating the pool block withholding attack as a weapon has bad connotations, and I don't think anyone directly condones such an attack. Nevertheless, the mere possibility of the attack could drive miners away from those overly-large open pools. As for masquerading as multiple small pools -- that's a very good point, with a surprising answer: it doesn't really matter. An attacker attacks all parts of the open pool proportionally to their size, and the result is basically identical to that of attacking a single large pool. All that being said -- it's not great to rely on the potential of attacks and on threats against the honest large pools out there (including GHash, which, afaik, did nothing more wrong than being successful). Best, Ittay On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > If you're saying a block withholding attack is a nice weapon to have to > dissuade large pools, isn't that easily defeated by large pools simply > masquerading as multiple small pools? As, for all we know, ghash may have > done? > > If you don't know who to attack there's no point in having the weapon. > While that weapon is still dangerous in the hands of others that are > indiscriminate, like the solo miners example of Peter Todd. > > Sorry if i misunderstood your point. > > -- > Jannes > > On 20 December 2015 at 18:00, Emin Gün Sirer < > bitcoin-dev@lists•linuxfoundation.org> wrote: > >> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete@petertodd•org> wrote: >> >>> There are a number of techniques that can be used to detect block >>> withholding attacks that you are not aware of. These techniques usually >>> have the characteristic that if known they can be avoided, so obviously >>> those who know about them are highly reluctant to reveal what exactly >>> they are. I personally know about some of them and have been asked to >>> keep that information secret, which I will. >>> >> >> Indeed, there are lots of weak measures that one could employ against >> an uninformed attacker. As I mentioned before, these are unlikely to be >> effective against a savvy attacker, and this is a good thing. >> >> >>> In the context of KYC, this techniques would likely hold up in court, >>> which means that if this stuff becomes a more serious problem it's >>> perfectly viable for large, well-resourced, pools to prevent block >>> withholding attacks, in part by removing anonymity of hashing power. >>> This would not be a positive development for the ecosystem. >>> >> >> KYC has a particular financial-regulation connotation in Bitcoin circles, >> of which I'm sure you're aware, and which you're using as a spectre. >> You don't mean government-regulated-KYC a la FINCEN and Bitcoin >> exchanges like Coinbase, you are just referring to a pool operator >> demanding to know that its customer is not coming from its competitors' >> data centers. >> >> And your prediction doesn't seem well-motivated or properly justified. >> There are tons of conditionals in your prediction, starting with the >> premise >> that every single open pool would implement some notion of identity >> checking. I don't believe that will happen. Instead, we will have the >> bigger >> pools become more suspicious of signing up new hash power, which is a >> good thing. And we will have small groups of people who have some reason >> for trusting each other (e.g. they know each other from IRC, conferences, >> etc) band together into small pools. These are fantastic outcomes for >> decentralization. >> >> Secondly, DRM tech can also easily be used to prevent block withholding >>> attacks by attesting to the honest of the hashing power. This is being >>> discussed in the industry, and again, this isn't a positive development >>> for the ecosystem. >>> >> >> DRM is a terrible application. Once again, I see that you're trying to >> use those >> three letters as a spectre as well, knowing that most people hate DRM, >> but >> keep in mind that DRM is just an application -- it's like pointing to >> Adobe Flash >> to taint all browser plugins. >> >> The tech behind DRM is called "attestation," and it provides a technical >> capability not possible by any other means. In essence, attestation can >> ensure that >> a remote node is indeed running the code that it purports to be running. >> Since >> most problems in computer security and distributed systems stem from not >> knowing what protocol the attacker is going to follow, attestation is the >> only >> technology we have that lets us step around this limitation. >> >> It can ensure, for instance, >> - that a node purporting to be Bitcoin Core (vLatest) is indeed running >> an >> unadulterated, latest version of Bitcoin Core >> - that a node claiming that it does not harvest IP addresses from SPV >> clients indeed does not harvest IP addresses. >> - that a cloud hashing outfit that rented out X terahashes to a user >> did >> indeed rent out X terahashes to that particular user, >> - that a miner operating on behalf of some pool P will not misbehave and >> discard perfectly good blocks >> and so forth. All of these would be great for the ecosystem. Just getting >> rid >> of the cloudhashing scams would put an end to a lot of heartache. >> >> > Keep in mind that when an open pool gets big, like GHash did and >>> > two other pools did before them, the only thing at our disposal used >>> > to be to yell at people about centralization until they left the big >>> > pools and reformed into smaller groups. Not only was such yelling >>> > kind of desperate looking, it wasn't incredibly effective, either. >>> > We had no protocol mechanisms that put pressure on big pools to >>> > stop signing up people. Ittay's discovery changed that: pools that >>> > get to be very big by indiscriminately signing up miners are likely to >>> > be infiltrated and their profitability will drop. And Peter's post is >>> > evidence that this is, indeed, happening as predicted. This is a >>> > good outcome, it puts pressure on the big pools to not grow. >>> >>> GHash.io was not a pure pool - they owned and operated a significant >>> amount of physical hashing power, and it's not at all clear that their % >>> of the network actually went down following that 51% debacle. >>> >> >> Right, it's not clear at all that yelling at people has much effect. As >> much >> fun as I had going to that meeting with GHash in London to ask them to >> back down off of the 51% boundary, I am pretty sure that yelling at large >> open pools will not scale. We needed better mechanisms for keeping pools >> in check. >> >> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a >> time when we should count our blessings, not work actively to render >> them inoperable. >> >> Currently a significant % of the hashing power - possibly a majority - >>> is in the form of large hashing installations whose owners individually, >>> and definitely in trusting groups, have enough hashing power to solo >>> mine. Eyal's results indicate those miners have incentives to attack >>> pools, and additionally they have the incentive of killing off pools to >>> make it difficult for new competition to get established, yet they >>> themselves are not vulnerable to that attack. >>> >> >> There are indeed solo miners out there who can attack the big open >> pools. The loss of the biggest open pools would not be a bad outcome. >> Pools >25% pose a danger, and the home miner doesn't need a pool >> >25% for protection against variance. >> >> > Peter, you allude to a specific suggestion from Luke-Jr. Can you >>> > please describe what it is? >>> >>> Basically you have the pool pick a secret k for each share, and commit >>> to H(k) in the share. Additionally the share commits to a target divider >>> D. The PoW validity rule is then changed from H(block header) < T, to be >>> H(block header) < T * D && H(H(block header) + k) < max_int / D >>> >> >> Thanks, this requires a change to the Bitcoin PoW. Good luck with that! >> >> Once again, this suggestion would make the GHash-at-51% situation >> possible again. Working extra hard to re-enable those painful days >> sounds like a terrible idea. >> >> - egs >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 11716 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 2 siblings, 0 replies; 47+ messages in thread From: Jonathan Toomim @ 2015-12-25 12:00 UTC (permalink / raw) To: Ittay; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 2145 bytes --] On Dec 25, 2015, at 3:15 AM, Ittay via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > Treating the pool block withholding attack as a weapon has bad connotations, and I don't think anyone directly condones such an attack. I directly condone the use of block withholding attacks whenever pools get large enough to perform selfish mining attacks. Selfish mining and large, centralized pools also have bad connotations. It's an attack against pools, not just large pools. Solo miners are immune. As such, the presence or use of block withholding attacks makes Bitcoin more similar to Satoshi's original vision. One of the issues with mining centralization via pools is that miners have a direct financial incentive to stay relatively small, but pools do not. Investing in mining is a zero-sum game, where each miner gains revenue by making investments at the expense of existing miners. This also means that miners take revenue from themselves when they upgrade their hashrate. If a miner already has 1/5 of the network hashrate, then the marginal revenue for that miner of adding 1 TH/s is only 4/5 of the marginal revenue for a miner with 0% of the network and who adds 1 TH/s. The bigger you get, the smaller your incentive to get bigger. This incentive applies to miners, but it does not apply to pools. Pools have an incentive to get as big as possible (except for social backlash and altruistic punishment issues). Pools are the problem. I think we should be looking for ways of making pooled mining less profitable than solo mining or p2pool-style mining. Block withholding attacks are one such tool, and maybe the only usable tool we'll get. If we have to choose between making bitcoin viable long-term and avoiding things with bad connotations, it might be better to let our hands get a little bit dirty. I don't intend to perform any such attacks myself. I like to keep my hat a nice shiny white. However, if anyone else were to perform such an attack, I would condone it. P.S.: Sorry, pool operators. I have nothing against you personally. I just think pools are dangerous, and I wish they didn't exist. [-- Attachment #1.2: Type: text/html, Size: 2991 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 2 siblings, 0 replies; 47+ messages in thread From: benevolent @ 2015-12-25 12:02 UTC (permalink / raw) To: Ittay; +Cc: Bitcoin Dev On 2015-12-25 11:15, Ittay via bitcoin-dev wrote: > > All that being said -- it's not great to rely on the potential of > attacks and on threats against the honest large pools out there > (including GHash, which, afaik, did nothing more wrong than being > successful). GHash.IO and double-spending against BetCoin Dice https://bitcointalk.org/index.php?topic=327767.0 ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 2 siblings, 0 replies; 47+ messages in thread From: Jannes Faber @ 2015-12-25 16:11 UTC (permalink / raw) To: Ittay, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 8767 bytes --] On 25 Dec 2015 12:15 p.m., "Ittay" <ittay.eyal@cornell•edu> wrote: > As for masquerading as multiple small pools -- that's a very good point, with a surprising answer: it doesn't really matter. An attacker attacks all parts of the open pool proportionally to their size, and the result is basically identical to that of attacking a single large pool. While true, that's only relevant to the indiscriminate attacker! The vigilante attacker that wants to hurt only pools that are too large, doesn't even know that there's a need to attack as all of them seem small. That's what i was saying. > > On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> If you're saying a block withholding attack is a nice weapon to have to dissuade large pools, isn't that easily defeated by large pools simply masquerading as multiple small pools? As, for all we know, ghash may have done? >> >> If you don't know who to attack there's no point in having the weapon. While that weapon is still dangerous in the hands of others that are indiscriminate, like the solo miners example of Peter Todd. >> >> Sorry if i misunderstood your point. >> >> >> -- >> Jannes >> >> On 20 December 2015 at 18:00, Emin Gün Sirer < bitcoin-dev@lists•linuxfoundation.org> wrote: >>> >>> On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete@petertodd•org> wrote: >>>> >>>> There are a number of techniques that can be used to detect block >>>> withholding attacks that you are not aware of. These techniques usually >>>> have the characteristic that if known they can be avoided, so obviously >>>> those who know about them are highly reluctant to reveal what exactly >>>> they are. I personally know about some of them and have been asked to >>>> keep that information secret, which I will. >>> >>> >>> Indeed, there are lots of weak measures that one could employ against >>> an uninformed attacker. As I mentioned before, these are unlikely to be >>> effective against a savvy attacker, and this is a good thing. >>> >>>> >>>> In the context of KYC, this techniques would likely hold up in court, >>>> which means that if this stuff becomes a more serious problem it's >>>> perfectly viable for large, well-resourced, pools to prevent block >>>> withholding attacks, in part by removing anonymity of hashing power. >>>> This would not be a positive development for the ecosystem. >>> >>> >>> KYC has a particular financial-regulation connotation in Bitcoin circles, >>> of which I'm sure you're aware, and which you're using as a spectre. >>> You don't mean government-regulated-KYC a la FINCEN and Bitcoin >>> exchanges like Coinbase, you are just referring to a pool operator >>> demanding to know that its customer is not coming from its competitors' >>> data centers. >>> >>> And your prediction doesn't seem well-motivated or properly justified. >>> There are tons of conditionals in your prediction, starting with the premise >>> that every single open pool would implement some notion of identity >>> checking. I don't believe that will happen. Instead, we will have the bigger >>> pools become more suspicious of signing up new hash power, which is a >>> good thing. And we will have small groups of people who have some reason >>> for trusting each other (e.g. they know each other from IRC, conferences, >>> etc) band together into small pools. These are fantastic outcomes for >>> decentralization. >>> >>>> Secondly, DRM tech can also easily be used to prevent block withholding >>>> attacks by attesting to the honest of the hashing power. This is being >>>> discussed in the industry, and again, this isn't a positive development >>>> for the ecosystem. >>> >>> >>> DRM is a terrible application. Once again, I see that you're trying to use those >>> three letters as a spectre as well, knowing that most people hate DRM, but >>> keep in mind that DRM is just an application -- it's like pointing to Adobe Flash >>> to taint all browser plugins. >>> >>> The tech behind DRM is called "attestation," and it provides a technical >>> capability not possible by any other means. In essence, attestation can ensure that >>> a remote node is indeed running the code that it purports to be running. Since >>> most problems in computer security and distributed systems stem from not >>> knowing what protocol the attacker is going to follow, attestation is the only >>> technology we have that lets us step around this limitation. >>> >>> It can ensure, for instance, >>> - that a node purporting to be Bitcoin Core (vLatest) is indeed running an >>> unadulterated, latest version of Bitcoin Core >>> - that a node claiming that it does not harvest IP addresses from SPV >>> clients indeed does not harvest IP addresses. >>> - that a cloud hashing outfit that rented out X terahashes to a user did >>> indeed rent out X terahashes to that particular user, >>> - that a miner operating on behalf of some pool P will not misbehave and >>> discard perfectly good blocks >>> and so forth. All of these would be great for the ecosystem. Just getting rid >>> of the cloudhashing scams would put an end to a lot of heartache. >>> >>>> > Keep in mind that when an open pool gets big, like GHash did and >>>> > two other pools did before them, the only thing at our disposal used >>>> > to be to yell at people about centralization until they left the big >>>> > pools and reformed into smaller groups. Not only was such yelling >>>> > kind of desperate looking, it wasn't incredibly effective, either. >>>> > We had no protocol mechanisms that put pressure on big pools to >>>> > stop signing up people. Ittay's discovery changed that: pools that >>>> > get to be very big by indiscriminately signing up miners are likely to >>>> > be infiltrated and their profitability will drop. And Peter's post is >>>> > evidence that this is, indeed, happening as predicted. This is a >>>> > good outcome, it puts pressure on the big pools to not grow. >>>> >>>> GHash.io was not a pure pool - they owned and operated a significant >>>> amount of physical hashing power, and it's not at all clear that their % >>>> of the network actually went down following that 51% debacle. >>> >>> >>> Right, it's not clear at all that yelling at people has much effect. As much >>> fun as I had going to that meeting with GHash in London to ask them to >>> back down off of the 51% boundary, I am pretty sure that yelling at large >>> open pools will not scale. We needed better mechanisms for keeping pools >>> in check. >>> >>> And Miner's Dilemma (MD) attacks are clearly quite effective. This is a >>> time when we should count our blessings, not work actively to render >>> them inoperable. >>> >>>> Currently a significant % of the hashing power - possibly a majority - >>>> is in the form of large hashing installations whose owners individually, >>>> and definitely in trusting groups, have enough hashing power to solo >>>> mine. Eyal's results indicate those miners have incentives to attack >>>> pools, and additionally they have the incentive of killing off pools to >>>> make it difficult for new competition to get established, yet they >>>> themselves are not vulnerable to that attack. >>> >>> >>> There are indeed solo miners out there who can attack the big open >>> pools. The loss of the biggest open pools would not be a bad outcome. >>> Pools >25% pose a danger, and the home miner doesn't need a pool >>> >25% for protection against variance. >>> >>>> > Peter, you allude to a specific suggestion from Luke-Jr. Can you >>>> > please describe what it is? >>>> >>>> Basically you have the pool pick a secret k for each share, and commit >>>> to H(k) in the share. Additionally the share commits to a target divider >>>> D. The PoW validity rule is then changed from H(block header) < T, to be >>>> H(block header) < T * D && H(H(block header) + k) < max_int / D >>> >>> >>> Thanks, this requires a change to the Bitcoin PoW. Good luck with that! >>> >>> Once again, this suggestion would make the GHash-at-51% situation >>> possible again. Working extra hard to re-enable those painful days >>> sounds like a terrible idea. >>> >>> - egs >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists•linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > [-- Attachment #2: Type: text/html, Size: 11660 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 17:00 ` Emin Gün Sirer 2015-12-21 11:39 ` Jannes Faber @ 2015-12-26 0:38 ` Geir Harald Hansen 2015-12-28 20:02 ` Peter Todd 2 siblings, 0 replies; 47+ messages in thread From: Geir Harald Hansen @ 2015-12-26 0:38 UTC (permalink / raw) To: bitcoin-dev On 20.12.2015 18:00, Emin Gün Sirer via bitcoin-dev wrote: > Instead, we will have the bigger > pools become more suspicious of signing up new hash power, which is a > good thing. Block withholding attacks do not differentiate between small and large pools. When Eligius and BTCGuild got hit with this, they were far from the biggest pools at the time. When my pool, Bitminter, got a new large miner who found 1 block where average luck would have had them find 3, one of the other miners claimed they must be withholding blocks. Even if there is no logic or evidence behind it, after one person cries wolf the others get nervous. This way even the possibility of block withholding can keep smaller pools from growing. It takes more hashpower to put a dent in a bigger pool, so you will see less such panic. > And we will have small groups of people who have some reason > for trusting each other (e.g. they know each other from IRC, conferences, > etc) band together into small pools. These are fantastic outcomes for > decentralization. Three guys with 1 TH/s, 2 TH/s and 100 GH/s meet at a conference and decide to start a private pool? Obviously that doesn't work. Maybe three people with huge warehouses of miners would work together if they knew and trusted each other. Those small miners need to mine with people they don't know to get an acceptable variance. If you kill off mining pools then small miners have no way to achieve acceptable variance and they will disappear. There will only be big warehouse miners left, the ones who are big enough to solo mine. That's not helping decentralization. > Right, it's not clear at all that yelling at people has much effect. As much > fun as I had going to that meeting with GHash in London to ask them to > back down off of the 51% boundary, I am pretty sure that yelling at large > open pools will not scale. We needed better mechanisms for keeping pools > in check. I agree. It's very disappointing how most miners and pools handle this (BTCGuild being the exception). But I do not think block withholding is a good tool. It can easily destroy small pools, but it won't put a dent in a pool that goes over 50%. Block withholding is a tool big pools can use to put smaller competitors out of business. And even if it was effective I would not use block withholding to attack other pools. > And Miner's Dilemma (MD) attacks are clearly quite effective. This is a > time when we should count our blessings, not work actively to render > them inoperable. Is it? Is there any example of block withholding leading to more decentralized mining? If I remember right, GHash being too big ended with BitFury moving some of their hashpower out of the pool. I don't know where that hashpower went and whether the problem was solved or merely hidden. GHash profitability being very low for some time wasn't due to block withholding, it was a bug that some miners abused to get paid for the same work multiple times. This made it look like a lot of work was done while finding few blocks. > Basically you have the pool pick a secret k for each share, and commit > to H(k) in the share. Additionally the share commits to a target divider > D. The PoW validity rule is then changed from H(block header) < T, to be > H(block header) < T * D && H(H(block header) + k) < max_int / D > > > Thanks, this requires a change to the Bitcoin PoW. Good luck with that! > > Once again, this suggestion would make the GHash-at-51% situation > possible again. Working extra hard to re-enable those painful days > sounds like a terrible idea. Block withholding didn't solve the problem back then. And guess what, those painful days are here right now. China is at 65% and block withholding isn't solving it. I was disappointed when GHash got too big and refused to do anything. It was sad when their miners didn't do anything. Then they used double-spends to scam a casino. I was shocked that noone cared. Now two thirds of the bitcoin hashpower is within the control of a single government. This time I expected noone would care - but I'm still disappointed. I'm also surprised at the irrational behavior; there are so many who go out of their way to put their own investments in danger. For a long time now many miners and pools have been irresponsible with the hashpower. But block withholding just makes it worse. Regards, Geir H. Hansen, Bitminter mining pool ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 17:00 ` Emin Gün Sirer 2015-12-21 11:39 ` Jannes Faber 2015-12-26 0:38 ` Geir Harald Hansen @ 2015-12-28 20:02 ` Peter Todd 2 siblings, 0 replies; 47+ messages in thread From: Peter Todd @ 2015-12-28 20:02 UTC (permalink / raw) To: Emin Gün Sirer; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 8169 bytes --] On Sun, Dec 20, 2015 at 12:00:37PM -0500, Emin Gün Sirer via bitcoin-dev wrote: > > In the context of KYC, this techniques would likely hold up in court, > > which means that if this stuff becomes a more serious problem it's > > perfectly viable for large, well-resourced, pools to prevent block > > withholding attacks, in part by removing anonymity of hashing power. > > This would not be a positive development for the ecosystem. > > > > KYC has a particular financial-regulation connotation in Bitcoin circles, > of which I'm sure you're aware, and which you're using as a spectre. > You don't mean government-regulated-KYC a la FINCEN and Bitcoin > exchanges like Coinbase, you are just referring to a pool operator > demanding to know that its customer is not coming from its competitors' > data centers. I mean Knowing Your Customer. The only way to know that a customer is *not* coming from a competitor's data center is to know their identity, which is precisely what KYC is. In the financial world, KYC is used to refer to any time you take steps to determine the real identity/deanonymize your customers. > And your prediction doesn't seem well-motivated or properly justified. > There are tons of conditionals in your prediction, starting with the premise > that every single open pool would implement some notion of identity > checking. I don't believe that will happen. Instead, we will have the bigger > pools become more suspicious of signing up new hash power, which is a > good thing. And we will have small groups of people who have some reason > for trusting each other (e.g. they know each other from IRC, conferences, > etc) band together into small pools. These are fantastic outcomes for > decentralization. That's a terrible outcomes for decentralization; we *want* people to be able to contribute hashing power to the network even if they don't already have personal connections with existing miners. That's how we attract new players to the mining industry whose backgrounds are not correlated with the backgrounds of other miners - exactly what we want for decentralization. Keep in mind that access to cheap power and cheap opportunities to get rid of waste heat is naturally decentralized by physics, economics, and politics. Basically, the cheapest power, and cheapest ways to get rid of waste heat, is in the form of unique opportunities that don't have economies of scale. For example, much of the Chinese hashing power takes advantage of stranded hydroelectric plants that are located far away from markets that would otherwise buy that power. These plants are limited in size by the local rivers and there's no way to make them any bigger - there's a natural diseconomy of scale involved. Now, support if you have access to such a hydro plant - maybe a mine in the middle of nowhere just closed and there's no-one else to sell the power too. Right now you can buy some hashing equipment(1) and start earning money immediately by pointing it at a pool of your choice. If that pool fucks up, it's really easy for you to change a few lines in your configs and point that hashing power to a different pool. However if block withholding attacks continue and kill off open access pools the process becomes much more arduous. Chances are you won't even bother, and Bitcoin will end up with one less decentralized miner. 1) If access to hashing equipment becomes a limiting factor/fails to improve, Bitcoin itself will likely have to switch PoW functions to succeed as a decentralized system. > Secondly, DRM tech can also easily be used to prevent block withholding > > attacks by attesting to the honest of the hashing power. This is being > > discussed in the industry, and again, this isn't a positive development > > for the ecosystem. > > > > DRM is a terrible application. Once again, I see that you're trying to use > those > three letters as a spectre as well, knowing that most people hate DRM, but > keep in mind that DRM is just an application -- it's like pointing to Adobe > Flash > to taint all browser plugins. > > The tech behind DRM is called "attestation," and it provides a technical > capability not possible by any other means. In essence, attestation can > ensure that > a remote node is indeed running the code that it purports to be running. > Since > most problems in computer security and distributed systems stem from not > knowing what protocol the attacker is going to follow, attestation is the > only > technology we have that lets us step around this limitation. > > It can ensure, for instance, > - that a node purporting to be Bitcoin Core (vLatest) is indeed running an > unadulterated, latest version of Bitcoin Core > - that a node claiming that it does not harvest IP addresses from SPV > clients indeed does not harvest IP addresses. > - that a cloud hashing outfit that rented out X terahashes to a user did > indeed rent out X terahashes to that particular user, > - that a miner operating on behalf of some pool P will not misbehave and > discard perfectly good blocks > and so forth. All of these would be great for the ecosystem. Just getting > rid > of the cloudhashing scams would put an end to a lot of heartache. Again, lets look at it from the perspective of someone with access to cheap power. With DRM tech a likely implementation is the equipment manufacturer/pool operator sells you a locked down, tamper-resistant, box that only can send hashing power to a specific pool. 21 for example has been investigating this model. If such equipment is common, even though the guy with a hydro plant in Siberia is physically and politically highly decentralized, the control of the blocks created is highly centralized, rendering his contribution to the network's decentralization moot. At best we might get general purpose attestation, but implementing that vs. locked down, single pool, boxes is more expensive and slower to market. Even then, we'd be much more likely to get fragile and difficult-to-reverse-engineer hashing equipment that's always going to be easier to add backdoors too. We're better off with an ecosystem where DRM tech like attestation isn't needed at all. As for cloud hashing... those scams have mostly died off as the market has become more efficient. > > GHash.io was not a pure pool - they owned and operated a significant > > amount of physical hashing power, and it's not at all clear that their % > > of the network actually went down following that 51% debacle. > > > > Right, it's not clear at all that yelling at people has much effect. As much > fun as I had going to that meeting with GHash in London to ask them to > back down off of the 51% boundary, I am pretty sure that yelling at large > open pools will not scale. We needed better mechanisms for keeping pools > in check. > > And Miner's Dilemma (MD) attacks are clearly quite effective. This is a > time when we should count our blessings, not work actively to render > them inoperable. What evidence do you have for them being "clearly quite effective"? Is there any evidence that they were used against GHash.io for example? Remember that block withholding attacks give an advantage to those with access to large amounts of physical hashing power, like GHash.IO did at that time. > > Basically you have the pool pick a secret k for each share, and commit > > to H(k) in the share. Additionally the share commits to a target divider > > D. The PoW validity rule is then changed from H(block header) < T, to be > > H(block header) < T * D && H(H(block header) + k) < max_int / D > > > > Thanks, this requires a change to the Bitcoin PoW. Good luck with that! It's not a change to the PoW, just a change to the definition of block validity; mining hardware does *not* need to change to implement Luke-Jr's idea. Also, as mentioned elsewhere in this thread, it can be implemented slowly as a pseudo-soft-fork. -- 'peter'[:-1]@petertodd.org 000000000000000001d3c4acb7446f66482fb6aceb087d7601c9e0644cf60e9a [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-20 13:28 ` Peter Todd 2015-12-20 17:00 ` Emin Gün Sirer @ 2015-12-26 8:23 ` Eric Lombrozo 2015-12-26 8:26 ` Eric Lombrozo ` (3 more replies) 1 sibling, 4 replies; 47+ messages in thread From: Eric Lombrozo @ 2015-12-26 8:23 UTC (permalink / raw) To: Peter Todd, Emin Gün Sirer; +Cc: Bitcoin Dev, nbvfour [-- Attachment #1: Type: text/plain, Size: 4236 bytes --] Peter Todd wrote: Fixing block withholding is relatively simple, but (so far) requires a SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should do this hard-fork in conjunction with any blocksize increase, which will have the desirable side effect of clearly show consent by the entire ecosystem, SPV clients included. I think we can generalize this and argue that it is impossible fix this without reducing the visible difficulty and blinding the hasher to an invisible difficulty. Unfortunately, changing the retargeting algo to compute lower visible difficulty (leaving all else the same) or interpreting the bits field in a way that yields a lower visible difficulty is a hard fork by definition - blocks that didn't meet the visible difficulty requirement before will now meet it. jl2012 wrote: >After the meeting I find a softfork solution. It is very inefficient >and I am leaving it here just for record. > >1. In the first output of the second transaction of a block, mining >pool will commit a random nonce with an OP_RETURN. > >2. Mine as normal. When a block is found, the hash is concatenated with >the committed random nonce and hashed. > >3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the >block is invalid. That means about 1% of blocks are discarded. > >4. For each difficulty retarget, the secondary target is decreased by 2 >^ 1/64. > >5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ >252. Therefore only 1 in 16 hash returned by hasher is really valid. >This should make the detection of block withholding attack much easier. > >All miners have to sacrifice 1% reward for 10 years. Confirmation will >also be 1% slower than it should be. > >If a node (full or SPV) is not updated, it becomes more vulnerable as >an attacker could mine a chain much faster without following the new >rules. But this is still a softfork, by definition. jl2012's key discovery here is that if we add an invisible difficulty while keeping the retarget algo and bits semantics the same, the visible difficulty will decrease automatically to compensate. In other words, we can artificially increase the block time interval, allowing us to force a lower visible difficulty at the next retarget without changing the retarget algo nor the bits semantics. There are no other free parameters we can tweak, so it seems this is really the best we can do. Unfortunately, this also means longer confirmation times, lower throughput, and lower miner revenue. Note, however, that confirmations would (on average) represent more PoW, so fewer confirmations would be required to achieve the same level of security. We can compensate for lower throughput and lower miner revenue by increasing block size and increasing block rewards. Interestingly, it turns out we *can* do these things with soft forks by embedding new structures into blocks and nesting their hash trees into existing structures. Ideas such as extension blocks [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html] have been proposed before...but they add significant complications to the protocol and require nontrivial app migration efforts. Old nodes would not get forked off the network but backwards compatibility would still be a problem as they would not be able to see at least some of the transactions and some of the bitcoins in blocks. But if we're willing to accept this, even the "sacred" 21 million asymptotic limit can be raised via soft fork! So in conclusion, it *is* possible to fix this attack with a soft fork and without altering the basic economics...but it's almost surely a lot more trouble than it's worth. Luke-Jr's solution is far simpler and more elegant and is perhaps one of the few examples of a new feature (as opposed to merely a structure cleanup) that would be better to deploy as a hard fork since it's simple to implement and seems to stand a reasonable chance of near universal support...and soft fork alternatives are very, very ugly and significantly impact system usability...and I think theory tells us we can't do any better. - Eric [-- Attachment #2: Type: text/html, Size: 6288 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 8:23 ` Eric Lombrozo @ 2015-12-26 8:26 ` Eric Lombrozo 2015-12-26 15:33 ` Jorge Timón ` (2 subsequent siblings) 3 siblings, 0 replies; 47+ messages in thread From: Eric Lombrozo @ 2015-12-26 8:26 UTC (permalink / raw) To: Peter Todd, Emin Gün Sirer; +Cc: Bitcoin Dev, nbvfour [-- Attachment #1: Type: text/plain, Size: 4807 bytes --] Note: my stupid email client didn't indent Peter Todd's quote correctly. The first paragraph is his, the second is my response. ------ Original Message ------ From: "Eric Lombrozo" <elombrozo@gmail•com> To: "Peter Todd" <pete@petertodd•org>; "Emin Gün Sirer" <el33th4x0r@gmail•com> Cc: nbvfour@gmail•com; "Bitcoin Dev" <bitcoin-dev@lists•linuxfoundation.org> Sent: 12/26/2015 12:23:38 AM Subject: Re[2]: [bitcoin-dev] We need to fix the block withholding attack >Peter Todd wrote: > Fixing block withholding is relatively simple, but (so far) requires a >SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We should >do this hard-fork in conjunction with any blocksize increase, which >will >have the desirable side effect of clearly show consent by the entire >ecosystem, SPV clients included. > >I think we can generalize this and argue that it is impossible fix this >without reducing the visible difficulty and blinding the hasher to an >invisible difficulty. Unfortunately, changing the retargeting algo to >compute lower visible difficulty (leaving all else the same) or >interpreting the bits field in a way that yields a lower visible >difficulty is a hard fork by definition - blocks that didn't meet the >visible difficulty requirement before will now meet it. > >jl2012 wrote: >>After the meeting I find a softfork solution. It is very inefficient >>and I am leaving it here just for record. >> >>1. In the first output of the second transaction of a block, mining >>pool will commit a random nonce with an OP_RETURN. >> >>2. Mine as normal. When a block is found, the hash is concatenated >>with the committed random nonce and hashed. >> >>3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the >>block is invalid. That means about 1% of blocks are discarded. >> >>4. For each difficulty retarget, the secondary target is decreased by >>2 ^ 1/64. >> >>5. After 546096 blocks or 10 years, the secondary target becomes 2 ^ >>252. Therefore only 1 in 16 hash returned by hasher is really valid. >>This should make the detection of block withholding attack much >>easier. >> >>All miners have to sacrifice 1% reward for 10 years. Confirmation will >>also be 1% slower than it should be. >> >>If a node (full or SPV) is not updated, it becomes more vulnerable as >>an attacker could mine a chain much faster without following the new >>rules. But this is still a softfork, by definition. >jl2012's key discovery here is that if we add an invisible difficulty >while keeping the retarget algo and bits semantics the same, the >visible difficulty will decrease automatically to compensate. In other >words, we can artificially increase the block time interval, allowing >us to force a lower visible difficulty at the next retarget without >changing the retarget algo nor the bits semantics. There are no other >free parameters we can tweak, so it seems this is really the best we >can do. > >Unfortunately, this also means longer confirmation times, lower >throughput, and lower miner revenue. Note, however, that confirmations >would (on average) represent more PoW, so fewer confirmations would be >required to achieve the same level of security. > >We can compensate for lower throughput and lower miner revenue by >increasing block size and increasing block rewards. Interestingly, it >turns out we *can* do these things with soft forks by embedding new >structures into blocks and nesting their hash trees into existing >structures. Ideas such as extension blocks >[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html] >have been proposed before...but they add significant complications to >the protocol and require nontrivial app migration efforts. Old nodes >would not get forked off the network but backwards compatibility would >still be a problem as they would not be able to see at least some of >the transactions and some of the bitcoins in blocks. But if we're >willing to accept this, even the "sacred" 21 million asymptotic limit >can be raised via soft fork! > >So in conclusion, it *is* possible to fix this attack with a soft fork >and without altering the basic economics...but it's almost surely a lot >more trouble than it's worth. Luke-Jr's solution is far simpler and >more elegant and is perhaps one of the few examples of a new feature >(as opposed to merely a structure cleanup) that would be better to >deploy as a hard fork since it's simple to implement and seems to stand >a reasonable chance of near universal support...and soft fork >alternatives are very, very ugly and significantly impact system >usability...and I think theory tells us we can't do any better. > >- Eric [-- Attachment #2: Type: text/html, Size: 7902 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 16:09 ` Tier Nolan 2015-12-26 21:22 ` Jonathan Toomim 3 siblings, 1 reply; 47+ messages in thread From: Jorge Timón @ 2015-12-26 15:33 UTC (permalink / raw) To: Eric Lombrozo; +Cc: Bitcoin Dev, nbvfour [-- Attachment #1: Type: text/plain, Size: 619 bytes --] On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > Unfortunately, this also means longer confirmation times, lower throughput, and lower miner revenue. Note, however, that confirmations would (on average) represent more PoW, so fewer confirmations would be required to achieve the same level of security. > I'm not sure I understand this. If mining revenue per unit of time drops, total pow per unit of time should also drop. Even if the inter-block time is increased, it's not clear to me that the pow per block would necessarily be higher. What am I missing? [-- Attachment #2: Type: text/html, Size: 780 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 15:33 ` Jorge Timón @ 2015-12-26 17:38 ` Eric Lombrozo 2015-12-26 18:01 ` Jorge Timón 0 siblings, 1 reply; 47+ messages in thread From: Eric Lombrozo @ 2015-12-26 17:38 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev, nbvfour [-- Attachment #1: Type: text/plain, Size: 2186 bytes --] For simplicity, assume total network hashpower is constant. Also, assume the soft fork activates at the beginning of a retarget period. At the moment the soft fork activates, the effective difficulty is increased (by adding a second independent PoW check that must also be satisfied) which means more hashes on average (and proportionally more time) are required to find a block. At the end of the retarget period, the difficulty is lowered so that if the second PoW difficulty were to be kept constant the block interval would again average 10 mins. If we were to keep the second PoW difficulty constant, we would restore the same total PoW-to-time-unit ratio and the retarget difficulty would stabilize again so each block would once more require the same number of hashes (and same amount of time) on average as before. But we don't keep the second PoW difficulty constant - we increase it so once again more hashes on average are required to find a block by the same proportion as before. And we keep doing this. Now, the assumption that hashpower is constant is obviously unrealistic. If this is your bone of contention, then yes, I agree my model is overly simplistic. My larger point was to explore the extent of what's possible with only a soft fork - and we can actually go pretty far and even compensate for these economic shifts by increasing block size and rewards. The whole thing is clearly a huge mess - and I wouldn't recommend actually doing it. On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jtimon@jtimon•cc> wrote: >On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < >bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Unfortunately, this also means longer confirmation times, lower >throughput, and lower miner revenue. Note, however, that confirmations >would (on average) represent more PoW, so fewer confirmations would be >required to achieve the same level of security. >> > >I'm not sure I understand this. If mining revenue per unit of time >drops, >total pow per unit of time should also drop. Even if the inter-block >time >is increased, it's not clear to me that the pow per block would >necessarily >be higher. >What am I missing? [-- Attachment #2: Type: text/html, Size: 2628 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 17:38 ` Eric Lombrozo @ 2015-12-26 18:01 ` Jorge Timón 0 siblings, 0 replies; 47+ messages in thread From: Jorge Timón @ 2015-12-26 18:01 UTC (permalink / raw) To: Eric Lombrozo; +Cc: Bitcoin Dev, nbvfour [-- Attachment #1: Type: text/plain, Size: 2701 bytes --] The hashpower is a function of the block reward (subsidy + fees): it's economically irrational to have costs greater than the reward (better just turn off your miners) and in a perfect competition (a theoretical model) profits tend to zero. That is, the costs tend to equal revenue (block reward). On Dec 26, 2015 6:38 PM, "Eric Lombrozo" <elombrozo@gmail•com> wrote: > For simplicity, assume total network hashpower is constant. Also, assume > the soft fork activates at the beginning of a retarget period. > > At the moment the soft fork activates, the effective difficulty is > increased (by adding a second independent PoW check that must also be > satisfied) which means more hashes on average (and proportionally more > time) are required to find a block. At the end of the retarget period, the > difficulty is lowered so that if the second PoW difficulty were to be kept > constant the block interval would again average 10 mins. > > If we were to keep the second PoW difficulty constant, we would restore > the same total PoW-to-time-unit ratio and the retarget difficulty would > stabilize again so each block would once more require the same number of > hashes (and same amount of time) on average as before. > > But we don't keep the second PoW difficulty constant - we increase it so > once again more hashes on average are required to find a block by the same > proportion as before. And we keep doing this. > > Now, the assumption that hashpower is constant is obviously unrealistic. > If this is your bone of contention, then yes, I agree my model is overly > simplistic. > > My larger point was to explore the extent of what's possible with only a > soft fork - and we can actually go pretty far and even compensate for these > economic shifts by increasing block size and rewards. The whole thing is > clearly a huge mess - and I wouldn't recommend actually doing it. > > > > On December 26, 2015 7:33:53 AM PST, "Jorge Timón" <jtimon@jtimon•cc> > wrote: >> >> >> On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" < >> bitcoin-dev@lists•linuxfoundation.org> wrote: >> >> > Unfortunately, this also means longer confirmation times, lower >> throughput, and lower miner revenue. Note, however, that confirmations >> would (on average) represent more PoW, so fewer confirmations would be >> required to achieve the same level of security. >> > >> >> I'm not sure I understand this. If mining revenue per unit of time drops, >> total pow per unit of time should also drop. Even if the inter-block time >> is increased, it's not clear to me that the pow per block would necessarily >> be higher. >> What am I missing? >> > [-- Attachment #2: Type: text/html, Size: 3240 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 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 16:09 ` Tier Nolan 2015-12-26 18:30 ` Eric Lombrozo 2015-12-26 21:22 ` Jonathan Toomim 3 siblings, 1 reply; 47+ messages in thread From: Tier Nolan @ 2015-12-26 16:09 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1097 bytes --] On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > Unfortunately, this also means longer confirmation times, lower > throughput, and lower miner revenue. Note, however, that confirmations > would (on average) represent more PoW, so fewer confirmations would be > required to achieve the same level of security. > No, the re-target compensates so that the number of blocks in the last two weeks is 2016. If a soft fork forces miners to throw away 25% of their blocks, then the difficulty will drop by 75% to keep things balanced. Throwing away 75% of blocks has the same effect on difficulty as destroying 75% of mining hardware. The block interval will only increase until the next re-target. Slowly increasing the fraction of blocks which are thrown away gives the re-target algorithm time to adjust, so it is another advantage. If the rule was instantly changed so that 95% of blocks were thrown away, then there could be up to 40 weeks until the next retarget and that would give 200 minute block times until the adjustment. [-- Attachment #2: Type: text/html, Size: 1560 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 16:09 ` Tier Nolan @ 2015-12-26 18:30 ` Eric Lombrozo 2015-12-26 19:34 ` Jorge Timón 0 siblings, 1 reply; 47+ messages in thread From: Eric Lombrozo @ 2015-12-26 18:30 UTC (permalink / raw) To: Tier Nolan, Tier Nolan via bitcoin-dev, Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2132 bytes --] I should have stated that we're assuming the actual total hashrate remains constant. Obviously this is not what would actually happen - the rest of the post discusses ways to counter the economic forces at play pushing total hashrate down using only soft forks. The increased variance is still unaccounted for (pool operators would have to deal with this somehow)...and we still have larger block intervals even with compensation. And the practicality of deployment and usability are clearly problematic, to understate things. It's merely an exercise seeking the theoretical limit of what's actually possible to do with a soft fork. On December 26, 2015 8:09:18 AM PST, Tier Nolan via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: >On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev < >bitcoin-dev@lists•linuxfoundation.org> wrote: > >> Unfortunately, this also means longer confirmation times, lower >> throughput, and lower miner revenue. Note, however, that >confirmations >> would (on average) represent more PoW, so fewer confirmations would >be >> required to achieve the same level of security. >> > > >No, the re-target compensates so that the number of blocks in the last >two >weeks is 2016. If a soft fork forces miners to throw away 25% of their >blocks, then the difficulty will drop by 75% to keep things balanced. >Throwing away 75% of blocks has the same effect on difficulty as >destroying >75% of mining hardware. > >The block interval will only increase until the next re-target. > >Slowly increasing the fraction of blocks which are thrown away gives >the >re-target algorithm time to adjust, so it is another advantage. > >If the rule was instantly changed so that 95% of blocks were thrown >away, >then there could be up to 40 weeks until the next retarget and that >would >give 200 minute block times until the adjustment. > > >------------------------------------------------------------------------ > >_______________________________________________ >bitcoin-dev mailing list >bitcoin-dev@lists•linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Type: text/html, Size: 2905 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 18:30 ` Eric Lombrozo @ 2015-12-26 19:34 ` Jorge Timón 0 siblings, 0 replies; 47+ messages in thread From: Jorge Timón @ 2015-12-26 19:34 UTC (permalink / raw) To: Eric Lombrozo; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 312 bytes --] On Dec 26, 2015 7:30 PM, "Eric Lombrozo via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation.org> wrote: > > I should have stated that we're assuming the actual total hashrate remains constant. But that's not reasonable if you are assuming that the total reward per unit of time drops, that's what confused me. [-- Attachment #2: Type: text/html, Size: 450 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 8:23 ` Eric Lombrozo ` (2 preceding siblings ...) 2015-12-26 16:09 ` Tier Nolan @ 2015-12-26 21:22 ` Jonathan Toomim 2015-12-27 4:33 ` Emin Gün Sirer 3 siblings, 1 reply; 47+ messages in thread From: Jonathan Toomim @ 2015-12-26 21:22 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1091 bytes --] Another option for how to deal with block withholding attacks: Give the miner who finds the block a bonus. This could even be part of the coinbase transaction. Block withholding is effective because it costs the attacker 0% and costs the pool 100%. If the pool's coinbase tx was 95% to the pool, 5% (1.25 BTC) to the miner, that would make block withholding attacks much more expensive to the attacker without making a huge impact on reward variance for small miners. If your pool gets attacked by a block withholding attack, then you can respond by jacking up the bonus ratio. At some point, block withholding attacks become unfeasibly expensive to perform. This can work because the pool sacrifices a small amount of variance for its customers by increasing the bonus, but the block attacker sacrifices revenue. This should make the attacker give up before the pool does. This system already exists in p2pool, although there the reward bonus for the block's finder is only 0.5%. This must have been proposed before, right? Anyone know of a good analysis of the game theory math? [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [bitcoin-dev] We need to fix the block withholding attack 2015-12-26 21:22 ` Jonathan Toomim @ 2015-12-27 4:33 ` Emin Gün Sirer 0 siblings, 0 replies; 47+ messages in thread From: Emin Gün Sirer @ 2015-12-27 4:33 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 379 bytes --] >Another option for how to deal with block withholding attacks: Give the miner who finds the block a bonus. ... >This must have been proposed before, right? Anyone know of a good analysis of the game theory math? Yes, Section 8.D. in Ittay's paper discusses this countermeasure, as well as a few others: https://www.cs.cornell.edu/~ie53/publications/btcPoolsSP15.pdf - egs [-- Attachment #2: Type: text/html, Size: 620 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2015-12-29 21:51 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-12-19 18:42 [bitcoin-dev] We need to fix the block withholding attack 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox