What about Bitcoin network congestion? Cut to cure – Secure the Bag safety bag technology

Bitcoin's network congestion varies widely. At the peak of the transaction, thousands of transactions are waiting to be packaged into blocks, resulting in soaring fees and many users still have to wait. At the same time, when there are fewer transactions, there are not enough transactions to fill the entire block, and the minimum fee is enough to confirm quickly.

Of course, for services that need to quickly complete a large number of transactions, network congestion during peak hours is a big problem. For example, an exchange, a pool, or a payroll service sometimes pays hundreds of users at the same time, and these users may be eager to get money, which is human nature. Therefore, these services require high fees to prioritize these transactions.

Now, bitcoin core developer Jeremy Rubin believes that he has found ways to reliably mitigate network congestion and increase bitcoin throughput during peak hours.

His solution is called OP_SECURETHEBAG .

• Ethereum 2.0 will be accelerated, and the simplification of the splicing scheme will be freshly released.
• The future of Bitcoin under the Great Depression
• Full-text translation + interpretation | New rules of the US Internal Revenue Service: income tax due to forked virtual currency

Secured bag technology (Securing the Bag)

To understand OP_SECURETHEBAG (hereafter referred to as "safety bag"), let us take a practical example as an example to start with the basics. In this example, there are 12 customers who request a withdrawal request when the transaction is at a higher fee. (In reality, this number may be 1200. Here, 12 customers are used to make it easier to explain concepts.)

Even without a safety bag, the exchange would not be so stupid to create 12 separate transactions to transfer money to each customer. Instead, in order to save money, it creates a "batched" transaction . The transaction may contain 3 inputs (including 3 "corresponding addresses" corresponding to the exchange) and 12 outputs (including "to" receipt addresses for different customers). In this example, assume that the output amount plus the handling fee is exactly equal to the input, so there is no change address .

In the image below, the left side is a separate transaction and the right side is a batch transaction .

Image taken from Jeremy Rubin at the Scaling Bitcoin 2019 conference on the OP_SECURETHEBAG demo

Since batch transactions contain many outputs (one to many customers), they are very large in terms of data. The larger the volume of a transaction, the higher the cost of packaging it into a block. During peak hours, the exchange will quickly make the cost of the transaction confirmation very high. (Although not as expensive as 12 separate transactions, the cost is still high.)

Exchanges may also use lower fees to save costs, in which case it will take some time to confirm the transaction. But before the transaction is confirmed, the customer is not sure if they will actually receive the money and needs to wait all the time: the money may be spent twice until the transaction is written to the block. This will make the customer very upset and the exchange does not want to. (In some cases, it may even be not allowed to wait for the customer to wait: for example, according to the contract, the payment is obligated to confirm the transaction on a specific day.)

The role of the safety bag is reflected here.

The security bag is a proposed "OpCode" – an additional feature of the Bitcoin programming language. The opcode is essentially a way for the exchange to "split" the batch transactions into two transactions: a "payment" transaction and a "receipt" transaction .

The "Payment" transaction contains three original inputs, corresponding to the address of the exchange. But it only contains a special output. This output is called a "committed output" and contains a password hash: a seemingly random but relatively short string of numbers.

This hash value is essentially a unique serial number that links to the other of the two transactions: the "receipt" transaction . The key to a security bag is that the "committed output" can only be used through this particular "payment" transaction and is linked by a hash value. (In technical terms, the hash value will be submitted to the entire "receipt" transaction except "prevouts", which is an implementation detail.)

A "receipt" transaction can be considered the second half of the original transaction. It only contains one input (corresponding to the submitted output in the "Payment" transaction) and all 12 outputs. Therefore, a "receipt" transaction that contains all of the output is much larger than a "payment" transaction.

In the image below, you can see that the left side is a normal batch transaction, and on the right are two separate transactions ("Payment" and "Receipt").

Image taken from Jeremy Rubin at the Scaling Bitcoin 2019 conference on the OP_SECURETHEBAG demo

When the exchange issues a payment to 12 customers, both the "payment" and "receipt" transactions are broadcast. But there is a big difference between the two, which is the core of the program. Smaller "payment" transactions involve a relatively large fee to ensure a quick confirmation. Since the transaction is small, from a data point of view, even a relatively large fee will not be much.

In contrast, larger "receipt" transactions involve relatively low fees, which means it may take some time to confirm. But here, waiting for a low-price transaction confirmation is not a big deal for the customer, because once the "payment" transaction is confirmed, it can be guaranteed that the money is guaranteed to correspond to a unique "receipt" transaction . Funds will be anchored in the blockchain and can only be received by these exchange customers.

