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

[Peter Todd via bitcoin-dev]

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/

[Bob McElrath via bitcoin-dev]

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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

[jl2012 via bitcoin-dev]

After the meeting I find a softfork solution. It is very inefficient and
I am leaving it here just for record.

1. In the first output of the second transaction of a block, mining pool
will commit a random nonce with an OP_RETURN.

2. Mine as normal. When a block is found, the hash is concatenated with
the committed random nonce and hashed.

3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the block
is invalid. That means about 1% of blocks are discarded.

4. For each difficulty retarget, the secondary target is decreased by 2
^ 1/64.

5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
252. Therefore only 1 in 16 hash returned by hasher is really valid.
This should make the detection of block withholding attack much easier.

All miners have to sacrifice 1% reward for 10 years. Confirmation will
also be 1% slower than it should be.

If a node (full or SPV) is not updated, it becomes more vulnerable as an
attacker could mine a chain much faster without following the new rules.
But this is still a softfork, by definition.

---------------

ok, back to topic. Do you mean this?
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.html

Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Chris Priest via bitcoin-dev]

Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of hashpower decided to pull off this attack,
they wouldn't be able to disrupt much. Once that time comes, then I
think this problem should be solved, until then it should be a low
priority. There are more important things to work on in the meantime.

On 12/19/15, Peter Todd via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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/
--
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d

[Matt Corallo via bitcoin-dev]

Peter was referring to pool-block-withholding, not selfish mining.

Post by Chris Priest via bitcoin-dev
Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of hashpower decided to pull off this attack,
they wouldn't be able to disrupt much. Once that time comes, then I
think this problem should be solved, until then it should be a low
priority. There are more important things to work on in the meantime.
On 12/19/15, Peter Todd via bitcoin-dev

Post by Peter Todd via bitcoin-dev
At the recent Scaling Bitcoin conference in Hong Kong we had a

chatham

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
are receiving legitimate threats by bad actors threatening to use

block

Post by Peter Todd via bitcoin-dev
withholding attacks against them. Pools offering their services to

the

Post by Peter Todd via bitcoin-dev
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,

Post by Peter Todd via bitcoin-dev
but it itself is still relatively vulnerable to block withholding,

and

Post by Peter Todd via bitcoin-dev
in any case has many other vulnerabilities and technical issues that

has

Post by Peter Todd via bitcoin-dev
prevented widespread adoption of P2Pool.
Fixing block withholding is relatively simple, but (so far) requires

a

Post by Peter Todd via bitcoin-dev
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We

should

Post by Peter Todd via bitcoin-dev
do this hard-fork in conjunction with any blocksize increase, which

will

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
by small pools against larger pools, disincentivising large pools.
However this argument is academic and not applicable to the real

world,

Post by Peter Todd via bitcoin-dev
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/
--
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Chris Priest via bitcoin-dev]

Then shouldn't this be something the pool deals with, not the bitcoin protocol?

Post by Matt Corallo via bitcoin-dev
Peter was referring to pool-block-withholding, not selfish mining.
On December 19, 2015 7:34:26 PM PST, Chris Priest via bitcoin-dev

Post by Chris Priest via bitcoin-dev
Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of hashpower decided to pull off this attack,
they wouldn't be able to disrupt much. Once that time comes, then I
think this problem should be solved, until then it should be a low
priority. There are more important things to work on in the meantime.
On 12/19/15, Peter Todd via bitcoin-dev

Post by Peter Todd via bitcoin-dev
At the recent Scaling Bitcoin conference in Hong Kong we had a

chatham

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
are receiving legitimate threats by bad actors threatening to use

block

Post by Peter Todd via bitcoin-dev
withholding attacks against them. Pools offering their services to

the

Post by Peter Todd via bitcoin-dev
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,

Post by Peter Todd via bitcoin-dev
but it itself is still relatively vulnerable to block withholding,

and

Post by Peter Todd via bitcoin-dev
in any case has many other vulnerabilities and technical issues that

has

Post by Peter Todd via bitcoin-dev
prevented widespread adoption of P2Pool.
Fixing block withholding is relatively simple, but (so far) requires

a

Post by Peter Todd via bitcoin-dev
SPV-visible hardfork. (Luke-Jr's two-stage target mechanism) We

should

Post by Peter Todd via bitcoin-dev
do this hard-fork in conjunction with any blocksize increase, which

will

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
by small pools against larger pools, disincentivising large pools.
However this argument is academic and not applicable to the real

world,

Post by Peter Todd via bitcoin-dev
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/
--
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Chris Priest via bitcoin-dev
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.

[Multipool Admin via bitcoin-dev]

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 <

Post by Chris Priest via bitcoin-dev

Post by Chris Priest via bitcoin-dev
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.
--
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Geir Harald Hansen via bitcoin-dev]

Last I heard it was believed the miner had made their own mining client
and that the block withholding was a bug, not an intended feature.

Post by Multipool Admin via bitcoin-dev
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
On Sat, Dec 19, 2015 at 07:43:59PM -0800, Chris Priest via

Post by Chris Priest via bitcoin-dev
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.
--
00000000000000000188b6321da7feae60d74c7b0becbdab3b1a0bd57f10947d
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Peter Todd via bitcoin-dev]

Post by Multipool Admin via bitcoin-dev
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.

Post by Multipool Admin via bitcoin-dev
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.

Post by Multipool Admin via bitcoin-dev
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)

[Emin Gün Sirer via bitcoin-dev]

On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <

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

[Multipool Admin via bitcoin-dev]

On Mon, Dec 28, 2015 at 11:30 AM, Emin GÃŒn Sirer <

Post by Emin Gün Sirer via bitcoin-dev
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <

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.

Post by Emin Gün Sirer via bitcoin-dev
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

[Multipool Admin via bitcoin-dev]

Post by Peter Todd via bitcoin-dev

Post by Multipool Admin via bitcoin-dev
Any attempt to 'fix' this problem, would most likely require changes to

all

Post by Multipool Admin via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
Eligius already does their miner payouts like this.

Post by Multipool Admin via bitcoin-dev
If you want to fix an issue with mining, fix the selfish mining issue

first

Post by Multipool Admin via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev

Post by Multipool Admin via bitcoin-dev
I don't believe it was ever clearly established whether Eligius suffered

a

Post by Multipool Admin via bitcoin-dev
block withholding attack or was just the victim of a miner with (what

was,

Post by Multipool Admin via bitcoin-dev
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

[Ivan Brightly via bitcoin-dev]

Post by Emin Gün Sirer via bitcoin-dev
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <
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.

[Dave Scotese via bitcoin-dev]

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 <

Post by Emin Gün Sirer via bitcoin-dev
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <

Post by Peter Todd via bitcoin-dev
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
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

[Jonathan Toomim via bitcoin-dev]

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

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
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.
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
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Dave Scotese via bitcoin-dev]

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 <

How could this possibly be enforced?
On Tue, Dec 29, 2015 at 12:59 PM, Dave Scotese via bitcoin-dev <

Post by Dave Scotese via bitcoin-dev
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
- 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 <

Post by Emin Gün Sirer via bitcoin-dev
On Mon, Dec 28, 2015 at 2:12 PM, Peter Todd via bitcoin-dev <

Post by Peter Todd via bitcoin-dev
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
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
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

[Chris Priest via bitcoin-dev]

Post by Chris Priest via bitcoin-dev
Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of hashpower decided to pull off this attack,
they wouldn't be able to disrupt much. Once that time comes, then I
think this problem should be solved, until then it should be a low
priority. There are more important things to work on in the meantime.

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.

[jl2012 via bitcoin-dev]

Post by Chris Priest via bitcoin-dev

Post by Chris Priest via bitcoin-dev
Block witholding attacks are only possible if you have a majority of
hashpower. If you only have 20% hashpower, you can't do this attack.
Currently, this attack is only a theoretical attack, as the ones with
all the hashpower today are not engaging in this behavior. Even if
someone who had a lot of hashpower decided to pull off this attack,
they wouldn't be able to disrupt much. Once that time comes, then I
think this problem should be solved, until then it should be a low
priority. There are more important things to work on in the meantime.

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.

Post by Chris Priest via bitcoin-dev
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.

[Chris Priest via bitcoin-dev]

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.

[Emin Gün Sirer via bitcoin-dev]

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

[Natanael via bitcoin-dev]

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.

[Tier Nolan via bitcoin-dev]

On Sun, Dec 20, 2015 at 5:12 AM, Emin GÃŒn Sirer <

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.

[Natanael via bitcoin-dev]

Den 20 dec 2015 12:38 skrev "Tier Nolan via bitcoin-dev" <

Post by Tier Nolan via bitcoin-dev
On Sun, Dec 20, 2015 at 5:12 AM, Emin GÃŒn Sirer <

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.

Post by Tier Nolan via bitcoin-dev
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.

[Tier Nolan via bitcoin-dev]

Post by Natanael via bitcoin-dev
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

Post by Natanael via bitcoin-dev
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.

[Peter Todd via bitcoin-dev]

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.

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.

[Emin Gün Sirer via bitcoin-dev]

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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 -

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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

[Jannes Faber via bitcoin-dev]

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 <

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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 -

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Ittay via bitcoin-dev]

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 <

Post by Jannes Faber via bitcoin-dev
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 <

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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 -

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jonathan Toomim via bitcoin-dev]

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.

[Jannes Faber via bitcoin-dev]

Post by Ittay via bitcoin-dev
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.

Post by Ittay via bitcoin-dev
On Mon, Dec 21, 2015 at 1:39 PM, Jannes Faber via bitcoin-dev <

Post by Jannes Faber via bitcoin-dev
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?

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev
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.

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev
Sorry if i misunderstood your point.
--
Jannes
On 20 December 2015 at 18:00, Emin GÃŒn Sirer <

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

Post by Peter Todd via bitcoin-dev
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,

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
etc) band together into small pools. These are fantastic outcomes for
decentralization.

Post by Peter Todd via bitcoin-dev
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

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
a remote node is indeed running the code that it purports to be

running. Since

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
most problems in computer security and distributed systems stem from not
knowing what protocol the attacker is going to follow, attestation is

