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:

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