From: Anthony Towns <aj@erisian•com.au>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Mining pools, stratumv2 and oblivious shares
Date: Fri, 16 Aug 2024 12:10:59 +1000 [thread overview]
Message-ID: <Zr61M64kQlYIBuzO@erisian.com.au> (raw)
In-Reply-To: <26322ee8-08e6-4718-8d1c-60bca8c13c6a@mattcorallo.com>
On Tue, Aug 13, 2024 at 09:57:06AM -0400, Matt Corallo wrote:
> Yes, block witholding attacks are easy to do. This has nothing to do with
> client work selection or not, its just...a fact of life with Bitcoin pooled
> mining.
>
> Doing block withholding by creating invalid templates I'd really call
> "shitty block withholding"
Hmm, I thought "BlueMatt" was referring to hair colour, not language
preference.
> cause at least the pool *can* detect it (with
> additional CPU power), vs traditional block withholding attacks they can
> only use statistical analysis.
>
> In fact, any statistical analysis you can do to detect traditional block
> withholding attacks also applies equally to any "shitty block withholding"
> attacks - the outcome (no valid blocks from a miner, but shares) is the
> same, so any relevant defenses apply equally.
The only way you can do statistical analyses is if miners (including
attackers) can be assigned a persistent identity with reasonable accuracy,
and you restrict your pool to accepting individual miners with a large
enough hashrate that they're expected to find a valid block relatively
frequently.
If individuals aren't required to have a large hashrate, an attacker can
just pretend to be multiple miners with small hashrate, all of whom are
unlucky, and your statistical result is just "my small hashrate miners
are in aggregate more unlucky than I expect", without providing a way to
distinguish the attacker's small hashrate identities from honest small
hashrate miners.
If "relatively frequently" is a year or less, that means only about 50k
companies/individuals globally can potentially be miners participating
in a pool, and far less if hashpower is not evenly distributed amongst
miners.
If you're relying on some combination of burdensome KYC, statistics and
restricting pool membership to large hashrate miners, then that's fine:
block withholding is fairly easily addressed. What I'm interested in is
a pool that doesn't do those things: for example, a world where 5% of
hashrate is from 60M BitAxe devices owned by 10M people, say. Solo-mining,
each person might expect to find a block once every 4000 years; with
pooled mining, they'd expect to be paid perhaps 80c per day. But in that
scenario, a pool with 30% hashrate running a block withholding attack
using 1% of hashrate increases their total reward (from 30% to 30.1%)
while cutting the honest bitaxe miners' rewards substantially (from 5%
to 4.2%, or 80c to 67c).
And in that scenario, it seems relatively easy for the attacker to
pretend to be 2M different users, *unless* you're doing real KYC on
every bitaxe miner at signup, in which case whoever you're outsourcing
KYC too becomes your centralising factor ("whoops, your social credit
score is too low to be allowed to be a bitcoin miner").
If the pool is not doing KYC, but does have some soft/hard-forked solution
like oblivious shares, and allows users to choose their block contents,
that's the point at which the invalid block appraoch comes in: you can
still perform effectively the exact same attack, simply by having your 1%
hashrate mining invalid shares rather than withholding the shares that
would be valid blocks. If the pool isn't validating every share, then
you'll only be detected when your share did turn out to be valid PoW, but
once you're detected you simply kill that identity and spin up a new one,
and because the pool isn't doing KYC, spinning up a new identity is easy.
As far as I can see that means your pool is either:
a) heavily KYCed
b) limited to high-hashrate miners
c) fully validating every share
d) vulnerable to block-withholding attacks, and hence not viable in
the long term in a competitive environment
Of those, "fully validating every share" seems the most appealing option
to me, but in practical terms, that seems incompatible with "any miner
can freely choose the txs they work on". In practice, of course, (a)
and (b) will presumably be the reality for the forseeable future for
all but a fairly trivial amount of hashrate.
> Adding more explicit "negotiation" to Stratum V2 work selection would defeat
> the purpose - if the pool is able to tell a miner not to work on some work
> it wants to, ...
A pool is always able to do that -- they can simply mark the share as
invalid after the fact and refuse to pay out on it, and perhaps make
a blog post explaining their policy. The over-the-wire protocol isn't
what provides that ability.
That's also precisely what they have to do if they detect a block
withholding attack by statistical methods: start refusing to pay out
for otherwise valid shares, based on non-consensus rules ("your account
has been banned", "your ip came from a range that seems suspicious",
"you don't have enough hashrate to be a member of this pool", ...).
> ... you might as well just have the pool pick the work.
> The only
> way any kind of centralized pooling with custom work selection adds any
> value to Bitcoin's decentralization is if the clients insist on mining the
> work they want to - whether on the pool or solo mining if the pool doesn't
> want it.
If you're really expecting miners are going to be constantly telling
their pool "do exactly what I want or I solo mine", I think you're pretty
likely to be disappointed by whatever the future holds... By its nature,
solo mining is something that can only be done profitably by relatively
few players at any given time; it's only potentially decentralised if the
total market for Bitcoin ownership/usage is itself very small.
Heck, we can observe right now that even *pools* aren't willing to insist
on the right to choose their own work when they can get smoother payouts
by letting someone else choose the work.
The only realistic way I see to improve mining decentralisation is
to make it easier to setup a viable competing pool when none of the
existing ones are being reasonable. If setting up a pool requires you
to do statistical analysis and setup KYC to avoid attacks from existing
players, that seems like a pretty big road-block.
Cheers,
aj
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zr61M64kQlYIBuzO%40erisian.com.au.
next prev parent reply other threads:[~2024-08-16 3:47 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-23 15:02 Anthony Towns
2024-07-23 18:44 ` Luke Dashjr
2024-07-31 18:00 ` Anthony Towns
2024-08-13 13:57 ` Matt Corallo
2024-08-16 2:10 ` Anthony Towns [this message]
2024-08-21 14:28 ` Matt Corallo
2024-08-27 9:07 ` Anthony Towns
2024-08-27 13:52 ` Matt Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zr61M64kQlYIBuzO@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox