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
>