the only

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
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

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev
of the cloudhashing scams would put an end to a lot of heartache.

Post by Peter Todd via bitcoin-dev

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.

Post by Peter Todd via bitcoin-dev
Currently a significant % of the hashing power - possibly a majority -
is in the form of large hashing installations whose owners

individually,

Post by Ittay via bitcoin-dev

Post by Jannes Faber via bitcoin-dev

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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

Post by Peter Todd via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[benevolent--- via bitcoin-dev]

Post by Ittay via bitcoin-dev
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

[Geir Harald Hansen via bitcoin-dev]

Post by Emin Gün Sirer via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev
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

[Peter Todd via bitcoin-dev]

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev
Secondly, DRM tech can also easily be used to prevent block withholding

Post by Peter Todd via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

Post by Emin Gün Sirer via bitcoin-dev

Post by Peter Todd via bitcoin-dev
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.

[Eric Lombrozo via bitcoin-dev]

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.

Post by jl2012 via bitcoin-dev
After the meeting I find a softfork solution. It is very inefficient
and I am leaving it here just for record.
1. In the first output of the second transaction of a block, mining
pool will commit a random nonce with an OP_RETURN.
2. Mine as normal. When a block is found, the hash is concatenated with
the committed random nonce and hashed.
3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the
block is invalid. That means about 1% of blocks are discarded.
4. For each difficulty retarget, the secondary target is decreased by 2
^ 1/64.
5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
252. Therefore only 1 in 16 hash returned by hasher is really valid.
This should make the detection of block withholding attack much easier.
All miners have to sacrifice 1% reward for 10 years. Confirmation will
also be 1% slower than it should be.
If a node (full or SPV) is not updated, it becomes more vulnerable as
an attacker could mine a chain much faster without following the new
rules. But this is still a softfork, by definition.

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

[Jorge Timón via bitcoin-dev]

On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <

Post by Eric Lombrozo via bitcoin-dev
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?

[Eric Lombrozo via bitcoin-dev]

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.

Post by Jorge Timón via bitcoin-dev
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <

Post by Eric Lombrozo via bitcoin-dev
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?

[Jorge Timón via bitcoin-dev]

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

Post by Eric Lombrozo via bitcoin-dev
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.

Post by Jorge Timón via bitcoin-dev
On Dec 26, 2015 9:24 AM, "Eric Lombrozo via bitcoin-dev" <

Post by Eric Lombrozo via bitcoin-dev
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?

[Tier Nolan via bitcoin-dev]

On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
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.

[Eric Lombrozo via bitcoin-dev]

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.

Post by Tier Nolan via bitcoin-dev
On Sat, Dec 26, 2015 at 8:23 AM, Eric Lombrozo via bitcoin-dev <

Post by Eric Lombrozo via bitcoin-dev
Unfortunately, this also means longer confirmation times, lower
throughput, and lower miner revenue. Note, however, that

confirmations

Post by Eric Lombrozo via bitcoin-dev
would (on average) represent more PoW, so fewer confirmations would

be

Post by Eric Lombrozo via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[Jorge Timón via bitcoin-dev]

On Dec 26, 2015 7:30 PM, "Eric Lombrozo via bitcoin-dev" <

Post by Eric Lombrozo via bitcoin-dev
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.

[Jonathan Toomim via bitcoin-dev]

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?

[Emin Gün Sirer via bitcoin-dev]

Post by Jonathan Toomim via bitcoin-dev
Another option for how to deal with block withholding attacks: Give the

miner who finds the block a bonus.
...

Post by Jonathan Toomim via bitcoin-dev
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

[Eric Lombrozo via bitcoin-dev]

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" <***@gmail.com>
To: "Peter Todd" <***@petertodd.org>; "Emin GÃŒn Sirer"
<***@gmail.com>
Cc: ***@gmail.com; "Bitcoin Dev"
<bitcoin-***@lists.linuxfoundation.org>
Sent: 12/26/2015 12:23:38 AM
Subject: Re[2]: [bitcoin-dev] We need to fix the block withholding
attack

Post by Peter Todd via bitcoin-dev
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.

Post by jl2012 via bitcoin-dev
After the meeting I find a softfork solution. It is very inefficient
and I am leaving it here just for record.
1. In the first output of the second transaction of a block, mining
pool will commit a random nonce with an OP_RETURN.
2. Mine as normal. When a block is found, the hash is concatenated
with the committed random nonce and hashed.
3. The resulting hash must be smaller than 2 ^ (256 - 1/64) or the
block is invalid. That means about 1% of blocks are discarded.
4. For each difficulty retarget, the secondary target is decreased by
2 ^ 1/64.
5. After 546096 blocks or 10 years, the secondary target becomes 2 ^
252. Therefore only 1 in 16 hash returned by hasher is really valid.
This should make the detection of block withholding attack much
easier.
All miners have to sacrifice 1% reward for 10 years. Confirmation will
also be 1% slower than it should be.
If a node (full or SPV) is not updated, it becomes more vulnerable as
an attacker could mine a chain much faster without following the new
rules. But this is still a softfork, by definition.

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