[bitcoin-dev] A payout scheme for a non custodial mining pool

* [bitcoin-dev] A payout scheme for a non custodial mining pool
@ 2023-05-03 15:48 F M
  2023-05-22  1:27 ` Antoine Riard
  0 siblings, 1 reply; 2+ messages in thread
From: F M @ 2023-05-03 15:48 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 4181 bytes --]

https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_OtMcc/edit?usp=sharing

Dear community,

In the last months there have been several discussions about the topic of
covenants and payment pools

[0]. It has been difficult to approach these topics as it seems that there
is no agreement in a precise

definition on what is a covenant or what is a payment pool. This is
probably due to the great generality

of these two concepts. Perhaps, a good approach to study them is to look at
some different use-cases

and see which are the properties that appear more often and enclose them in
a clear definition. About

payment pools, that may be considered themself as a covenant, we
specialized further, studying a payment

pool’s scheme that may be used for the miners of a mining pool in order to
share the ownership of the

coinbase reward [1]. This would make the pool non-custodial.

The main pools now are custodial, in the sense that they collect the
rewards of mining, and use them

subsequently to pay the miners. As there are few large pools that find
almost all the blocks, custodial

polls increase the level of centralization in a protocol born to be
decentralized and consensus ruled.

This is why we generally want non-custodial pools.

The only non-custodial payment pool that appeared is P2Pool, active some
years ago, that was also decentralized.

In P2Pool, the miners were paid directly by an output of the coinbase
transaction. This implies a very

large coinbase, preventing the inclusion of more transactions in the block,
and therefore collecting

less fees and making the mining less profitable, compared to a custodial
pool. This makes the P2Pool

payout scheme inappropriate considering also that there is big effort in
keeping blockchain light, with

several off-chain protocols.

Our scheme uses ANYPREVOUT signatures and it is based on the idea of
payment trees. A payment tree is

a tree of transactions that redistributes the funds to the payment pool
participants, having their address

to the leaves. The root contains the funds of the payment pool on n-of-n
multisig. We allow payment trees

for future payment pools, in which the input’s references of the
transactions are left empty and the

signatures are ANYPREVOUT.

This makes it possible to safely create a payment pool, merge two payment
pools and withdraw funds from

a payment pool.

Why do we use ANYPREVOUT? Most payment pool structures use precompiled
transactions for allowing safe

withdrawal. The signatures of these transactions clearly commits to the
extranonce of the coinbase. So,

if the payment pool is set for the co-ownership of the mining reward, there
must be a set of precompiled

transactions for every extranonce tried by every miner, that may not be
feasible.

The use of ANYPREVOUT allow the miners to collectively construct a payment
tree that “waits” the rewards,

in the case that some miners finds a block. This payment tree is unique for
all miners.

We assume the pool to be centralized, even though our payment pool scheme
perhaps can be generalized

to decentralized pools. We compared the average space occupied on the
blockchain and compared with the

one of P2Pool. The results seem to be promising in this aspect, and are
even better if the Pool is KYC.

Clearly, this is just a very brief summary of our work, that is enclosed
and labeled as an RFC. So, every

remark or comment may be very appreciated.

Authors:

   -

   Lorban (HRF), https://github.com/lorbax/, lorenzo.bonax@gmail•com
   -

   Fi3, https://github.com/fi3/
   -

   Rachel Rybarczyk (Galaxy Digital), https://github.com/rrybarczyk

PS
Please note that although the linked document bears some resemblance to a
research paper, it is presented as an RFC. We chose to publish it as an RFC
because it is not intended to be a comprehensive work.

[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-July/020763.html

[1]
https://docs.google.com/document/d/1qiOOSOT7epX658_nhjz-jj0DlnSRvytemOv_u_OtMcc/edit?usp=sharing

[-- Attachment #2: Type: text/html, Size: 22840 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread