RFC

Payment pools and co-ownership of coinbase reward

Name: Lorban

Institution: HRF

GitHub: https://github.com/lorbax/

Name: Fi3

Institution: DHN

GitHub: https://github.com/fi3/

Rachel Rybarczyk

Institution: Galaxy Digital

https://github.com/rrybarczyk

Abstract. In this RFC we present a possible solution for the payout scheme of a non-custodial pool, in which the pool’s miners are the participants of the payment pool associated with the mining pool. Our scheme does not rely on off-chain technology and assumes BIP0118.

1. Introduction        2

2. Payment pool structure        3

2.1 Naive payment pools        4

2.2 The proposed scheme        5

2.3 Merging two payment pools        7

2.4 Sending funds to a payment pool        9

2.5 Withdrawal of funds from a payment pool        9

2.6 Payment pool with large number of participants        11

2.7 Why ANYPREVOUT        12

2.8 Non-collaborative participants and DOS attacks        13

2.9 Remarks        14

3. Payment pools for mining pools        14

3.1 Implementation for miners        15

3.2 Operations on a payment pool for a mining pools        17

3.3 Withdrawal from a payment pool        18

3.4 Average weight on the blockchain        20

3.5 Collaboration between participants of a payment  pool in a mining pool        22

3.6 Possible attacks to a payment pool        22

3.7 Fees        23

4. Technical considerations about payment pools for mining pools        23

4.1 Wait 100 confirmations        23

4.2 Aggregating pubkeys        23

4.3 Qualitative anatomy of transactions that use ANYPREVOUT        24

5. Payment pools using CTV and TLUV        25

5.1 CTV payment pools        25

5.2 TLUV payment pools        25

5.3 Payment pools for mining pools using ANYPREVOUT  and TLUV        26

6. Conclusions        27

  1.  Introduction

In pooled mining, there is a pool server that sits between the mining devices and the Bitcoin network. The pool server has two main responsibilities.

The first is handling all the communications that would otherwise be done between a mining device and the network: it provides miners with the information needed to commence mining on a candidate block, and it receives a miner’s submitted solution for validation and network confirmation. The means of communication between pool and miner is specified by a mining protocol. The mining protocol ensures that the miner is provided with enough information to build a candidate Bitcoin block header and perform the necessary hashing to yield a resulting solution: a block header whose hash is below the network target.

The second main responsibility of the pool is the handling of the miner’s reward payouts, something that is historically not specified in the mining protocol but is instead left up to the pool to decide. In pooled mining, the means in which a miner receives their reward varies greatly from the payment received directly from the network in solo mining. During the construction of the block template, the pool formats the coinbase transaction such that the block reward is paid to the pool’s Bitcoin address. Such a centralization of funds exposes mining a critical risk. Because the payout mechanism is left to the centralised, 3rd-party pool service, miners are forced to fully trust that the pool is paying them a fair payout and cannot verify that the pool is not withholding a portion of their rewards from them, an act called pool skimming. In fact, there have been some occurrences of pool skimming occurring throughout the years, but in general this is a phenomenon that is difficult to detect. The only recourse a miner has is to switch to a different pool, but this offers little solace as there are only a handful of pools to join that are large enough to offer consistent rewards. One possible solution for this problem is to add a payout scheme in which the coinbase reward is collected directly by the miners, in such a way that the pool has never the control of miners’ funds. A pool with this property is called non-custodial. The main non-custodial pool that appeared in Bitcoin history was P2Pool. The payout scheme of P2Pool was simple, but inefficient. Indeed, each miner was paid with funds locked to his address directly in the coinbase transaction outputs. This resulted in a large coinbase. As in future the miners’ payout will rely more on fees than freshly generated BTC, this is not a forward-looking solution.

In this RFC we present a payout scheme for a non-custodial pool that should be better than the P2Pool scheme. The benefits are more consistent with a centralised KYC pool, even though this payout system seems to be always convenient, provided that the pool is large enough. Our scheme is introduced through the concept of a payment pool, where the participants are the miners of the mining pool. The presented payment pool scheme uses ANYPREVOUT, does not rely on any off-chain technology and it is trustless, in the sense that a participant does not have to trust in collaboration of all other participants: a non-collaborating participant is automatically ejected from the payment pool and it is not a threat for accessibility of funds. Our study assumes the pool to be centralised, but it can be generalised to decentralised pools. Our payment pool scheme is meant to be a future extension of Stratum V2 mining protocol.

Summary of chapters. In Section 2.1 the desired properties that a generic payment pool should have is introduced. In Section 2.2 three possible solutions for a payment pool are analysed. The first two are easy to implement but are expensive in terms of fees or computational resources. The third is the actual proposal. The rest of the chapter is devoted to the development of the proposed scheme of payment pool that is introduced in Section 2.2, from a theoretical point of view. Guidelines for several pool procedures are given, including  the merging of two payment pools (Section 2.3), the withdrawal of funds from a payment pool (Section 2.4), the sending funds to a payment pool (Section 2.5), and the ejection of non-collaborative participants, fees and attacks (Section 2.8). All the payment pools have 8 participants. Larger payment pools are treated in Section 2.6. In Section 2.7 we discuss why and where ANYPREVOUT [1] is needed in our scheme.

In Section 3 the proposed scheme of Chapter 2 is implemented for the case where the participants of the payment pools are miners of a mining pool that share the rewards of successfully mined blocks. In Chapter 3.4 we show that our scheme is very convenient (in terms of space occupied in the blockchain) for KYC pools and is still better than P2Pool when the number of participants is large. In the following sections of the chapter we discuss about the collaboration seeded to make our scheme work, possible attacks and a fee system to prevent some of them.

In Section 4 we analyse some technical issues encountered during the design of the scheme, how to deal with the fact that the coinbase reward remains frozen for 100 blocks (Section 4.1), how to create co-own addresses using MuSig2 (Section 4.2), and a qualitative description of transactions that use ANYPREVOUT (Section 4.3).

In Section 5 payment pools based on CTV (Section 5.1), TLUV (Section 5.2) and TLUV & ANYPREVOUT (Section 5.3) are all analysed.

A conclusion is presented in Section 6.

  1.  Payment pool structure                                            

According to [2], a payment pool is a multi-party construction enabling multiple participants to share the ownership of a single on-chain UTXO among many off-chain/promised balances. Though intuitive, this definition is not technical and it is prone to interpretation.

