A payout scheme for a non custodial mining pool

A payout scheme for a non custodial mining pool
2023-05-22  1:27 ` Antoine Riard
  
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	[|nested]
2023-05-03 15:48 [bitcoin-dev] A payout scheme for a non custodial mining pool F M

  
From: Antoine Riard @ 2023-05-22  1:27 UTC ( / )
  To: F M, Bitcoin Protocol Discussion



Hi Lorban,

The RFC is very clear and consistent on presenting payments pools in
the context of non-custodial mining pools, congrats to the authoring
team.

Few feedbacks, on the technical definition of a payment pool, the
common idea between all payment pools ideas presented so far
(Joinpool, Radixpool, Coinpool) is the pool tree (what you're calling
the payment tree) enabling a compact withdrawal from the pool, with
more or less conservation of the pooling after a withdrawal.

In 2., for the observation of the group of properties, there is one
more which matters a lot if you would like to have off-chain novation
of the pool tree, it's replay security, where a pool participant
cannot replay its withdrawal, partially or in whole, after withdrawing
all its balances.

In 2.1, "as, for an integer n, the n! rapidly grows in size, it
follows that the number of pre-signed transactions that has to be
computed rapidly becomes too large"."This problem seems to not have
been considered in [14]". The factorial complexity of the number of
states (transactions/balances) in function of the number pool
participants is mentioned in a footnote of the paper: "These
restrictions could be also achieved by pre-signing all possible
sequences of state transitions (producing, storing and exchanging all
these signatures), which scales poorly (factorial) with the number of
participants." and in the original mail post about Coinpool:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017964.html
:)

In 2.7, in the rational about using ANYPREVOUT, I think if you're
using the ANYPREVOUT variant, the spent output amount is committed by
the signature digest and I think this is introducing an
interdependency between the validity of the payment tree and the block
template of transactions, as in function of this latter the coinbase
reward fluctuates ? I believe ANYPREVOUTANYSCRIPT is better as there
is no such
commitment to the spent amount/scriptPubkey iirc.

About the attacks, effectively the lack of cooperation of pool
participants to enable cooperative withdrawal is a huge DoS factor, it
can be fought by fees to enter in the pool. Another deterrence is the
timelocking of the balance in case of non-cooperative closure. Past
force-closure of pools can be consumed as a proof of good-conduct by
future co-participants in a payment pool.

Best,
Antoine


Le mer. 3 mai 2023 à 17:05, F M via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> a écrit :

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