path: root/5f/ccad8f0e126b0f19c27099f506dca5869926e4

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 07E1EC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Dec 2021 23:14:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id D6E1742971
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Dec 2021 23:14:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id xH6UuuPdSQsi
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Dec 2021 23:14:55 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo74.poczta.onet.pl (smtpo74.poczta.onet.pl [141.105.16.24])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 08AC242970
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 12 Dec 2021 23:14:54 +0000 (UTC)
Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4JC0pY6GvJzlgW5r;
 Mon, 13 Dec 2021 00:14:45 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1639350885; bh=0n0pPoDxtXLmhFIZ+eegn/XHxF7qe7xgOQJmv/liXTI=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=SsCkxhBcywOB+KkbFbCDrr+zCTyIvaLErB78+RNgTHe4lXWBu4waQZ3K8rkP1sHVd
 cfwsaw3A90pD6hTb8x+WE4BvcF4AsM4EmeztgioQ8/Wmd2d7wXgpw+KnKLLl6ey44g
 gd7FFAbBKDu5Q94Q3UU9MtAW3aS1WgnIu40izgJs=
Content-Type: multipart/alternative;
 boundary="===============5173187126171932332=="
MIME-Version: 1.0
Received: from [5.173.254.236] by pmq6v.m5r2.onet via HTTP id ;
 Mon, 13 Dec 2021 00:14:45 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Jeremy <jlrubin@mit.edu>,
 Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAD5xwhgOK6p7fqZPha1jvDgo=4Syti9K46a2A48Eas44dn9v6Q@mail.gmail.com>
Date: Mon, 13 Dec 2021 00:14:45 +0100
Message-Id: <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.254.236;PL;2
X-Mailman-Approved-At: Sun, 12 Dec 2021 23:23:37 +0000
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized
 Coordination Free Mining Pools
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Dec 2021 23:14:57 -0000

This is a multi-part message in MIME format.
--===============5173187126171932332==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> how to select an analyze the choice of window
Currently, we need 100 blocks to spend the coinbase transaction and I think=
 that should be our "window".
> and payout functions
Something like "miner-based difficulty" should do the trick. So, each miner=
 is trying to produce its own block, with its own transactions, and its own=
 coinbase reward (based on those transactions, if we want to think ahead an=
d do it right from the start, we should be ready for situation where the ba=
sic block reward is zero and the whole coinbase is based only on transactio=
n fees). So, each miner can mine a block with its own coinbase amount (base=
d on transaction fees). Then, that miner should multiply the target by the =
number of satoshis collected in the coinbase transaction to get "target per=
 satoshi". Then, by dividing this target by its block hash, it would produc=
e the number of satoshis that miner should receive.
Some example:
difficulty: 170ba21f
target: 0000000000000000000ba21f0000000000000000000000000000000000000000
coinbase: 6.27930034 BTC (627930034 satoshis =3D 0x256d73b2 satoshis)
targetPerSatoshi: 0000000000000000000ba21f000000000000000000000000000000000=
0000000*0x256d73b2
targetPerSatoshi: 000000000001b367c41da68e000000000000000000000000000000000=
0000000
sampleShare: 0000000000000000b613738816247a7f4d357cae555996519cf5b543e9b355=
4b
minerReward: targetPerSatoshi/sampleShare=3D0x2642e (156718 satoshis =3D 0.=
00156718 BTC for this share)
Because we assume that the basic reward will be zero, we assume that all mi=
ners will include their own set of transactions. That means, to check if th=
e miner really should receive that reward, checking all transactions is req=
uired. Assuming that most of the miners will have similar transactions in t=
heir mempools, for each share there is a need to only check transactions th=
at were unknown by that miner. For all other previously validated transacti=
ons, miners can store a table like: "<txid> <fee>" and then quickly validat=
e if the amount specified in the coinbase transaction is correct.
To avoid "share spam", we can use something like "miner-based difficulty" m=
entioned above. Everyone knows the network difficulty, but not all miners a=
re directly connected. So, for each connection with each miner in our decen=
tralized pool, we can define a difficulty for each connection. In this way,=
 each node can specify the absolute minimum difficulty, where paying any re=
ward is above the dust limit, and where including that miner makes sense. T=
hen, each miner can produce shares and adjust miner-based difficulty, just =
to produce for example one share per 10 minutes (or per 30 seconds if we ha=
ve enough resources to fully validate each share from each miner we are con=
nected with in that time).
If we want to include really small miners (like CPU miners), then we need a=
 way to allow sub-satoshi payments. That means, each small miner should min=
e to a single N-of-N taproot-based multisig, where the whole pot is then sp=
litted between N miners in LN. That means, for example one output of 1000 s=
atoshis can be shared between one million small CPU miners. Then, our targe=
t from example above is denominated in millisatoshis.
targetPerSatoshi: 000000000001b367c41da68e000000000000000000000000000000000=
0000000*0x3e8 (1000 in decimal)
targetPerMillisatoshi: 0000000006a4cd5613d29ab00000000000000000000000000000=
000000000000
On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev <bitcoin-dev@lists.linux=
foundation.org> wrote:
Howdy, welcome to day 15!
=C2=A0
Today's post covers a form of a mining pool that can be operated as sort of=
 a map-reduce over blocks without any "infrastructure".
=C2=A0
https://rubin.io/bitcoin/2021/12/12/advent-15/
=C2=A0
There's still some really open-ended questions (perhaps for y'all to consid=
er) around how to select an analyze the choice of window and payout functio=
ns, but something like this could alleviate a lot of the centralization pre=
ssures typically faced by pools.
=C2=A0
Notably, compared to previous attempts, combining the payment pool payout w=
ith this concept means that there is practically very little on-chain overh=
ead from this approach as the chain-load
for including payouts in every block is deferred for future cooperation amo=
ng miners. Although that can be considered cooperation itself, if you think=
 of it like a pipeline, the cooperation happens out of band from mining and=
 block production so it really is coordination free to mine.
