Content-Type: multipart/alternative;
 boundary="===============5173187126171932332=="
MIME-Version: 1.0
From: vjudeu@gazeta.pl
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>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized
 Coordination Free Mining Pools
Precedence: list

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==--