Definition 2.1.1 Let  be a positive integer. A payment pool as a set of participant addresses  such that all the participant co-own (in -of- multisig) a single Bitcoin address, to which are allocated some (>0)  funds.

Unfortunately, when we talk about payment pools, it seems that everyone agrees that a payment pool is a structure that should be richer than the above, even though it seems difficult to define which are the good-to-have properties for a payment pool. In this context, our aim is not to define which is the best notion of payment pool in general, but rather a group of properties that a payment pool should have in order to be adopted by the miners of a mining pool.

  1. Fund security: A participant MUST NOT be required to be online to ensure that their funds are not lost or stolen.
  2. Co-ownership: The funds of the payment pool MUST be collectively co-owned by all its participants.
  3. Access to Funds: Each participant can unilaterally withdraw his funds at any time.
  4. Cumulative: Multiple payment pools MUST be able to merge into a single payment pool. 

                                   

This whole work is an attempt to provide a payment pool structure such that these properties are clearly satisfied from a kind-of technical point of view.                 

We give some notations that will be used in all the following. If  is the set of addresses of payment pool’s participants, we denote  with  the associated Bitcoin address in -of- multisig. We use this notation because the associated Bitcoin address is derived from the aggregated Schnorr pubkeys of all the participants, as we will see in Section 4.2. In order to keep the exposition endurable, we avoid unnecessary generalisations. For example, we assume that   and , so  is the co-own address. This is no loss of generality, as the procedures that we will describe also work with larger payment pools, as we will see in Section 2.6.

        2.1 Naive payment pools

In this section we describe two possible “naive” ways to construct a payment pool. Though being easy to deploy and understand, these two schemes are not feasible. Assume the notations of the section above.

Figure 2.2.1.

First naive scheme.

The first scheme that we report here is actually quite important, as it is basically the payout scheme of P2Pool, the main decentralised mining pool in Bitcoin history. This is also the payout scheme of Laurentia pool, see [15]. For simplicity, as we are talking about general payment pools, we do not refer to any specific aspect of P2Pool. The idea of this scheme is the following. Suppose that some funds are locked to . To guarantee everyone funds’ access, there is a transaction  that redistributes funds to every participant. The input of this transaction is the funds locked to , and there is exactly one output for every participant. See Figure 2.2.1.

As long as no one withdraws, the funds stay locked to . Consider the scenario in which a participant, , desires to withdraw their funds from the payment pool. Then  publishes the transaction  and get his funds. In this way, all other participants are forced to withdraw.                                    

This is unsuitable, as in general we want that only funds claimed by the owners leave the pool. Moreover, the transaction  would have an output for every participant of the pool, making it very heavy in terms of vB, and would eventually occupy a large amount of blockchain space. This makes this scheme impractical and also very expensive if the pool is large. This is enough to discard this scheme for general purpose.

Figure 2.2.2.

Second naive scheme.

Assume the same notation as above. In the first naive example, the one-exit-all-exit scheme is very inconvenient. A possible solution to this, described in Figure 2.2.2, is to set that  withdraws its funds and the remaining funds go to a second payment pool set by the participants that have addresses . Clearly, to avoid that  withdraws all the funds, this transaction must be pre-signed by all the addresses of  in the moment of setting up the payment pool. So, there must be such a pre-signed transaction for each participant.

Thus, the number  of presigned transactions is equal to

,

Where  is the number of presigned transactions needed in the second payment pool that consists of all addresses of , except the first that withdrew its funds. So, it is easy to see that

As, for an integer , the  rapidly grows in size, it follows that the number of presigned transactions that has to be computed rapidly becomes too large.
This problem seems to not have been considered in [14], as the change that goes back to the pool must be an output in the Withdraw transaction defined in 5.1 of the whitepaper. It is not explained why the already existing withdrawal transactions should be valid also for spending this second change output.

2.2 The proposed scheme

In this section we describe a possible solution for a payment pool which is more flexible and avoids the issues of the naive implementations above.

As before, we assume that the payment pool has  participants and  is the set of their address. We stress that this is no loss of generality and the topology of a payment pool with more participants is described in Section 2.6. Set the following addresses:

  •  co-owned by all participants,
  •  co-owned by  and ,
  •  co-owned by  and .
  •  co-owned respectively by  and and and so on.

The co-own funds are locked to the address . Moreover, there are the following poresigned transactions.

  •  is the transaction that spends funds locked to  and has two outputs to the addresses . 
  •  is the transaction that spends funds locked to  and has two outputs to the addresses .
  •  is the transaction that spends funds locked to  and has two outputs to the addresses .
  •  is the transaction that spends funds locked to  and has two outputs to the addresses .
  •  is the transaction that spends funds locked to  and has two outputs to the addresses .
  •  is the transaction that spends funds locked to  and has two outputs to the addresses .
  •  is the transaction that spends funds locked to  and has two outputs to the addresses .

Figure 2.2.3. Payment pool with payment tree

The idea is the following: the funds are locked in 8-of-8 multisig

Definition 2.2.4 

  1. A set of transactions as in Figure 2.2.3 is called payment tree. We allow payment trees in which the inputs’ references of the transactions are left empty and that signatures are ANYPREVOUT.
  2. From now on, we assume that a payment pool is a structure as in Definition 2.1.1 which has a payment tree.


It is very important to keep in mind the difference between a payment tree and a payment pool. A payment tree is just a set of transactions, which may be incomplete and may have no funds allocated. On the other hand, as soon as some funds are allocated to the root address, all the transactions’ inputs can be filled and the payment tree becomes a payment pool. This will be discussed often throughout the following. We remark that if the number of participants is not 8, the payment tree (and therefore the payment pool) are constructed according to Section 2.6.

If some transactions of the payment pool are published, the payment pool splits and the remaining payment pools are called sub payment pools. For example, suppose that the transaction  is published. Then the funds locked to  are divided into the balance of  and the balance of . Therefore, the following are sub payment pools.

  • , , ,  with the transactions ,  and .
  • , ,  with the transactions ,  and .

The details of this scheme may differ from the desired implementation, so they will be discussed in Chapter 3. It is immediately seen that there are a total of seven transactions, which are global in the sense that they are enough to guarantee to every participant the withdrawal of their funds. In other words, the payment tree gives everyone access to their funds.

The following sections analyse the properties and the operations that can be performed with this scheme, like withdrawal of funds (Section 2.4), merging of payment pool (Section 2.3), sending funds to a payment pool (Section 2.5) and unilateral ejection of non-collaborative participants (Section 2.8). In Section 2.8 we discuss why we need ANYPREVOUT.

2.3 Merging two payment pools

Suppose that there are two payment pools. The first manages a UTXO  that is co-own by participants having addresses . The output   is locked to the address . The second payment pool is set by participants having addresses  and manages a UTXO , co-own by this second set of participants.

Figure 2.3.1

Suppose that we want to merge these two payment pools in a third payment pool, set by the participants having addresses from  to . We proceeds with the following steps.

  1. All the participants set up a payment tree where the inputs’ references are left empty and the signatures use ANYPREVOUT (see Section 2.7). The address in the root of the payment tree is . In the Figure 2.3.2 below, the payment tree is constructed according to Section 2.6.

Figure 2.3.2

  1. The participants construct and publish a merging transaction, a transaction that merges and  in  , locking it to .

  1. Now the root address has some funds (namely  locked to and the inputs can be added to all the transactions of the payment tree. So, this payment tree becomes a payment pool, called the merging of the former payment pools.

Note that without any modification we can generalise the merging for more than two payment pools. As a single address with some funds locked to can is considered a payment pool, the merging of payment pools may be used to let a new participant join an already existing payment pool. A transaction as in Figure 2.3.1, is called a merging transaction or the transaction that merges the payment pools. The Figure 2.2.3 below gives an overview of the whole procedure of the merging of two payment pools.

Figure 2.3.3

2.4 Sending funds to a payment pool

Payment pools will be used in the context of the co-ownership of the coinbase rewards by the miners of a mining pool. In this spirit, this section addresses how to apply the payment pool scheme introduced in Section 2.1 to manage the situation where there are funds that are sent to the participants to a payment pool by a third party, with address .

Figure 2.4.1

In this case, the payment pool in Figure 2.4.1 is the already existing payment pool that manages an output  A new payment tree is created (with ANYPREVOUT, this will be discussed in Section 2.7), with the same participants, see Figure 2.4.2. Similarly to the merging of payment pools, the inputs of the transactions of this payment tree are left empty. Then,  sends the funds to the root address of this payment tree with a funding transaction, whose output is denoted . Thus, the inputs can be added to the transactions of the payment tree, which becomes the payment pool that manages .

Figure 2.4.2

Now, these two payment pools are merged to a single payment pool, where the balance of every participant is upgraded.

2.5 Withdrawal of funds from a payment pool

We consider two forms of funds’ withdrawal. The unilateral withdrawal is performed by a participant that unilaterally decides to withdraw his funds regardless of the other participants. The coordinated withdrawal is performed during the merging of two payment pools.

Unilateral withdrawal. Consider the payment pool in Figure 2.2.3. Suppose that  decides to withdraw the funds. As the transactions of the payment tree are presigned, it is enough that  publishes the transactions ,  and .

So, transaction  spends funds locked to , splitting them in two outputs, locked  and . Likewise, transaction  spends funds locked to  and has two outputs locked to addresses  and . Eventually,  gets the control of his funds through publishing the transaction

Figure 2.5.1

Now, we can see that there are funds that are locked to some vertices of the payment tree. The nodes, that in this case are the addresses ,  and , have the control of the remaining funds. In particular:

  •  owns a single UTXO of  
  • owns a single UTXO of , and
  •  owns a single UTXO of .

Moreover, the addresses and the transactions and form a sub payment pool. The same is true for  and the transaction  and  with the empty trasaction. Figure 2.5.2 shows the sub-payment pools after that  performs a unilateral withdrawal.

Figure 2.5.2

Now it is expected the participants with addresses addresses , that are exactly the addresses involved in the subpayment pools, want to rejoin a single payment pool. To do so, they collectively sign a transaction that spends the funds in the roots of the remaining subpayment pools and has one output, locked to the address , through the process of merging the payment pools described in Section 2.3.

This type of withdrawal is called unilateral because  gets the control of his funds regardless of the other participants, which are left to the duty of rejoining another payment pool. We remark that the payment tree serves as insurance that everyone has access to their funds, also in the case that the payment pool is compromised.

Coordinated withdrawal. Suppose that the participants having addresses have two payment pools that manage two co-own UTXO, that we denote with  and .

Figure 2.5.3

Assume that the participants want to merge these two payment pools in a single payment pool and that there is a participant, say with address H, that wants to withdraw his funds. This participant may take advantage of the situation, by withdrawing his funds during the merging of the two payment pools. Indeed, we can construct a modified version of the merging transaction,  where

  •  and  are the inputs
  • There is an output  locked to , that corresponds to ’s funds and an output  locked to the root of the newly constructed payment tree.

This type of withdrawal requires cooperation between the participants.

Figure 2.5.4

 

Comparison between these two types of withdrawals. If the payment pool between participants will not be updated in any way (through merging with a second payment pool, for example), unilateral withdrawal is the only way for a participant to get his funds. However, in situations where a funding transaction appears periodically, like the reward of a mined block, coordinated withdrawal is more convenient because it occupies less space on the blockchain.

2.6 Payment pool with large number of participants

We have considered payment pools with eight participants. If the number of participants is  with  positive integer, then a payment pools can be defined in the same way, using a binary tree as Figure 2.2.3, but with height  in place of .

Figure 2.6.1.

Note that in this case, every participant that wants to withdraw the funds must publish  transactions and pay all of the associated fees. If the number of participants is , that is not a power of , (as seen in Figure 2.6.1) we proceed in the following way.

Suppose that  are the addresses of the participants. Then, we produce addresses , where

  , ,

(with  is an address co-owned by  and ) if  is even and

,

If  is odd.  Therefore, we produce  with the same procedure,  and so on. For the first  such that  (that exists as the sizes of the ’s is strictly decreasing) we have an address co-owned by every participant of the pool. We remark that we tacitly assumed that, for example, the address  is co-owned by the participants that have addresses .

Proposition 2.6.2. Suppose that a payment pool has  participants. To perform an unilateral withdrawal or ejecting a non-collaborating participant (see Section 2.8), at most  need to be published.

Proof. We prove it for ejection of participants. For unilateral withdrawal the proof is the same. This can be done via publishing some transactions of the payment tree, following the scheme in Section 2.5. In particular, if  is a participant different from  such that, in the payment tree,

,

where  is the height of a node in the payment tree, seen as an oriented finite tree with root and a set with partial ordering (so the sup is the supremum), if  withdraws his funds then  is forced to withdraw his funds. The number of transactions to be published is exactly the height of the payment tree, that has eight  except when .

2.7 Why ANYPREVOUT

Imagine that there are some participants with addresses  and assume that they want to receive some funds in a co-own address. So, the set up  in -of- multisig. Once that the funds arrived on , it is immediately seen that if some of the participants vanishes, the funds are lost for everyone. One possible way to do that is to set a lower threshold, like -of- multisig. But this seems to be inappropriate, as the participants, in this context, are the miners of a mining pool. So, every participant’s balance is a piece of the output locked to , and the  miners with less funds may steal the funds of the  participants with more funds. One possible way to solve this problem, is to set a payment tree that manages the funds locked to  before, in such a way that


when funds arrive at the co-own address, a payment tree that manages these funds is already deployed.

One way to do that is to use ANYPREVOUT. Indeed, consider the transaction  in the payment tree as in Figure 2.2.3. As this transaction, that spends funds locked to , has to be compiled before the transaction that actually locks the funds to , the input reference of   is left empty and the signature in the witness of  does not cover the input, i.e. is ANYPREVOUT. Therefore, the id of  is not determined and the same happens to transactions  and . This means that all the transactions in the payment tree have the inputs missing and signatures ANYPREVOUT. Clearly, once that the funds are locked to  through a transaction , then all the transactions in the payment tree can be filled and become valid. So, this payment tree becomes a payment pool.
The exact same problem also appears if the participants are the miners of a mining pool. During the mining of a block, the miners agreed on the reward and compiled a payment tree. So, using any type of valid transaction format, the first transaction of the temporary payment tree depends on the id of the coinbase transaction. The id of the coinbase is the hash committed to the serialised transaction, that therefore commits also to the extranonce. So, for every extranonce used by any miner, there should be a different payment tree. As there are many extranonces per second tried by a single miner, the number of payment trees to be computed becomes too large. This is why the temporary payment tree in Section 3.1 consists of transactions as above, where the inputs references are empty and the signatures are ANYPREVOUT.


In this section, we describe how this problem arises every time some co-own funds are moved. Suppose that the participants want to merge the two payment pools in Figure 2.3.1. The outputs  are safe as there is a payment tree that manages each. These optus has to be merged to , locked to . If all the participants compile a transaction for this purpose, and then a participant go offline,  would be unspendable. Therefore a payment tree with incomplete transactions and ANYPREVOUT signature as in Figure 2.3.2 has to be constructed before the transaction that moves  into .
Suppose now that some participant wants to perform a coordinated withdrawal (see Section 2.5). Then, looking at Figure 2.5.3, all the participants must firstly collaborate to create a payment tree (where the transactions have input empty and ANYPREVOUT signatures) that manages  and only after this they can compile the merging transaction with withdrawal.

2.8 Non-collaborative participants and DOS attacks

Non-collaborative participants: Our proposal benefits from collaboration between the participants of the payment pool in the case that the coordinated withdrawal is possible (for example, when the participants are the miners of a mining pool). Nevertheless, collaboration has an impact only in the efficiency of the implementation of a payment pool and it is not strictly required for the security of the payment pool. If there is one honest participant, with address  that it is non-collaborative (because, for any reason, went offline), then there are two possible scenarios. Either there is another participant, with address , such that  is a node of the binary tree associated to the payment pool, or there are two other participants, with addresses  and  such that  is the parent node of  and  and  is the parent node of  and . In both cases, a way to overcome the inactivity of the offline participant is that the participant with address  withdraws their funds. In this way, the offline participant is forced to withdraw his funds. The other participants can later merge the remaining sub payment pools in a new payment pool, without . In this case, the fees of the transactions needed are not paid by , that is offline, but are instead shared by the remaining participants of the pool. This ensures the payment pool conforms to the Fund Security Property (Section 2.1, Property 3) allowing for participants to have access to their funds without requiring every participant to be online.

Dishonest participants and DOS attacks: Now suppose that a participant with address  goes offline with a malicious intent. In this case, following the procedure above, the remaining participants have to expel  from the payment poo and they have to pay the fees of  transactions, by Proposition 2.6.2 (recall also the merging transaction). If the malicious participant rejoins the pool and then goes offline again many times, this is considered as a DOS attack. To deter this behaviour, every participant must pay an entrance fee to join a payment pool. The fee is a small amount of burned funds. It is possible to limit the number of times a participant can go offline and rejoin. After reaching this limit, they must pay a second entrance fee by again burning their funds, making a DOS attack expensive. Note that this problem appears only in the case where the pool is not KYC (know your customer).

2.9 Remarks

In this section we analyse how the payment pool properties at the beginning of Chapter 2 are fulfilled by our scheme. First of all, it is secure because it can’t happen that some funds remain unspendable for a non-collaborating participant. Respects the idea of co-ownership by construction. Every participant has access to his funds at any moment though a unilateral withdrawal, even though unilateral withdrawals are discouraged. Finally, it is cumulative (see Sections 2.3 and 2.4). Is worth mentioning that many features of our payment pool scheme in this chapter and its implementation in the next chapter overlaps with the ideas in [14].

  1.  Payment pools for mining pools

In this chapter, we adapt the scheme in Chapter 2 to implement a payment pool in mining pools. So, the payment pool’s participants are the miners and every time that some participant mines a block, the coinbase reward goes to the payment pool in such a way that every participant is paid in proportion to the hash power he has contributed. Though this chapter works with the current mining software Stratum, we remark that our scheme is designed to be deployed in  Stratum V2. We assume that the pool is centralised and we remark that what follows can be generalised for decentralised mining pools.

All the transactions are full taproot, in the sense that the inputs and the outputs are P2TR (see taproot soft-fork BIPs 340, 341 and 342, see [5]). This has several benefits. First of all, it is possible to use Schnorr signatures SDSS, a particular type of signatures that allow key aggregation and batch verification of the signature, through the new multisignature protocol MuSig. This protocol has three rounds of communications and can be reduced to two using a variation of the scheme, known as MuSig2 (see [6] and [7]). This will be discussed in Section 4.2.

In the following, we assume that the proportion of hashpower contribution, and consequently the coinbase repartition among miners, remains constant from block to block. This is not true in practice, even though our scheme can be adapted to situations in which the hashpower contributions are not constant. Agreement of coinbase redistribution is a whole problem on its own and detailed implementation that takes into account this aspect is out of the scope of this work.

3.1 Implementation for miners

In the following, we assume that the BIP 118 is active and that miners are mining the block number . As before, suppose that the participants have addresses A,B,C,D,E,F,G,H that store the following balances in a payment pool.

  • A: 5 BTC
  • B: 5 BTC
  • C: 10 BTC
  • D: 10 BTC
  • E: 15 BTC
  • F: 15 BTC
  • G: 20 BTC
  • H: 20 BTC

These funds, that sum up to 100BTC, appear on chain as an unspent output  locked to the address . We implement the payment tree in Section 2.2. So, there are 7 precompiled transactions. This payment pool is called the n-th payment pool and changes only if a pool’s miner finds a new block.

Figure 3.1.1.

The participants are contributing to the pool’s hashpower. The contribution is calculated by the shares that the miners provided to the pool. So, we assume that the coinbase reward (fees included)  is 10BTC and it is partitioned as follows.

  • A: 2 BTC
  • B: 0.5 BTC
  • C: 0.5 BTC
  • D: 1.5 BTC
  • E: 1 BTC
  • F: 1.5 BTC
  • G: 1 BTC
  • H: 2 BTC

The temporary payment tree is a tree that, in the case that some pool’s miner finds a block, redistributes the coinbase output among participants likewise the payment tree of a payment pool. Nevertheless, the temporary payment tree is not a payment pool, because it does not have any funds allocated to the root as long as any miner of the pool finds a block. In this tree, all the transactions have the input empty and the witness signatures do not cover the inputs, namely they are ANYPREVOUT. The temporary payment tree is calculated by the pool once and then stored, as the hashrate of each participant is assumed to be constant.

Figure 3.1.2.

Now, when the block  is mined, the miners start immediately to mine the -th block with the temporary payment tree. Nevertheless, the -th payment pool changes depending on one the two following cases.

  1. the block is mined outside the pool
  2. the block is mined by some pool’s miner

Suppose that the -th block is mined outside the pool.

Figure 3.1.3.

Since no funds have arrived, the -th payment pool is equal to the -th one. See Figure 3.1.3.

Suppose now that some pool’s miner successfully mines the -th block. The coinbase transaction is a funding transaction in the sense of Section 2.4 and we can apply the procedure “Sending funds to a payment pool”. In particular, both the temporary payment tree and the -th payment pool are both payment pools (since have some funds locked to the root address). Now we only need to merge these two payment pools, according to Sections 3.2 and 2.3. We call  the merging transaction. The resulting payment pool is the -th payment.

Figure 3.1.4

We point out that, for safety reasons, the payment tree that manages the output of  should be constructed before that  is constructed, using ANYPREVOUT and omitting the input’s reference. See Section 2.7.

3.2 Operations on a payment pool for a mining pools

Merging of payment pools. Note that among miners of a mining pool there may be more than one payment pool. For example:

  1. the pool finds a new block, then the temporary payment pool and the payment pool need to be merged
  2. if a participant performs a unilateral withdrawal or he is expelled by the payment pool (these operations are described below), there are  remaining payment pools that need to be merged.

Suppose we are in the second case. Conceptually, both situations can be viewed as an unilateral withdrawal (the procedure is the same: some transactions are published in order to let a participant withdraw). So, the payment pools that have to be merged are the sub-payment pools and we follow the procedure described in Section 2.5, paragraph “Unilateral withdrawal”.

Figure 3.2.1.

Suppose we are in the first case. So, there are exactly two payment pools with funds (the temporary payment tree, that manages the output  of the coinbase transaction and the the -th payment pool, that manages the output ). Then, it is possible to merge these payment pools, using a merging transaction . As  and  are P2TR outputs, the transaction  (see Figure 3.2.1 and Section 2.3 for the definition of merging transaction) spends  and  via the key-path. This requires collaboration of all participants. If a participant is not collaborating (for example, for the signatures required in the transaction ), he can be expelled by both the payment pools and the other participants can rejoin to a payment pool (see the next paragraph). Suppose that  is the output of the merging transaction; we recall that, for safety reasons, a payment tree that manages  should be constructed, using ANYPREVOUT, before the transaction  is compiled.

Expelling a non-collaborating participant. If a participant  is not collaborating at some time, then he can be unilaterally ejected from the payment pool by the other participants. After ejection, there are  remaining sub-payment pools. The participants of these payment pools can rejoin to a single payment pool, merging the sub-payment pools. We remark that the costs of the whole procedure (in terms of transactions’ fees) can be shared by the participants.

Large payment pools. If the number of participants is greater than 8, the payment trees can be implemented using the construction in Section 2.6.

3.3 Withdrawal from a payment pool

In Section 2.5 we saw two types of withdrawals, the coordinated and the unilateral ones. Though the unilateral withdrawal always results in a direct access to funds, the other participants are left with the task of grouping all the remaining subpayment pools in a single payment pool, which need a merging transaction with many  inputs, where  is the number of miners). Assuming that every participant withdraws funds regularly, choosing the unilateral withdrawal as standard would lead to a large average occupied space on the blockchain (see Section 3.4). The same is true if a participant makes many withdrawals of a small amount of funds. Therefore, we set the following constraints.

  1. Coordinated withdrawal is the standard type of withdrawal and unilateral withdrawal is considered an attack to the payment pool (see Section 3.6).
  2. Every participant should withdraw all his funds at every withdrawal.

