From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 15 Aug 2024 20:47:23 -0700 Received: from mail-qv1-f63.google.com ([209.85.219.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1senvv-0001Iw-42 for bitcoindev@gnusha.org; Thu, 15 Aug 2024 20:47:23 -0700 Received: by mail-qv1-f63.google.com with SMTP id 6a1803df08f44-6bf6da864a6sf16864666d6.3 for ; Thu, 15 Aug 2024 20:47:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1723780036; cv=pass; d=google.com; s=arc-20160816; b=hvsUB8j6ugou9AfS4K3ig7uOqzFQeaa1MNw/aAI2tVhNQNQO3FEEQOECeOcYRyYbHH 9Fa7Y/Ikq+FuXlvZPEK2wmxiuFornEvIiSU//UGOEy/0vvSupqR5TN+OJRKAo2jApiUx ArPQWFVf2gSiwgSc/nOPgMe6P2MMWET0ZwzlnrNMlL6APEmOPHKxFZMQeifvRst1wZf6 2j76Ryl2/TuMHjI4xBIg0HwkOL29G2hUzi8DYbqu0FDGRw+t32NhUo5+kw4gu6nLcFD7 1wa9TdFUvsBFaJpJM/m4DlHtekHRJAodAS1uMQYn+fnfPfxykj57Bws07kCJA5sEwuTL g8uQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=u4WuQVdfXD9fSmSoXPgRYH8Vjv9q+iVb8sYsv3m1EAI=; fh=9D5/xjpgDdICoQW0xKDYkXScpiECRgIL0UaWjZfrzao=; b=FbJFKn2jSwMobQcQgLrSnvQyJFEHJ5YfPn9/lzFQRJ8CfD/9p0N832Am4B28ZTuqXV lS66U53s/vDT6YeasyvhT9SzrLWg9sIu1VWyMUZYYmwPnqgX1vbngBUHVeiZsPsmZ+F6 mpbsn7GyLLDrsWz7eVqae+Lh6LQBo46CeLcRyNd48ubHSJihmWa9J+azn6UH4Q2lI777 pVu0D9JHTjoNgfcepRtx+RdaDVI0Uo3Z+ESgSzG9Zp1O6vB7jV3O7J8rlF6TMvmc3O6w Jhj04p/wRMe2GlVy8GYtULiDkQGoULEpIcY7AZRGrkqU0Onyb+khEnkqkFnuuDbZ0Pnk daTg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1723780036; x=1724384836; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to; bh=u4WuQVdfXD9fSmSoXPgRYH8Vjv9q+iVb8sYsv3m1EAI=; b=gxnps2rS8xXtjATylMIVxDixMDEeBqzWjFurupjT6/Qyzoeq67ltns2uXWvLOQ8vbC qaHatNnriGOu4dmapDod1dU/MEXoJrGloSCqAiX3UUrprAoc2YIBeMmhYUC/Y/VB2NrT 6zRbM9woCu3FuJqJc1lajUKIksYDsJ9Pbh7/4tYg1nw6zl2SsFhpTE3ASo26G+JOuX7G hFdYIrutXe4lxiGTI/kCHuA9ySDzCAQbHZ77CtgcqdFlzkE7EHfRtTq8fZGq9kw3HO0T SpjB1poee47uhz9LqmVOCi+iUlkAjUkocXnF5WXY/tgIg2kSre0h2ltfOdH5qbuexlH3 OYAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723780036; x=1724384836; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=u4WuQVdfXD9fSmSoXPgRYH8Vjv9q+iVb8sYsv3m1EAI=; b=BtOjeaLfcpi0PDwk+wjtS047RX9XnjJ1pIz7nHTdAJrGOhZulpiCGf+TArTLoeAZSs /9ssknSw0OWkGCmTcHKqY5o1Z/qXCcMp25DsxyiClDBT0lPZa2WE3Tz0KCWkUl5IjQQB C3rvmIezotAWJprD36OsQs50AvEvovja2tMp7o98rgMGFO/4Z+gw+bcn7muUYRz5x9vh Wpy0/AL/mG35vKPJhR8If1dVt18VE0wCqqvGTaZZ3b6PUqFtWP1103ybabs0cSc0Rb+2 BvyQVpVoB0ebpaBAHlXhzbnEfH7uLAAWA350NcLq6kAtiGM8+zOAsPJ6tBmVabh1gCG7 egnw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCU8e2+pyXd7Y1x1wDJTkaOs6fGHzaAWqpJwBDx4hY7/mlmGY3mIL1mMTDzGxt9ARbHnen27AIMRWt4yAauO6c2AXweuSMw= X-Gm-Message-State: AOJu0YwZ4V1rH5V0OXbMivrD6dDVyqnJP/XuGMk3TR/54v+s6CTgbiZH xu4uwyLywNKvq6/3vJxzxI++BATBZtjXyt6wUch2sdtLKLaWNZyr X-Google-Smtp-Source: AGHT+IHfUYjc4mLsBLscGCeWGVZ4Fd4nkq7dwjyeDpszDZzEbQ5eX9u23xD9LtfXO4TAN/7uVCxHTw== X-Received: by 2002:ad4:4bb1:0:b0:6bf:7f11:3fac with SMTP id 6a1803df08f44-6bf7f114174mr7549966d6.44.1723780036207; Thu, 15 Aug 2024 20:47:16 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6214:2607:b0:6b5:f4e:9d67 with SMTP id 6a1803df08f44-6bf6d39ef92ls31659036d6.0.-pod-prod-05-us; Thu, 15 Aug 2024 20:47:14 -0700 (PDT) X-Received: by 2002:a05:6214:21a1:b0:6b7:ab15:a5c7 with SMTP id 6a1803df08f44-6bf7ce7b149mr1122146d6.12.1723780034044; Thu, 15 Aug 2024 20:47:14 -0700 (PDT) Received: by 2002:a05:620a:1:b0:79c:bd3:58c5 with SMTP id af79cd13be357-7a507f7f1b3ms85a; Thu, 15 Aug 2024 19:11:13 -0700 (PDT) X-Received: by 2002:a05:620a:2483:b0:79f:1809:afc2 with SMTP id af79cd13be357-7a5069d1afbmr149895885a.45.1723774272603; Thu, 15 Aug 2024 19:11:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1723774272; cv=none; d=google.com; s=arc-20160816; b=vdl4qHTMvfmOhSCDHUFvIYUrvw/Xut/cyyGJLh5fVnb8UT+YqgHwcbuOcYI82GuZ4z UIm1/kJMR3wawH/w/Nto53YSzYdzRzseGLZdf/UyDdYnRxhqWDWSTHb3UAqxtxL/6RvH FmcnSGFXXWyl5HU7JkoNU3PFrNxp3sP1nPQqxLQA22lnUD8rlLFZ6tmV1Bp2oz03Co0M Zta1jkiFJCipHFzKKMqwytdJ3PsBP9Zy4sKj92xPdvTPcDpJvLwVG8foMDnw9SRe5hTj UanZbXeUl8DJre4jAhTA17miSsZmGAi6jIN2Ka0jiKKwkaB2M6Kp/RtiAB3dNgViTNLc rn1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date; bh=ycuOxX5Kz+KCq2BK9n5IAjHYw8MIBd9RpIDFWbCrn1U=; fh=QeX9rcZFbTLJsBh4PJSh4yeJazhXI8eiMyjXjq43dsI=; b=bThb6oXMZGU/sTanT2gcH01pKz3fQPn+sK4rnOgPe1WA4x1pX5yEhdVwWP6g+g1uGP WOU0HK3uWayMrswlKbUZNbBXVta9n4N77TsceMRk+X6Pe0HooQgzI6J76cPU70BBwsIw nMM6MLX03CZyDaPLxDG7RpFp5zdX2sMCk9idJvskBjMcf/O7iTyLe/HgLd73OPZv6pEV svSr5SnDEht2jzKPBlsA3ZC4GjiMxDwTJg3zlgNWFbyAZNdBdX6ej8bMrTnOJlDXqP+U l1cCaJktCXJdt2gkJlPBvJsD2E5rXjZZ95fuTVcZY+VI2XFSwiUGMHVtc0Z6uQD7k2+K 1Z5Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Received: from cerulean.erisian.com.au (azure.erisian.com.au. [172.104.61.193]) by gmr-mx.google.com with ESMTPS id af79cd13be357-7a4ff0c86cfsi11517785a.5.2024.08.15.19.11.12 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Aug 2024 19:11:12 -0700 (PDT) Received-SPF: pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) client-ip=172.104.61.193; Received: from aj@azure.erisian.com.au by cerulean.erisian.com.au with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1semQj-0000ec-8T; Fri, 16 Aug 2024 12:11:07 +1000 Received: by email (sSMTP sendmail emulation); Fri, 16 Aug 2024 12:10:59 +1000 Date: Fri, 16 Aug 2024 12:10:59 +1000 From: Anthony Towns To: Matt Corallo Cc: bitcoindev@googlegroups.com Subject: Re: [bitcoindev] Mining pools, stratumv2 and oblivious shares Message-ID: References: <26322ee8-08e6-4718-8d1c-60bca8c13c6a@mattcorallo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: <26322ee8-08e6-4718-8d1c-60bca8c13c6a@mattcorallo.com> X-Spam_score: -0.0 X-Spam_bar: / X-Original-Sender: aj@erisian.com.au X-Original-Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of aj@erisian.com.au designates 172.104.61.193 as permitted sender) smtp.mailfrom=aj@erisian.com.au Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) 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.