From: Matt Corallo <lf-lists@mattcorallo•com>
To: Anthony Towns <aj@erisian•com.au>
Cc: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] Mining pools, stratumv2 and oblivious shares
Date: Wed, 21 Aug 2024 10:28:35 -0400 [thread overview]
Message-ID: <c6f1dbbd-f4a3-4783-9e5a-6a64e82fc268@mattcorallo.com> (raw)
In-Reply-To: <Zr61M64kQlYIBuzO@erisian.com.au>
On 8/15/24 10:10 PM, Anthony Towns wrote:
> On Tue, Aug 13, 2024 at 09:57:06AM -0400, Matt Corallo wrote:
> 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.
Yep.
-snip-
> 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.
Except "fully validating every share" doesn't change anything. You totally missed the point that
both I and Luke raised - you can fully validate every share, or not, but either way block
withholding requires some kind of statistical analysis to detect, subject to the limitations you raise.
>> 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.
A pool can decline to pay out, yes, but the miner will still work on that block. The point of custom
work selection is that the miner will *always* work on the block they want, no matter what. And if
they mind it, they broadcast it directly themselves. Anything else would defeat the point.
A pool can send their users an email and ask them to change the rules of what they mine on, but it
then requires an active action taken by the miner to change what they want to mine on.
>> 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.
You're totally missing the point that pools can just...pay out properly? Or if they don't people
will create new pools that do? Not sure why you think that's a far-fetched outcome.
Matt
--
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/c6f1dbbd-f4a3-4783-9e5a-6a64e82fc268%40mattcorallo.com.
next prev parent reply other threads:[~2024-08-21 14:41 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
2024-08-21 14:28 ` Matt Corallo [this message]
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=c6f1dbbd-f4a3-4783-9e5a-6a64e82fc268@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.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