Suppose that at the block  the -th payment pool has to be merged with the temporary payment tree with some locked funds. Call  and  respectively the co-owned UTXO of these two payment pools and in Figure 3.3.1.

Figure 3.3.1.

Suppose that some participants, say  and  want to withdraw their funds. Their withdrawal is done during the merging transaction. The inputs of this transaction are  and  and the outputs are  where are the funds that remain in the payment pool and  and  are respectively the funds of  and. Recall that, before this transaction is compiled, the participants that co-own  have to construct the payment tree for .

Figure 3.3.2.

 

Figure 3.3.3

In conclusion of this section, we remark that the payment tree serves as insurance that every part has direct access to their funds, in the case that the entire payment pool is compromised.

3.4 Average weight on the blockchain

In P2Pool, the miners’ payout with P2Pool is the scheme in Figure 2.2.1, where every miner is paid directly through output locked to his address in the coinbase transaction. So, the coinbase transaction has as many outputs as the number of pool’s miners. As P2Pool is the only non-custodial large pool appeared, we make a comparison between our pool and P2Pool payout scheme in terms of average space occupied on the blockchain, which is the average number of vB per block that the pool occupies for miners’ payout. We introduce some constants.

  • : on average, the pool has  participants.
  • : on average, the pools finds a block every  blocks.
  • : on average, for every block there are  participants that want to withdraw.
  • : on average, every block there are  participants that go offline.
  • : is the weight in vB of a P2TR transaction input
  • : is the weight in vB of a P2TR transaction output

