> 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@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
