[bitcoin-dev] We need to fix the block withholding attack

[bitcoin-dev] We need to fix the block withholding attack

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Bob McElrath]

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 

Re: [bitcoin-dev] We need to fix the block withholding attack

[jl2012]

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Chris Priest]

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
>

Re: [bitcoin-dev] We need to fix the block withholding attack

[Matt Corallo]

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Chris Priest]

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
>
>

Re: [bitcoin-dev] We need to fix the block withholding attack

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Multipool Admin]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Geir Harald Hansen]

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
> 

Re: [bitcoin-dev] We need to fix the block withholding attack

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Emin Gün Sirer]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Multipool Admin]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Multipool Admin]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Ivan Brightly]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Dave Scotese]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jonathan Toomim]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Allen Piscitello]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Dave Scotese]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[jl2012]

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Chris Priest]

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.

Re: [bitcoin-dev] We need to fix the block withholding attack

[jl2012]

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.

Re: [bitcoin-dev] We need to fix the block withholding attack

[Emin Gün Sirer]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Chris Priest]

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.

Re: [bitcoin-dev] We need to fix the block withholding attack

[Emin Gün Sirer]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Natanael]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Tier Nolan]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Natanael]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Tier Nolan]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Emin Gün Sirer]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jannes Faber]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Ittay]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jonathan Toomim]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[benevolent]

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jannes Faber]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Geir Harald Hansen]

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

Re: [bitcoin-dev] We need to fix the block withholding attack

[Peter Todd]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Eric Lombrozo]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Eric Lombrozo]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Eric Lombrozo]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Tier Nolan]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Eric Lombrozo]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jorge Timón]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Jonathan Toomim]

[-- 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 --]

Re: [bitcoin-dev] We need to fix the block withholding attack

[Emin Gün Sirer]

[-- 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 --]