Now we calculate the average space per block on the blockchain of the P2Pool. For the architecture of the pool, a miner is considered offline if it remains unresponsive for  block in row. If the pool finds a block, the miners are paid directly with coinbase outputs. So, the coinbase size is approximately  and the average space occupied on the blockchain is

.

The average space per block occupied on the blockchain by our scheme is a bit more difficult to calculate. First of all, the space occupied varies depending on the fact that the pool is or is not KYC. This leads to two calculations. Note furthermore that withdrawal is supposed to be only of coordinated type. Moreover, unresponsive participants are expelled by the payment pool, nevertheless the number of participants of the payment pool are supposed to be constant. We remark that adding a participant to the pool has no impact on the blockchain, unless he withdraws his funds (in coordinated or unilateral way) or becomes unresponsive.

Average weight of merging and withdrawal. As the withdrawal is performed during the merging of the payment pool and temporary payment tree, we calculate the weight of both procedures at the same time. This boils down to the calculation of the size of the modified version of the merging transaction in Figure 3.3.2.

This transaction has two inputs. The root of the new payment pool is an output of this transaction. On average, every  blocks there are  participants that want to withdraw. Therefore, this transaction has size . Therefore, the average weight per block is

Average weight of expelling a non collaborating participant. In Section 3.2 we saw that for expelling a non-collaborating participants, we have to publish  transactions of the payment tree. Each of these transactions has one input and two outputs. Then, we need a transaction to merge the remaining  sub-payment pools. This transaction has  inputs and one output. Therefore, if, on average, there are  participants per block that go offline (and need to be expelled by the pool), the average weight of expelling is