Although the money is not in place… but the funds have been properly kept.

Child Pays for Parent?

Although the basic examples outlined above can ensure that the customers of the 12 exchanges eventually receive their funds, this may not fully satisfy them.

(*If the transaction fee has not fallen below the required level, the “receipt” transaction will not actually confirm itself; this can be solved by the techniques described in the second half of this article.)

For example, Alice, one of the 12 exchange clients, must pay the rent to the landlord today. At this time, it is not enough to know that she will eventually receive money from the exchange – no matter how much she is sure she will receive the money (the landlord does not care). What she actually needs is the ability to spend her output.

This is technically possible. Alice can take out her unconfirmed output (one of 12) and immediately use it in a new transaction. The only problem is that Alice's transaction can only be confirmed after the "receipt" transaction has been confirmed. At the same time, the landlord’s request for the rent of the rent will arrive today.

Fortunately, Alice can use an old bitcoin technology to ensure that both the “receipt” transaction and her own transaction are confirmed: “Child Pays for Parent” (CPFP) . Basically, if Alice pays the landlord a transaction that contains a high enough fee, the miner will also be motivated to package the "receipt" transaction into the block – although the "receipt" transaction itself is charged for them. Not very attractive. But after all, only two transactions were confirmed at the same time, they can get Alice's high fees.

In other words, it will be very expensive to speed up the process of confirming the “receipt” transaction with a large amount of data. This is why the exchange used the "safety bag" for the first time. At this time, Alice needs to pay for the handling of all 12 customers in batches, not the exchange. But in this way, Alice, who is also a customer, will be very uncomfortable.

Fortunately, the safety bag provides a better solution.

Tree Payments

In order to solve Alice's problems, the exchange can further use the special means of "safety bags".

In the basic example above, the "payment" transaction contains a submitted output, and the "receipt" transaction contains a corresponding input and 12 normal outputs. But in fact, these 12 outputs can be further split into more "receipt" transactions .

For example, a "payment" transaction can include two submitted outputs, corresponding to two different "receipt" transactions , each of which contains six normal outputs. Of course, this means that for quick confirmation, the fee for the "payment" transaction will be higher, but Alice will have to pay more than half of the cost: she only has to pay for the other 5 other customers instead of 11 One.

Even better, the exchange can create "intermediate" deals between the initial "payment" transaction and the final "receipt " transaction ! These "intermediate" transactions contain an input and any submitted output, and may also contain normal output, creating a tree structure. In this way, the exchange can reasonably reduce the cost of CPFP even for customers whose services require immediate capital turnover. Customers in a hurry can only pay for their related intermediate transactions at most, regardless of the rest of the transaction.

As shown in the following figure, the exchange can choose the most suitable way to create this tree transaction structure according to its own needs. (The more intermediate steps, the more total transaction data that typically needs to be confirmed on the blockchain, but the lower the cost per user. The “chained” payment is similar to tree-based payments, but more dependent on transactions. Chronologically.)

Image taken from Jeremy Rubin at the Scaling Bitcoin 2019 conference on the OP_SECURETHEBAG demo

Details and implementation

This article describes the basic implementation logic of the Secure The Bag. In fact, this solution can be implemented and replaced in many ways. For example, Alice does not have to use CPFP to pay the landlord, but can receive funds through the Lightning Network and pay the landlord immediately. There are other, more complex solutions that can speed up "receipt" transactions.

In addition, strictly speaking, the “safe bag opcode” in the solution is not the only way to implement a two-phase payment solution. Even with the current Bitcoin protocol, a similar purpose can be achieved – but requiring all recipients to coordinate and collaborate, which is difficult to achieve in the exchange and its customer examples, and as more users join, this The situation will become more difficult. Other solutions, such as covenants , require an upgrade to the Bitcoin protocol.

Implementing a security bag also requires upgrading the Bitcoin protocol, but it can be done with a backward compatible soft fork. The current project proposer, Rubin, has completed most of the coding work required – the code and ideas are still to be reviewed. In addition, even if the proposal passes the review of all peers, the protocol upgrade may take some time to be adopted. Therefore, it is not yet possible to determine when the "safety bag" will be officially launched (if passed).

Author: Aaron Van Wirdum

Translation & Editing: Peter Hon

Source: Bitcoin Magazine

We will continue to update Blocking; if you have any questions or suggestions, please contact us!