=C2=A0
Cheers,
=C2=A0
Jeremy
--
@JeremyRubin
--===============5173187126171932332==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt; how to select an analyze the choice of window<br /><br />Currentl=
y, we need 100 blocks to spend the coinbase transaction and I think that sh=
ould be our "window".<br /><br />&gt; and payout functions<br /><br />Somet=
hing like "miner-based difficulty" should do the trick. So, each miner is t=
rying to produce its own block, with its own transactions, and its own coin=
base reward (based on those transactions, if we want to think ahead and do =
it right from the start, we should be ready for situation where the basic b=
lock reward is zero and the whole coinbase is based only on transaction fee=
s). So, each miner can mine a block with its own coinbase amount (based on =
transaction fees). Then, that miner should multiply the target by the numbe=
r of satoshis collected in the coinbase transaction to get "target per sato=
shi". Then, by dividing this target by its block hash, it would produce the=
 number of satoshis that miner should receive.<br /><br />Some example:<br =
/><br />difficulty: 170ba21f<br />target: 0000000000000000000ba21f000000000=
0000000000000000000000000000000<br />coinbase: 6.27930034 BTC (627930034 sa=
toshis =3D 0x256d73b2 satoshis)<br />targetPerSatoshi: 0000000000000000000b=
a21f0000000000000000000000000000000000000000*0x256d73b2<br />targetPerSatos=
hi: 000000000001b367c41da68e0000000000000000000000000000000000000000<br />s=
ampleShare: 0000000000000000b613738816247a7f4d357cae555996519cf5b543e9b3554=
b<br />minerReward: targetPerSatoshi/sampleShare=3D0x2642e (156718 satoshis=
 =3D 0.00156718 BTC for this share)<br /><br />Because we assume that the b=
asic reward will be zero, we assume that all miners will include their own =
set of transactions. That means, to check if the miner really should receiv=
e that reward, checking all transactions is required. Assuming that most of=
 the miners will have similar transactions in their mempools, for each shar=
e there is a need to only check transactions that were unknown by that mine=
r. For all other previously validated transactions, miners can store a tabl=
e like: "&lt;txid&gt; &lt;fee&gt;" and then quickly validate if the amount =
specified in the coinbase transaction is correct.<br /><br />To avoid "shar=
e spam", we can use something like "miner-based difficulty" mentioned above=
. Everyone knows the network difficulty, but not all miners are directly co=
nnected. So, for each connection with each miner in our decentralized pool,=
 we can define a difficulty for each connection. In this way, each node can=
 specify the absolute minimum difficulty, where paying any reward is above =
the dust limit, and where including that miner makes sense. Then, each mine=
r can produce shares and adjust miner-based difficulty, just to produce for=
 example one share per 10 minutes (or per 30 seconds if we have enough reso=
urces to fully validate each share from each miner we are connected with in=
 that time).<br /><br />If we want to include really small miners (like CPU=
 miners), then we need a way to allow sub-satoshi payments. That means, eac=
h small miner should mine to a single N-of-N taproot-based multisig, where =
the whole pot is then splitted between N miners in LN. That means, for exam=
ple one output of 1000 satoshis can be shared between one million small CPU=
 miners. Then, our target from example above is denominated in millisatoshi=
s.<br /><br />targetPerSatoshi: 000000000001b367c41da68e0000000000000000000=
000000000000000000000*0x3e8 (1000 in decimal)<br />targetPerMillisatoshi: 0=
000000006a4cd5613d29ab00000000000000000000000000000000000000000<br /><br />=
</div>
<div>On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev &lt;bitcoin-dev@lis=
ts.linuxfoundation.org&gt; wrote:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"ltr">
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Howdy, welcome to day 15!</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">&nbsp;</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Today's post covers a form of a mini=
ng pool that can be operated as sort of a map-reduce over blocks without an=
y "infrastructure".</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">&nbsp;</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;"><a href=3D"https://rubin.io/bitcoin/=
2021/12/12/advent-15/" target=3D"_blank" rel=3D"noopener">https://rubin.io/=
bitcoin/2021/12/12/advent-15/</a></div>
<div>&nbsp;</div>
<div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">There's still some really open-ended=
 questions (perhaps for y'all to consider) around how to select an analyze =
the choice of window and payout functions, but something like this could al=
leviate a lot of the centralization pressures typically faced by pools.</di=
v>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">&nbsp;</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Notably, compared to previous attemp=
ts, combining the payment pool payout with this concept means that there is=
 practically very little on-chain overhead from this approach as the chain-=
load</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">for including payouts in every block=
 is deferred for future cooperation among miners. Although that can be cons=
idered cooperation itself, if you think of it like a pipeline, the cooperat=
ion happens out of band from mining and block production so it really is co=
ordination free to mine.</div>
</div>
<div>&nbsp;</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Cheers,</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">&nbsp;</div>
<div class=3D"gmail_default" style=3D"font-family: arial,helvetica,sans-ser=
if; font-size: small; color: #000000;">Jeremy</div>
<br />
<div>
<div class=3D"gmail_signature" dir=3D"ltr">
<div dir=3D"ltr">--<br /><a href=3D"https://twitter.com/JeremyRubin" target=
=3D"_blank" rel=3D"noopener">@JeremyRubin</a></div>
</div>
</div>
</div>
</blockquote>

--===============5173187126171932332==--