From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 07E1EC0012 for ; 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 ; 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 ; 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 ; 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 , Bitcoin development mailing list In-Reply-To: Date: Mon, 13 Dec 2021 00:14:45 +0100 Message-Id: <57315643-a4c33a2ff7196be1070725cf1903435e@pmq6v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: " " 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 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
> how to select an analyze the choice of window

Currentl= y, we need 100 blocks to spend the coinbase transaction and I think that sh= ould be our "window".

> and payout functions

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.

Some example:

difficulty: 170ba21f
target: 0000000000000000000ba21f000000000= 0000000000000000000000000000000
coinbase: 6.27930034 BTC (627930034 sa= toshis =3D 0x256d73b2 satoshis)
targetPerSatoshi: 0000000000000000000b= a21f0000000000000000000000000000000000000000*0x256d73b2
targetPerSatos= hi: 000000000001b367c41da68e0000000000000000000000000000000000000000
s= ampleShare: 0000000000000000b613738816247a7f4d357cae555996519cf5b543e9b3554= b
minerReward: targetPerSatoshi/sampleShare=3D0x2642e (156718 satoshis= =3D 0.00156718 BTC for this share)

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: "<txid> <fee>" and then quickly validate if the amount = specified in the coinbase transaction is correct.

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).

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.

targetPerSatoshi: 000000000001b367c41da68e0000000000000000000= 000000000000000000000*0x3e8 (1000 in decimal)
targetPerMillisatoshi: 0= 000000006a4cd5613d29ab00000000000000000000000000000000000000000

=
On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev <bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
Howdy, welcome to day 15!
 
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".
 
https://rubin.io/= bitcoin/2021/12/12/advent-15/
 
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.
 
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
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.
 
Cheers,
 
Jeremy

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