Bitcoin payment pools may be one of the most ambitious ideas for cryptocurrency’s future. Here is what it is all about.
Payment pools, a potential Layer Two solution made possible through Taproot, could let groups of bitcoin users share UTXOs for more privacy.
In October, developers introduced a proposal into the Bitcoin Core client’s source code that includes Shnorr’s signatures and Taproot and Tapscript technologies. The timing of its activation remains open, but the solution, which many people are looking forward to, offers the potential to create new, often very curious scenarios. Taproot is the second part of the offer. While Snorr’s scheme offers a new type of signature, Taproot expands their functionality — a combination of cryptographic tricks allows users to hide details of their financial activity behind seemingly ordinary Bitcoin transactions.
Moreover, Taproot technology has already become a source of inspiration for new ideas and developments that may become another part of Bitcoin in the future. Based on the basic idea of Taproot, Jeremy Rubin, Antoine Reard, Gleb Naumenko, Gregory Maxwell and other Bitcoin Core developers have started discussing the concept of payment pools. Such pools (JoinPool, CoinPool) could allow a group of users to act as joint owners of the same coins (transaction outputs) and make payments between them.
Since the group itself and its individual members are hidden in the Taproot structure, a higher level of privacy and flexibility of smart contracts is achieved, and other benefits also appear. These include the potential to send and receive transactions off-chain, i.e. without recording data in the blockchain. This turns payment pools into a new second layer of Bitcoin. The design features of the payment pools differ depending on the offers, but they all share a common idea.
To create a payment pool, users combine their coins on the Taproot address. For example, Alice has three coins, Bob has two and Carol has one. They have a total of six coins. Together they create a transaction by sending these coins to a common address they know and creating a payment pool with these six coins.
In a blockchain, the payment pool is displayed as a normal Bitcoin address with the six coins. But this is only on the surface, and in reality Alice, Bob and Carol have used Taproot technology, which ensures that each of them owns a corresponding share of the coins. At any moment, all participants in the payment pool can withdraw their own coins.
This possibility is ensured by the fact that there are two main options for spending coins from a common address. The first option is the possibility of sending funds directly from the address using cryptographic signatures. This requires the consent of all participants and such a transaction will be no different from any other transaction in the Bitcoin network. Alice, Bob and Carol can each send coins to themselves or, for example, donate them to Julian — the goals are not important, the consent of all three participants is important as without this it will not be possible to make the payment.
The second option has several sub-options. Before sending coins to the Alice payment pool, Bob and Carol have included the option of alternative spending in the underlying Taproot tree. If one of the participants chooses to spend the coins through this alternative path, they send the amount corresponding to their balance in the payment pool to the address they control. The remaining coins will also be automatically spent in the process.
This can be done in several ways, depending on the design of the payment pool, each of which has its own weaknesses in terms of complexity and scalability. The easiest way is to send each participant their share of the coins. In other words, if Alice leaves the payment pool, Bob and Carol also leave it.
The second way, which Reard and Naumenko prefer, is to send all remaining coins to the new payment pool. This pool looks exactly the same as the first one, but there will no longer be any coins of the outgoing participant. This design offers the best possible user interaction, but it turns out to be the most difficult in terms of scalability, primarily because it is necessary to prepare for all possible exit scenarios for participants, including those involving a transition to the new payment pool. A possible solution could be an unnamed Bitcoin protocol upgrade, which would allow the rules to be transferred to the new payment pool.
To understand what it means to send the remaining coins to the new payment pool in practice, let us present a scenario in which Alice, Bob and Carol choose the second method (all remaining coins are sent to the new pool). If Alice leaves the first pool, the remaining three coins are sent to the address she has specified, the remaining three coins will end up in a new pool in which Bob and Carol will participate. Alice can now dispose of the coins belonging to her at her own discretion. Nothing has changed for Bob and Carol: they can still spend the remaining coins on their chosen targets, or each of them can leave the payment pool.
The possibility to spend the funds in the payment pool, subject to general agreement, gives another opportunity: the payment pool can be dynamic. Participants can not only withdraw their coins or pay others, they can also do something more interesting — transfer coins to new versions of the payment pools with different designs.
For example, Alice buys a new car and wants to pay for it with one bitcoin. Alice, Bob and Carol can create a transaction where one coin goes to the car dealer and the other five are sent to the new payment pool. It will look exactly the same as the first one, except that Alice will already have two coins — one less than before.
The transaction will look like a regular Bitcoin transaction, in other words, the car dealer or blockchain spy will think that Alice owned all six bitcoins, of which one was spent to buy a car. They will not know that some of the coins belonged to Bob and Carol and that they were involved in the transaction.
The next time Bob decides to send the money, they will leave the same payment pool, which still looks like a normal bitcoin transaction to the others. Blockchain spies may think that Alice is sending the transaction again. Even if they somehow find out that they are dealing with the payment pool, they will still not be able to determine which of the participants made the last payment — the author of the transaction may be Alice, Bob or Carol.
New users can join the payment pool in the same way. If Alice, Bob and Carol agree to accept Dave’s coins into the payment pool, they will create a new transaction where the funds in the existing pool are sent to the new payment pool together with Dave’s coins. Dave will become a member of the new pool and receive equal opportunities with the rest of the money.
Another option gives the participants in the payment pool the opportunity to pay each other. For example, if Alice wants to pay one coin to Bob, the participants in the pool send funds to the new payment pool, where one coin is deducted from Alice’s balance and Bob’s balance is increased by one coin. The entry in the blockchain still looks like an ordinary bitcoin transaction, and it is impossible to say what is really behind it.
Moreover, additional upgrades to the Bitcoin source code, such as the activation of Noinput, make it possible for off-site transactions to occur. These types of payment pools can potentially be used to support the Lightning Network protocol itself or other Layer 2 protocols, hiding the complexity of the mechanism involved behind the veil of a conventional Bitcoin transaction for an onlooker.
Learn more about Bitcoin and earn daily rewards in cryptocurrency with our cloud-based Bitcoin mining platform Hashmart.io!