vjudeu at gazeta.pl [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-12 📝 Original message:> how to select an analyze ...
📅 Original date posted:2021-12-12
📝 Original message:> 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 and do it right from the start, we should be ready for situation where the basic block reward is zero and the whole coinbase is based only on transaction fees). 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 number of satoshis collected in the coinbase transaction to get "target per satoshi". 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: 0000000000000000000ba21f0000000000000000000000000000000000000000
coinbase: 6.27930034 BTC (627930034 satoshis = 0x256d73b2 satoshis)
targetPerSatoshi: 0000000000000000000ba21f0000000000000000000000000000000000000000*0x256d73b2
targetPerSatoshi: 000000000001b367c41da68e0000000000000000000000000000000000000000
sampleShare: 0000000000000000b613738816247a7f4d357cae555996519cf5b543e9b3554b
minerReward: targetPerSatoshi/sampleShare=0x2642e (156718 satoshis = 0.00156718 BTC for this share)
Because we assume that the basic 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 receive that reward, checking all transactions is required. Assuming that most of the miners will have similar transactions in their mempools, for each share there is a need to only check transactions that were unknown by that miner. For all other previously validated transactions, miners can store a table like: "<txid> <fee>" and then quickly validate if the amount specified in the coinbase transaction is correct.
To avoid "share spam", we can use something like "miner-based difficulty" mentioned above. Everyone knows the network difficulty, but not all miners are directly connected. 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 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 have enough resources 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, each 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 example one output of 1000 satoshis can be shared between one million small CPU miners. Then, our target from example above is denominated in millisatoshis.
targetPerSatoshi: 000000000001b367c41da68e0000000000000000000000000000000000000000*0x3e8 (1000 in decimal)
targetPerMillisatoshi: 0000000006a4cd5613d29ab00000000000000000000000000000000000000000
On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Howdy, welcome to day 15!
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".
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 alleviate a lot of the centralization pressures typically faced by pools.
Notably, compared to previous attempts, 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 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.
Cheers,
Jeremy
--
@JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211213/a6680906/attachment.html>;
📝 Original message:> 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 and do it right from the start, we should be ready for situation where the basic block reward is zero and the whole coinbase is based only on transaction fees). 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 number of satoshis collected in the coinbase transaction to get "target per satoshi". 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: 0000000000000000000ba21f0000000000000000000000000000000000000000
coinbase: 6.27930034 BTC (627930034 satoshis = 0x256d73b2 satoshis)
targetPerSatoshi: 0000000000000000000ba21f0000000000000000000000000000000000000000*0x256d73b2
targetPerSatoshi: 000000000001b367c41da68e0000000000000000000000000000000000000000
sampleShare: 0000000000000000b613738816247a7f4d357cae555996519cf5b543e9b3554b
minerReward: targetPerSatoshi/sampleShare=0x2642e (156718 satoshis = 0.00156718 BTC for this share)
Because we assume that the basic 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 receive that reward, checking all transactions is required. Assuming that most of the miners will have similar transactions in their mempools, for each share there is a need to only check transactions that were unknown by that miner. For all other previously validated transactions, miners can store a table like: "<txid> <fee>" and then quickly validate if the amount specified in the coinbase transaction is correct.
To avoid "share spam", we can use something like "miner-based difficulty" mentioned above. Everyone knows the network difficulty, but not all miners are directly connected. 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 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 have enough resources 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, each 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 example one output of 1000 satoshis can be shared between one million small CPU miners. Then, our target from example above is denominated in millisatoshis.
targetPerSatoshi: 000000000001b367c41da68e0000000000000000000000000000000000000000*0x3e8 (1000 in decimal)
targetPerMillisatoshi: 0000000006a4cd5613d29ab00000000000000000000000000000000000000000
On 2021-12-12 17:43:39 user Jeremy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
Howdy, welcome to day 15!
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".
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 alleviate a lot of the centralization pressures typically faced by pools.
Notably, compared to previous attempts, 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 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.
Cheers,
Jeremy
--
@JeremyRubin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211213/a6680906/attachment.html>;