In October, developers implemented into the Bitcoin Core client’s source code a proposal that includes Schnorr signatures and Taproot and Tapscript technologies. Activation timelines remain open, but the decision, eagerly anticipated by many, opens the potential for creating new, often quite intriguing scenarios.
Taproot is the second part of the proposal. If the Schnorr scheme offers a new type of signature, Taproot expands their functionality — thanks to a combination of cryptographic tricks, users gain the ability to hide details of their financial activity behind outwardly ordinary Bitcoin transactions.
Taproot is close, or The next step in Bitcoin’s evolution
Moreover, Taproot has already inspired new ideas and developments that could become another part of Bitcoin in the future. On what work is underway in this direction, in particular on creating a new second layer analogous to the Lightning Network, we present in an adapted translation of Aaron van Wirdum’s article from Bitcoin Magazine.
Building on the basic idea of Taproot, Jeremy Rubin, Antoine Riard, Gleb Naumenko, Gregory Maxwell and other Bitcoin Core developers began discussing the concept of payment pools. Such pools (JoinPool, CoinPool) could allow a group of users to act as co-owners of the same coins (transaction outputs) and make payments among themselves.
Because the group itself and its individual members are hidden within the Taproot structure, a higher level of privacy and flexibility of smart contracts is achieved, and there are other advantages. Among them is the potential ability to send and receive off-chain transactions, i.e., without recording data on the blockchain. This makes payment pools a new second layer of Bitcoin.
The design features of payment pools differ across proposals, but they share a common idea.
Joint ownership of coins
To create a payment pool, users consolidate their coins on a Taproot address. For example, Alice has three coins, Bob two, Carol one. In total they have six coins. Together they create a transaction, sending these coins to a common address known to them and forming a payment pool with these six coins.
In the blockchain, the payment pool appears as a standard Bitcoin address containing six coins. But beneath the surface, Alice, Bob and Carol have used Taproot technology, which ensures each holds the corresponding share of the coins. At any moment all participants can withdraw the coins attributed to them.
The capability is enabled by two main options for spending coins from the shared address.
The first option is the ability to send funds directly from the address using cryptographic signatures. This requires the consent of all participants, and such a transaction would be indistinguishable from any other Bitcoin network transaction. Alice, Bob and Carol may send coins to themselves or, for example, donate them to Julian—the destination is not important; what matters is the consent of all three participants, since without it the payment cannot be made.
The second option has several sub-options. Before sending coins into the pool, Alice, Bob and Carol included in the Taproot-address underlying cryptographic tree the possibility of an alternative spending path. If one of the participants decides to spend coins via such an alternative path, they send the amount corresponding to their balance in the pool to an address they control. The remaining coins are automatically spent as well.
This can be done in several ways, depending on the pool’s design, each with its own drawbacks in terms of complexity and scalability. The simplest way is to pay each participant their share of coins. In other words, if Alice leaves the payment pool, Bob and Carol also leave it.
The second method, preferred by Riard and Naumenko, is to send all remaining coins to a new payment pool. This pool looks exactly like the first, except that it will contain no coins belonging to the departed participant.
This design offers the best user experience, but proves most challenging from a scalability perspective, primarily because one must plan for all possible exit scenarios of participants, including transitions to a new payment pool. A potential solution could be an as-yet unnamed upgrade to Bitcoin’s protocol that moves rules to the new payment pool.
A tricky softfork case: how the next Bitcoin update will be activated
Jeremy Rubin, however, does not consider such a solution practical, preferring a middle ground between the first and second methods: some participants receive coins to their own addresses, while the coins of other participants are sent to a new payment pool. This solution is less ideal from a user experience standpoint, but offers better scalability.
To understand what sending the remaining coins to the new payment pool means in practice, consider 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, her three coins are sent to the address she specifies, the remaining three coins end up in the new pool, whose participants will be Bob and Carol. Now Alice can dispose of her coins as she wishes; nothing changes for Bob and Carol: they can still spend the remaining coins for their chosen purposes, or each of them may leave the payment pool.
Payment scenarios
The ability to spend funds in the pool with mutual consent offers another possibility: the payment pool can be dynamic. Participants can do more than withdraw their coins or pay others; they can also move coins into new versions of 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 under which one coin goes to the car dealer, and the remaining five are sent to the new payment pool. It will look exactly like the first, except that Alice will now have two coins — one fewer than before.
The transaction will appear as a regular Bitcoin transaction, and in other words the car dealer or blockchain spies will conclude that Alice owned all six Bitcoins, of which she spent one to buy the car. They will not know that some coins belonged to Bob and Carol or that they participated in the transaction.
Next time Bob decides to send funds, they will depart from the same pool, which for others still looks like a normal Bitcoin transaction. Blockchain spies might think that the transaction is being sent again by Alice. Even if they somehow determine that they are dealing with a payment pool, they still cannot determine which participant made the last payment—the author of the transaction could be either Alice, Bob, or Carol.
In the same way, new users can join the payment pool. If Alice, Bob and Carol agree to admit Dave to the pool, together with him they will create a transaction in which funds in the existing pool along with Dave’s coins are moved to a new payment pool. Dave becomes a participant in the new pool and gains the same rights as the others.
Another option gives the pool participants the ability to pay one another. For example, if Alice wants to pay Bob one coin, the pool participants move funds to a new payment pool in which one coin is deducted from Alice’s balance and Bob’s balance is increased by one. The on-chain record still looks like a standard Bitcoin transaction, and what it actually hides behind cannot be said.
Moreover, additional upgrades to Bitcoin’s core code, for example the activation of the Noinput protocol [proposed by Blockstream’s Christian Decker as a soft fork for the Lightning Network – ForkLog], enable off-chain transactions.
Such types of payment pools could potentially support the Lightning Network protocol itself or other second-layer protocols, hiding the full complexity of the mechanism behind the veil of a Bitcoin transaction that is ordinary to a casual observer.
Subscribe to ForkLog news on Telegram: ForkLog FEED — the full news feed, ForkLog — the most important news and polls.