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