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