Emin Gün Sirer [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-20 📝 Original message:On Sun, Dec 20, 2015 at ...

📅 Original date posted:2015-12-20
📝 Original message:On Sun, Dec 20, 2015 at 8:28 AM, Peter Todd <pete at petertodd.org> wrote:

> There are a number of techniques that can be used to detect block
> withholding attacks that you are not aware of. These techniques usually
> have the characteristic that if known they can be avoided, so obviously
> those who know about them are highly reluctant to reveal what exactly
> they are. I personally know about some of them and have been asked to
> keep that information secret, which I will.
>

Indeed, there are lots of weak measures that one could employ against
an uninformed attacker. As I mentioned before, these are unlikely to be
effective against a savvy attacker, and this is a good thing.


> In the context of KYC, this techniques would likely hold up in court,
> which means that if this stuff becomes a more serious problem it's
> perfectly viable for large, well-resourced, pools to prevent block
> withholding attacks, in part by removing anonymity of hashing power.
> This would not be a positive development for the ecosystem.
>

KYC has a particular financial-regulation connotation in Bitcoin circles,
of which I'm sure you're aware, and which you're using as a spectre.
You don't mean government-regulated-KYC a la FINCEN and Bitcoin
exchanges like Coinbase, you are just referring to a pool operator
demanding to know that its customer is not coming from its competitors'
data centers.

And your prediction doesn't seem well-motivated or properly justified.
There are tons of conditionals in your prediction, starting with the premise
that every single open pool would implement some notion of identity
checking. I don't believe that will happen. Instead, we will have the bigger
pools become more suspicious of signing up new hash power, which is a
good thing. And we will have small groups of people who have some reason
for trusting each other (e.g. they know each other from IRC, conferences,
etc) band together into small pools. These are fantastic outcomes for
decentralization.

Secondly, DRM tech can also easily be used to prevent block withholding
> attacks by attesting to the honest of the hashing power. This is being
> discussed in the industry, and again, this isn't a positive development
> for the ecosystem.
>

DRM is a terrible application. Once again, I see that you're trying to use
those
three letters as a spectre as well, knowing that most people hate DRM, but
keep in mind that DRM is just an application -- it's like pointing to Adobe
Flash
to taint all browser plugins.

The tech behind DRM is called "attestation," and it provides a technical
capability not possible by any other means. In essence, attestation can
ensure that
a remote node is indeed running the code that it purports to be running.
Since
most problems in computer security and distributed systems stem from not
knowing what protocol the attacker is going to follow, attestation is the
only
technology we have that lets us step around this limitation.

It can ensure, for instance,
- that a node purporting to be Bitcoin Core (vLatest) is indeed running an
unadulterated, latest version of Bitcoin Core
- that a node claiming that it does not harvest IP addresses from SPV
clients indeed does not harvest IP addresses.
- that a cloud hashing outfit that rented out X terahashes to a user did
indeed rent out X terahashes to that particular user,
- that a miner operating on behalf of some pool P will not misbehave and
discard perfectly good blocks
and so forth. All of these would be great for the ecosystem. Just getting
rid
of the cloudhashing scams would put an end to a lot of heartache.

> Keep in mind that when an open pool gets big, like GHash did and
> > two other pools did before them, the only thing at our disposal used
> > to be to yell at people about centralization until they left the big
> > pools and reformed into smaller groups. Not only was such yelling
> > kind of desperate looking, it wasn't incredibly effective, either.
> > We had no protocol mechanisms that put pressure on big pools to
> > stop signing up people. Ittay's discovery changed that: pools that
> > get to be very big by indiscriminately signing up miners are likely to
> > be infiltrated and their profitability will drop. And Peter's post is
> > evidence that this is, indeed, happening as predicted. This is a
> > good outcome, it puts pressure on the big pools to not grow.
>
> GHash.io was not a pure pool - they owned and operated a significant
> amount of physical hashing power, and it's not at all clear that their %
> of the network actually went down following that 51% debacle.
>

Right, it's not clear at all that yelling at people has much effect. As much
fun as I had going to that meeting with GHash in London to ask them to
back down off of the 51% boundary, I am pretty sure that yelling at large
open pools will not scale. We needed better mechanisms for keeping pools
in check.

And Miner's Dilemma (MD) attacks are clearly quite effective. This is a
time when we should count our blessings, not work actively to render
them inoperable.

Currently a significant % of the hashing power - possibly a majority -
> is in the form of large hashing installations whose owners individually,
> and definitely in trusting groups, have enough hashing power to solo
> mine. Eyal's results indicate those miners have incentives to attack
> pools, and additionally they have the incentive of killing off pools to
> make it difficult for new competition to get established, yet they
> themselves are not vulnerable to that attack.
>

There are indeed solo miners out there who can attack the big open
pools. The loss of the biggest open pools would not be a bad outcome.
Pools >25% pose a danger, and the home miner doesn't need a pool
>25% for protection against variance.

> Peter, you allude to a specific suggestion from Luke-Jr. Can you
> > please describe what it is?
>
> Basically you have the pool pick a secret k for each share, and commit
> to H(k) in the share. Additionally the share commits to a target divider
> D. The PoW validity rule is then changed from H(block header) < T, to be
> H(block header) < T * D && H(H(block header) + k) < max_int / D
>

Thanks, this requires a change to the Bitcoin PoW. Good luck with that!

Once again, this suggestion would make the GHash-at-51% situation
possible again. Working extra hard to re-enable those painful days
sounds like a terrible idea.

- egs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151220/9b9bc3ea/attachment-0001.html>;