.

This is the most expensive operation, that would potentially disrupt the payment pool structure, so it is important to minimise it. One easy way to do this, is to set the pool KYC, that would make this cost zero.

Average weight of the coinbase. This transaction has one input and one output, so, according to [10], the coinbase is a fixed weight of 111vB. Since there is on average one coinbase every  blocks, the average weight of the coinbase is .

non-KYC pool. If the pool is non KYC, the total average weight is:

Therefore, our pool’s payout scheme is better than the one of P2Pool if

.

Let’s rewrite the disequation, where :

.

This is equivalent to the following

.

With easy asymptotic analysis, we can see that there is a  large such that, for all , the disequation above is satisfied.

KYC pool. In the case of KYC pool, the total average weight is

.

In this case, the our pool’s payout scheme is better than the one of P2Pool if

.

The  such that the disequation is satisfied for all  is much smaller than the  in the non-KYC pools.

In the following analysis, we present numerical data using four hypothetical mining pools. Our assumptions include a value of k equal to 0.005, which means that every miner wants to withdraw their earnings after every 200 blocks (33 hours). The data presented here should be considered preliminary and incomplete, as it serves only to provide a rough estimate. The values of z are only relevant in cases where the pool is non-KYC; if the pool is KYC-compliant, z is always equal to zero.

  1. The first pool we examined had a value of z equal to 0.01, indicating that on average, one miner goes offline every 100 blocks. The pool had 1000 participants (n=1000) with a high hashrate (br=10), which resulted in a block being found every 10 blocks.
  2. The second pool had a value of z equal to 1, meaning that on average, one miner goes offline per block. The pool had 10000 participants (n=10000) and a lower hashrate (br=100), which resulted in a block being found every 100 blocks.
  3. The third pool had a value of z equal to 0.01, with 1000 participants (n=1000) and a hashrate of 10 (br=10).
  4. The fourth pool is equal to the third, but with a value of z equal to 1.

The first pool has few participants who are large and reliable miners. The second pool has a low hashrate and many small and unreliable miners. The third pool is large, with many reliable miners, and the fourth is similar to the third, but with unreliable miners. Our findings indicate that the first pool can be divided into three cases based on the payout scheme: P2Pool, the proposed payout scheme, and the case where z=0 (i.e., the pool is KYC-compliant). Below we include the results for three kind of payment schemes: P2Pool scheme, our scheme with z=0 (KYC), and our scheme with z not equal to 0 (not KYC).

Pool 1

Pool 2

Pool 3

Pool 4

P2Pool

4305.75

4300.58

43005.75

43005.75

KYC

27.115

2.905

27.12

27.12

non-KYC

47.58

2716.74

54.25

2740.95

https://docs.google.com/spreadsheets/d/1wB6yKu64AnozACUuJLxwi_ABDEzScFxYfIqDF0mRWkw/edit?usp=sharing

3.5 Collaboration between participants of a payment  pool in a mining pool

Collaboration is needed every time some multisig funds have to be moved, like merging payment pools, coordinated withdrawal. Nevertheless, it is not strictly necessary to make the funds accessible to everyone. Indeed, this scheme is conceived in such a way no participant can keep hostage funds in multisig if he does not collaborate. For example, suppose that that the current block (that is the n-th block) is mined by some participant of the mining pool; the -th payment pool and the temporary payment tree manage the outputs  and  (see Figure 3.1.4) and are calculated before these outputs appear. According to Section 2.7, these payment trees work as a sort of insurance, making it impossible for a participant to keep hostage funds locked to a co-own address. Indeed, if A is non-collaborative during the process of merging  and  in the output  with the merging transaction , then A does partecipate to the multisig process. In this case, A would be ejected by all the payment pools he is involved into and the remaining participants rejoin to the new payment pool, according to Section 2.8 . We remark that the temporary payment trees are constructed by the pool and a miner agrees to mine with a particular temporary payment tree only after he checked the precompiled transactions in the tree’s branch that required his signature. So, it is sufficient and necessary that the pool sends to every miner at the same time the entire payment tree, in order to avoid that some miner finds a block using an incomplete payment tree.

3.6 Possible attacks to a payment pool

In this section we analyse the possible attacks that can be performed to our proposed scheme for a payment pool.

An attacker would join the payment pool and then disrupt the normal activity of the pool. According to Section 2.8, two possible ways to do so are unilateral withdrawals and going offline many times. Then, the pool would split into many sub payment pools that have to be re-merged. This requires collaboration between participants to sign the merging transactions and, moreover, the pool has to create a new payment tree. Every time that a participant goes offline, he does not collaborate in signing rounds, and this disrupts many processes, first of all the merge of payment pools.

