{"id":19210,"date":"2019-10-04T13:00:55","date_gmt":"2019-10-04T13:00:55","guid":{"rendered":"http:\/\/ci027cfe65a01126c3"},"modified":"2025-01-27T21:16:47","modified_gmt":"2025-01-27T21:16:47","slug":"secure-the-bag-cutting-transactions-in-half-to-resolve-bitcoin-network-congestion","status":"publish","type":"post","link":"https:\/\/bitcoinmagazine.com\/technical\/secure-the-bag-cutting-transactions-in-half-to-resolve-bitcoin-network-congestion","title":{"rendered":"Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion"},"content":{"rendered":"
<\/div>
<\/figure>\n

Edit note, November 20, 2019: Since original publication of this article, OP_SECURETHEBAG has been renamed as OP_CHECKTEMPLATEVERIFY.<\/em><\/p>\n

Bitcoin\u2019s network congestion can vary wildly. During some hours of some days, tens of thousands of transactions are waiting to get included in a block, causing fees to spike and leaving many users waiting. During slower hours, meanwhile, there aren\u2019t even enough transactions to fill all blocks, and the smallest of fees suffice for quick confirmation.<\/p>\n

Network congestion during peak hours is of course a big problem for services that need to make many transactions, fast. Exchanges, mining pools<\/a> or payroll services, for example, sometimes pay hundreds of users simultaneously \u2014 and these users may be understandably impatient to get their money. The services therefore pay high fees, bumping all other transactions on the Bitcoin network back in the queue.<\/p>\n

Now, Bitcoin Core contributor Jeremy Rubin believes he has figured out how to reliably smooth out network congestion, increasing Bitcoin\u2019s throughput during peak hours.<\/p>\n

His proposal is called OP_SECURETHEBAG.<\/p>\n

Securing the Bag<\/h2>\n

To understand OP_SECURETHEBAG (which, from now on, we\u2019ll simply call \u201cSecure the Bag\u201d), let\u2019s take a practical example and start from the basics. In this example, 12 customers all request that an exchange issue their withdrawals while fees are high. (In reality this might easily be 1,200 customers \u2014 but with 12, the concept is easier to explain.)<\/p>\n

Even without Secure the Bag, the exchange is sensible and does not create 12 separate transactions to pay each customer individually. Instead, to save on fees, it creates a \u201cbatched\u201d transaction, which is more compact. The transaction consists of, say, three inputs (referring to the \u201cfrom\u201d addresses, all three of which belong to the exchange) and 12 outputs (which include the \u201cto\u201d addresses, belonging to the different customers). In this example, the amounts add up nicely, so there is no change address.<\/p>\n

In the images below, the transaction would look like transaction A on the right \u2014 not like 12 individual transactions as shown to the left. <\/p>\n

<\/figure>\n

Because the batched transaction includes so many outputs \u2014 one for each customer \u2014 it is quite large, data-wise. The larger a transaction is, the more it costs to have it included in a block. And during peak hours, it will be quite expensive for the exchange to have the transaction confirm quickly. (Not as expensive as 12 individual transactions would be, but still expensive.)<\/p>\n

Now, it is possible for the exchange to include a lower fee instead, in which case it would just take a while for the transaction to confirm. But until it confirms, customers would be waiting for their money, unsure if they will really receive it at all: The money could be double-spent until the transaction is included in a block. This leaves the customers unhappy, and the exchange doesn\u2019t want that. (In some cases, it may not even be an option to let customers wait: Payroll services could, for example, be contractually obligated to have the transaction confirmed on a particular day.)<\/p>\n

This is where Secure the Bag comes in.<\/p>\n

Secure the Bag is a proposed \u201cOpCode\u201d: an addition to Bitcoin\u2019s programming language. This OpCode would essentially let the exchange \u201csplit\u201d its batched transaction into two transactions: a \u201csending\u201d and \u201creceiving\u201d transaction.<\/p>\n

The first of these \u2014 the \u201csending\u201d transaction \u2014 includes the three original inputs, referring to the addresses owned by the exchange. But it includes only one special output. This output is called a \u201ccommitted output\u201d and contains a cryptographic hash: a seemingly random but relatively short string of numbers.<\/p>\n

This hash essentially serves as a unique serial number, linking it to the other of the two transactions: the \u201creceiving\u201d transaction. Key to Secure the Bag, the only way the committed output can be spent is through this specific \u201creceiving\u201d transaction, to which it is linked through the hash. (In technical terms, the hash commits to the entire \u201creceiving\u201d transaction except for the \u201cprevouts,\u201d but this is an implementation detail.)<\/p>\n

The \u201creceiving\u201d transaction can be considered the second half of the original transaction. It contains only one input, referring to the committed output from the \u201csending\u201d transaction, and all the 12 outputs. This \u201creceiving\u201d transaction, with all the outputs, is therefore much larger than the \u201csending\u201d transaction.<\/p>\n

In the images below, you can see the normal batched transaction on the left, and the two separated transactions (\u201csending\u201d and \u201creceiving\u201d) of a Secure the Bag payment on the right.<\/p>\n

<\/figure>\n

As it issues the withdrawal to its 12 customers, the exchange broadcasts both the \u201csending\u201d and \u201creceiving\u201d transactions. But there is one big difference between the two, and this is the heart of the trick. The smaller \u201csending\u201d transaction includes a relatively large fee, to ensure that it confirms fast. Since this transaction is small, data-wise, even a relatively large fee is manageable.<\/p>\n

The larger \u201creceiving\u201d transaction, in contrast, includes a relatively low fee, meaning it could take a while to confirm. But this time, the wait for a low-fee transaction to confirm shouldn\u2019t be a big problem for the customers, because once the \u201csending\u201d transaction has confirmed, it ensures that all the money is guaranteed to the \u201creceiving\u201d transaction. The funds are anchored in the blockchain and have nowhere else to go but to the exchange\u2019s customers.<\/p>\n

The money isn\u2019t quite there yet \u2026 but the bag has been secured.<\/p>\n

Child Pays for Parent<\/h2>\n

While the basic example as outlined above would ensure* that the exchange\u2019s 12 customers get their funds eventually, this may not satisfy all of them quite yet.<\/p>\n

(*In the event that transaction fees never come down to the required level, the \u201creceiving\u201d transaction would actually not confirm on its own; this is resolved though the same trick as explained in the remainder of this article.)<\/p>\n

By way of example, Alice, one of the 12 customers, must pay her landlord today. Therefore, just knowing that she will receive her money from the exchange eventually doesn\u2019t suffice \u2014 no matter how sure she is that she will indeed receive it. She actually needs to be able to spend her output. <\/p>\n

This is technically possible. Alice can take her unconfirmed output (one of the 12), and spend it in a new transaction immediately. The only problem: Alice\u2019s transaction will only confirm after the \u201creceiving\u201d transaction is also confirmed. Meanwhile her landlord is demanding a confirmed transaction today.<\/p>\n

Luckily enough, Alice can leverage an older Bitcoin trick to ensure that both the \u201creceiving\u201d transaction and her own transaction confirm: \u201cChild Pays for Parent\u201d (CPFP). Basically, if Alice includes a high enough fee in her transaction to the landlord, miners will be incentivized to include the \u201creceiving\u201d transaction in a block as well \u2014 even if they don\u2019t care for the fee on the \u201creceiving\u201d transaction itself. After all, they only get Alice\u2019s high fee by confirming both.<\/p>\n

That said, compensating for the large \u201creceiving\u201d transaction would be quite expensive. That\u2019s why the exchange used Secure the Bag in the first place. Instead of the exchange, now Alice would be paying for the batched transaction to all 12 customers. This wouldn\u2019t make her a very happy customer.<\/p>\n

Fortunately, Secure the Bag offers a better solution.<\/p>\n

Tree Payments<\/h2>\n

To solve Alice\u2019s problem, the exchange could take the Secure the Bag trick one step further.<\/p>\n

In the basic example shown above, the \u201csending\u201d transaction includes one committed output, while a single \u201creceiving\u201d transaction includes one corresponding input and 12 normal outputs. But it is possible to further split up these 12 outputs over more \u201creceiving\u201d transactions.<\/p>\n

The \u201csending\u201d transaction could, for example, include two committed outputs, referring to two different \u201creceiving\u201d transactions that each include six normal outputs. This would mean, of course, that the \u201csending\u201d transaction is a bit more expensive to have confirmed fast, but Alice\u2019s cost would be more than halved: She\u2019d now pay for only five other customers instead of eleven.<\/p>\n

Even better, the exchange could create \u201cintermediate\u201d transactions between the initial \u201csending\u201d transaction and the eventual \u201creceiving\u201d transactions! These \u201cintermediate\u201d transactions would all include one input and one or several committed outputs and possibly normal outputs, creating a tree structure. In this way, the exchange can reasonably minimize the CPFP cost, even for customers who need to spend their funds straight away. Customers in a hurry would need to pay for the intermediate transactions relevant to them, at most, and ignore the rest.<\/p>\n

As shown in the images below, the exchange can create such a tree as creatively as desired, depending on what works best for its customers. (More intermediate steps would generally require more total transaction data to be confirmed on the blockchain \u2014 but less cost per individual user. \u201cChained\u201d payments are similar to Tree payments, but are more dependant on the chronology of transactions.)<\/p>\n

<\/figure>\n

Details and Deployment<\/h2>\n

This article describes fairly basic implementations of Secure the Bag. In actuality, the proposal could be implemented and utilized in various ways. For example, rather than Alice needing to use CPFP to be able to pay her landlord, she could receive funds into Lightning channels and instantly be able to pay her landlord through those. There are also other, more complicated solutions to speed up the \u201creceiving\u201d transaction.<\/p>\n

Also, the proposed Secure the Bag OpCode is, strictly speaking, not the only way to realize the two-phase payment solution. Even with the current Bitcoin protocol, something similar could be achieved \u2014 but it would require all recipients to coordinate and cooperate, which is not very likely in the example of an exchange and its customers, and such a scenario would become harder as more users join. Others solutions (such as covenants) would require Bitcoin protocol upgrades.<\/p>\n

Secure the Bag, too, would require a protocol upgrade by means of a backward-compatible soft fork. Rubin has already done most of the coding work required \u2014 though both the code and the idea are still subject to review. Further, even if the proposal passes all peer review, protocol upgrades can take a while to be adopted. As such, there is currently no estimation as to when Secure the Bag will be live on Bitcoin \u2014 if ever.<\/p>\n

Thanks to Jeremy Rubin for information and feedback. For more information, simulation data and various other use cases for Secure the Bag, also see the relevant<\/em> Bitcoin Improvement Proposal<\/em><\/a>, the development mailing-list<\/em> discussion<\/em><\/a> on the topic and Rubin\u2019s full presentation at Scaling Bitcoin 2019 in Tel Aviv:<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

Bitcoin Core contributor Jeremy Rubin may have figured out how to reliably smooth out network congestion, increasing Bitcoin\u2019s throughput in peak hours.<\/p>\n","protected":false},"author":2509,"featured_media":15752,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[35],"tags":[227,2351,1563,477,2254],"class_list":{"0":"post-19210","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-technical","8":"tag-bitcoin-core","9":"tag-jeremy-rubin","10":"tag-opcode","11":"tag-payments","12":"tag-technical"},"author_data":{"id":2509,"name":"Aaron van Wirdum","nicename":"aaron-van-wirdum","avatar_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/12\/aaron-van-wirdum-96x96.jpg"},"featured_image_url":"https:\/\/bitcoinmagazine.com\/wp-content\/uploads\/2024\/11\/bitcoin-magazine-bag.png","_links":{"self":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/19210","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/users\/2509"}],"replies":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/comments?post=19210"}],"version-history":[{"count":0,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/posts\/19210\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media\/15752"}],"wp:attachment":[{"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/media?parent=19210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/categories?post=19210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bitcoinmagazine.com\/wp-json\/wp\/v2\/tags?post=19210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}