A possible way to disincentivize these two behaviours is to manage a form of payment pool entry fee. Call  an amount of BTC. A new miner that wants to join the payment pool, he has to burn . Assume that the miner is already in the pool. If he exit the pool for some reason at the -th block(either unilateral withdrawal or expelled being unresponsive), for rejoining the pool he has to pay a fee of burned funds that corresponds to the following amount:

,

Where  is the average hashrate of the miner and  is the blocks’ interval between the n-th block and the smallest block before n that the miner was online (namely the maximal interval that the miner was online before the block n). The functions  and  are strictly monotone and .

We set this fee with this idea: if a participant wants to perform a dos attack, he must use a mining device with great hashrate (so that  becomes small) and take time to get the “trust” of the pool (so that  becomes small).

A detailed fee scheme is out of the scope of this work.

We remark that if a state performs this, the costs would be immaterial. A possible solution for this is to set the pool KYC, that would make this type of attack impossible.

3.7 Fees

In a normal context, to deploy a payment pool, the participants must pay only the fees of the merging transaction in Figure 3.3.2. To expel an offline participant, must be published

+1

transactions and for merging the remaining sub payment pools is needed a transaction with as many inputs  as the remaining sub payment pools and with a single output. The fees can be calculated directly.

  1.  Technical considerations about payment pools for mining pools

4.1 Wait 100 confirmations

The coinbase funds can be spent only after  block confirmations. There are two solutions that can mitigate this problem. The first, is to keep in memory at most  payment pool, where there is one payment pool, that we call special that collects the funds and the other payment pools are waiting block confirmations to be merged with the special payment pool.

The second is to split participants. If a payment pool has more than  of the bitcoin hashrate, then the pool can split the participants in submining pools, so that the probability for a submining pool to find two blocks at distance  is very low.

4.2 Aggregating pubkeys

We assume also that there is a third party that runs the procedure MuSig2, generating all the addresses and all the transactions as in the tree in Figure 2.2.3. One advantage of a centralised pool, is that this task can be fun filled by the pool for all the participants. We denote this situation by saying that the pool plays the Aggregator role.  We proceed step-by step with the construction of the payment pool with the tree in Figure 2.2.3. And a shared UTXO that is the output from a transaction emitted by the payer’s address .

  • Each participant communicates to the Aggregator the needed data, that is actually his PubKey, the Nonces according to the MuSig2 protocol, and the amount of funds.
  • The aggregator aggregates the participants PubKeys and creates the correspondent bitcoin addresses ,  ecc.
  • Aggregator creates the transactions that correspond to tree’s edges as above.
  • Each participant signs these transactions with ANYPREVOUT and sends back the signature.
  • The Aggregator aggregates the signatures and sends back to each participant the batched signature of every transaction that he is involved into.
  • The Aggregator creates the funding transaction that sends funds to the .

4.3 Qualitative anatomy of transactions that use ANYPREVOUT

For completeness, we include a description of a transaction that spends an input signed with ANYPREVOUT.  Consider, for example, the  transaction  as in Figure 2.2.3, we now give a qualitative description on how this transaction would look like.

According to [12],  spends the P2TR output of the coinbase transaction via the script path. This output is of the form

1 <q>,

Where 1 is the witness version, q is the tweaked pubkey, namely the x-component of the point

,

where  is the generator of the elliptic curve,  is the hash function,  is the point that corresponds to the aggregated public key of the participants  ( for an even number ) and h is the -byte the hash of a script s that is described below (in general, h is the Merkel root of some Merkel tree).

Observe that the address  starts with

bc1p <bech32 encoding of q> <6-characters-checksum>.

The witness of the transaction input is of the form

<n> <d> <s> <c>

where n is the number of witness elements (that in this case is always , see the Specifications of BIP 342 [5]), d is the data for the following item s, that is the script used to tweak the public key p, and c is the control block. The control block is of the form

0xc0 <p> <b>

where p is the internal pubkey p. Now, d is of the form

<sig>,

where sig is the signature of the transaction that has a specific hash_type flag, indicating that it is committed to all the outputs and the amount of the input, but not to any reference of the input. Now, s contains a script that check the signature sig against p, that is an aggregated Schnorr public key, namely a script of the type

<p> OP_CHECKSIG

This transaction has two outputs that correspond to the first two branches of the payment tree in Figure 2.2.3. The first output is of the form

1 <q1>

where q1 is the tweaked public key of the aggregated participants  and . The script used for creating q1 is

<p1> OP_CHECKSIG

Where p1 is the internal public key that corresponds to q1.

The second output is similar, with the aggregated pubkey of  that is replaced with the pubkey of .

  1. Payment pools using CTV and TLUV

5.1 CTV payment pools

In this paragraph we analyse the construction of a payment pool using the opcode OP_CHECKTEMPLATEVERIFY (OP_CTV for brevity). The coinbase has an output with the ScriptPubKey of the form

ScriptPubkey: “0 H1”,

Where H1 is of the form <32-bytes-hash>, namely a P2WSH. To spend this output, it must be presented a witness of the form

Witness: “H2 OP_CTV”,

Where H2 is of the form <32-bytes-hash>. If the hash of the witness coincides with H1, then the script is executed and the output is spent. The value H2 is the hash committed to the following list of values

  1. nVersion,
  2. nLockTime.
  3. scriptSig hash (for non-segwit case),
  4. input count,
  5. sequences hash,
  6. output count,
  7. outputs hash,
  8. input index.

These values refer to the transaction that spends the funding output. We can see that in this transaction there is no signature required. So, one may be tempted to use CTV transactions to implement a payment pool as in Chapter 2, where the miners’ pubkeys appear in the leaf transactions. This would not need any round of signatures.

Nevertheless, with this implementation, money can be spent only flowing through the tree in Figure 2.2.3, ending up to mining pool participants. So, if one participant wants to withdraw, everyone is forced to withdraw. As a consequence of this, it is not possible to merge payment pools and it follows that this implementation is actually worse than directly redistributing the funds, by adding the address of every participant in the outputs of the transaction that spends the output of the funding transaction. Indeed, if the pool has  participants, this implementation requires at least transactions that would occupy more space on the blockchain (even though more efficiently).

One proposal of a payment pool that uses CTV appears in [8], on the occasion of the day 13 of the Bitcoin Advent Calendar of Jeremin Rubin, the author of BIP-119. On the other hand, that solution uses a multisignature scheme, so there are no real benefits compared to the scheme we proposed in Chapter 2.

5.2 TLUV payment pools

In this section we examine the possibility to implement a payment pool using TLUV, proposed in the bitcoin mailing list in [11]. The BIP proposal has a new opcode, TLUV. This opcode allows modifying the Merkle tree, trimming some branches or adding a new script, and removing signatures from the aggregated internal pubkey. The syntax for TLUV is the following

Y H C TLUV

where Y represents the tweak of the internal pubkey, namely the internal pubkey is modified in terms of Y (this is used to remove signatures from an internal aggregated pubkey), H is the leaf script that is added to the Merkle tree and C is an integer that represents “how much” the Merkle tree gets trimmed. If Y=0 or H=0, then, respectively, no modifications are performed to the internal pubkey or no script is added to the Merkle tree. The bip contains a another new opcode IN_OUT_AMOUNT, that pushes two items onto the stack: the amount from this input's UTXO, and the amount in the corresponding output, and then expect anyone using TLUV to use maths operators to verify that funds are being appropriately retained in the updated scriptPubKey.

We give a brief description of how TLUV may be used to deploy a payment pool. We follow the scheme that appears in the original mail of the author in the bitcoin mailing list [13]. Suppose that  are participants of a payment pool that share a UTXO O1. There are scripts S, S, S, S and so on, such that S is the script that allows participant  to withdraw his funds. In other words, if  wants to withdraw his funds, it provides the valid script S that verifies the correct amount of funds returned to the pool, using IN_OUT_AMOUNT and contains something like

<pubkey of X> 0 2 TLUV

where the pubkey of  is removed from the internal aggregated pubkey, 0 means that no leaf is added to the Merkle tree and 2 means that the current script is removed from the leaves of the Merkle tree.  

This payment pool has an advantage, as participants can withdraw whenever they want with just a single transaction, while the scheme of a payment pool that we described and implemented in Chapters 2 and 3 withdrawal is performed during the merging of payment pools or unilaterally, disrupting the activity of the payment pool. Nevertheless, if a participant becomes inactive, then all the others have to eject from the payment pool, each using his script, and rejoin a new one. This requires  transactions, while ejecting a participant with the previous scheme needs  transactions.

If some of the scripts S, S, S, S etc need the  of the previous transaction, a TLUV-only payment pool pool has to calculate a taproot address for every extranonce that every miner is mining with, and this is infeasible (see Section 2.7).

Using TLUV is therefore possible to implement the second naive payment pool Scheme in Section 2.2 without presigning  transactions, where  is the number of participants of the payment pool. Again, this implementation would be convenient as soon as every participant is online. If a participant does not collaborate, then all the other participants have to exit using their scripts and rejoin to another payment pool. Unfortunately, this requires  transactions, while with our scheme, ejecting a non-collaborative participant, would require only  transactions to be published.

5.3 Payment pools for mining pools using ANYPREVOUT  and TLUV

In this section we discuss the use of TLUV and ANPREVOUT in synergy in order to deploy a payment pool that has the benefits of both the proposals. Assume that the payment pool is deployed among the miners of a mining pool that want to share their funds in a single UTXO and want to add to the payment pool the coinbase reward. We use the notations of Section 3.1. Firstly, we can assume that the -th payment pool uses TLUV for allowing everyone to withdraw their funds with the correspondent scripts, and a payment tree, built with ANYPREVOUT, that allows the pool to eject a non-collaborative participant. The temporary payment tree is constructed as in Section 3.1. If some miner finds a block, then the temporary payment tree and the -th payment pool has to be merged into a third payment pool. This last uses TLUV for allowing cheap withdrawal and a payment tree for allowing ejecting non-collaborative participants; the payment tree has to be constructed earlier, using ANYPREVOUT.

If a participant does not collaborate, then it can be ejected using the payment trees and the participants can rejoin to a new payment pool.

So, assuming TLUV and ANYPREVOUT, it is possible to implement a payment pool for mining pool’s miners (that we suppose to be  in number) with the following characteristics.

  • Participants can withdraw using one single transaction at any time.
  • If some miner of the pool finds a new block, the coinbase output can be merged with the previous payment pool to a new payment pool.
  • If a participant does not collaborate, it can be unilaterally ejected with  transactions.

  1. Conclusions

From Section 5.1, it seems that the rigidity of CTV makes it difficult to deploy a payment pool that is suitable for our case, even though we leave open the possibility of some resolutive tricky implementation we are not aware of. It is the opinion of the authors that the following are the most interesting schemes for a payment pool suitable for our purposes.

  1. Using only ANYPREVOUT
  2. Using ANYPREVOUT and TLUV
  3. Using only TLUV

Note that, as TLUV is in a very early phase of development, it is not clear whether it is affected by Problem 1 of Section 4.1. In the worst case, TLUV alone may not be enough to implement a payment pool suitable for our scopes; in this case, ANYPREVOUT would be needed. We present a summary of pros and cons of the schemes analysed.

pros

cons

ANYPREVOUT

Requires only one BIP, cheapest for unilateral ejection, low communication

Expensive for withdrawal

TLUV

Easiest to deploy,  cheapest for withdrawal

Expensive for unilateral ejection, lightly discussed, may not be enough

ANYPREVOUT+TLUV

Cheapest for withdrawal and unilateral ejection, low communication

Difficult to deploy, requires 2 BIPs, whose one in a very early stage

So, we think that, for our purposes, an ANYPREVOUT-only payment pool would be the best choice to implement first, leaving space for a TLUV update.
We also remark that our scheme is suitable for KYC pools, as the average weight in the blockchain occupied for the normal activity of the payment pool is very limited (see Section 3.4).

References

[1] https://anyprevout.xyz/

[2] https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg11383.html

[3] https://braiins.com/stratum-v2

[4] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki

[5] https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki

[6] https://github.com/jonasnick/bips/blob/musig2/bip-musig2.mediawiki

[7] Jonas Nick, Tim Ruffing, and Yannick Seurin, “MuSig2: Simple Two-Round Schnorr Multi-Signatures”, Cryptology ePrint Archive, 2020/1261.

[8] https://rubin.io/bitcoin/2021/12/10/advent-13/

[9] https://bitcoinops.org/en/topics/cpfp/

[10] https://bitcoinops.org/en/tools/calc-size/

[11] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019419.html

[12]https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

[13]https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019420.html

[14] G. Naumenko, A. Riard, “CoinPool: efficient off-chain payment pools for Bitcoin”, https://coinpool.dev/v0.1.pdf.

[15] https://laurentiapool.org/wp-content/uploads/2020/05/laurentiapool_whitepaper.pdf