Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion

Bitcoin’s 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’t even enough transactions to fill all blocks, and the smallest of fees suffice for quick confirmation.

Network congestion during peak hours is of course a big problem for services that need to make many transactions, fast. Exchanges, mining pools or payroll services, for example, sometimes pay hundreds of users simultaneously — 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.

Now, Bitcoin Core contributor Jeremy Rubin believes he has figured out how to reliably smooth out network congestion, increasing Bitcoin’s throughput during peak hours.

His proposal is called OP_SECURETHEBAG.

Coinbase 8

Securing the Bag

To understand OP_SECURETHEBAG (which, from now on, we’ll simply call “Secure the Bag”), let’s 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 — but with 12, the concept is easier to explain.)

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 “batched” transaction, which is more compact. The transaction consists of, say, three inputs (referring to the “from” addresses, all three of which belong to the exchange) and 12 outputs (which include the “to” addresses, belonging to the different customers). In this example, the amounts add up nicely, so there is no change address.

In the images below, the transaction would look like transaction A on the right — not like 12 individual transactions as shown to the left. 

Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 1
Images taken from Jeremy Rubin’s presentation on OP_SECURETHEBAG at Scaling Bitcoin 2019
Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 1
Images taken from Jeremy Rubin’s presentation on OP_SECURETHEBAG at Scaling Bitcoin 2019

Because the batched transaction includes so many outputs — one for each customer — 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.)

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’t 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.)

This is where Secure the Bag comes in.

Secure the Bag is a proposed “OpCode”: an addition to Bitcoin’s programming language. This OpCode would essentially let the exchange “split” its batched transaction into two transactions: a “sending” and “receiving” transaction.

The first of these — the “sending” transaction — 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 “committed output” and contains a cryptographic hash: a seemingly random but relatively short string of numbers.

This hash essentially serves as a unique serial number, linking it to the other of the two transactions: the “receiving” transaction. Key to Secure the Bag, the only way the committed output can be spent is through this specific “receiving” transaction, to which it is linked through the hash. (In technical terms, the hash commits to the entire “receiving” transaction except for the “prevouts,” but this is an implementation detail.)

The “receiving” transaction can be considered the second half of the original transaction. It contains only one input, referring to the committed output from the “sending” transaction, and all the 12 outputs. This “receiving” transaction, with all the outputs, is therefore much larger than the “sending” transaction.

In the images below, you can see the normal batched transaction on the left, and the two separated transactions (“sending” and “receiving”) of a Secure the Bag payment on the right.

Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 3
Images taken from Jeremy Rubin’s presentation on OP_SECURETHEBAG at Scaling Bitcoin 2019
Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 3
Images taken from Jeremy Rubin’s presentation on OP_SECURETHEBAG at Scaling Bitcoin 2019

As it issues the withdrawal to its 12 customers, the exchange broadcasts both the “sending” and “receiving” transactions. But there is one big difference between the two, and this is the heart of the trick. The smaller “sending” 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.

The larger “receiving” 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’t be a big problem for the customers, because once the “sending” transaction has confirmed, it ensures that all the money is guaranteed to the “receiving” transaction. The funds are anchored in the blockchain and have nowhere else to go but to the exchange’s customers.

The money isn’t quite there yet … but the bag has been secured.

Child Pays for Parent

While the basic example as outlined above would ensure* that the exchange’s 12 customers get their funds eventually, this may not satisfy all of them quite yet.

(*In the event that transaction fees never come down to the required level, the “receiving” transaction would actually not confirm on its own; this is resolved though the same trick as explained in the remainder of this article.)

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’t suffice — no matter how sure she is that she will indeed receive it. She actually needs to be able to spend her output. 

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’s transaction will only confirm after the “receiving” transaction is also confirmed. Meanwhile her landlord is demanding a confirmed transaction today.

Luckily enough, Alice can leverage an older Bitcoin trick to ensure that both the “receiving” transaction and her own transaction confirm: “Child Pays for Parent” (CPFP). Basically, if Alice includes a high enough fee in her transaction to the landlord, miners will be incentivized to include the “receiving” transaction in a block as well — even if they don’t care for the fee on the “receiving” transaction itself. After all, they only get Alice’s high fee by confirming both.

That said, compensating for the large “receiving” transaction would be quite expensive. That’s 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’t make her a very happy customer.

Fortunately, Secure the Bag offers a better solution.

Tree Payments

To solve Alice’s problem, the exchange could take the Secure the Bag trick one step further.

In the basic example shown above, the “sending” transaction includes one committed output, while a single “receiving” transaction includes one corresponding input and 12 normal outputs. But it is possible to further split up these 12 outputs over more “receiving” transactions.

The “sending” transaction could, for example, include two committed outputs, referring to two different “receiving” transactions that each include six normal outputs. This would mean, of course, that the “sending” transaction is a bit more expensive to have confirmed fast, but Alice’s cost would be more than halved: She’d now pay for only five other customers instead of eleven.

Even better, the exchange could create “intermediate” transactions between the initial “sending” transaction and the eventual “receiving” transactions! These “intermediate” 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.

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 — but less cost per individual user. “Chained” payments are similar to Tree payments, but are more dependant on the chronology of transactions.)

Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 5
Image taken from Jeremy Rubin’s presentation on OP_SECURETHEBAG at Scaling Bitcoin 2019
Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 5
Image taken from Jeremy Rubin’s presentation on OP_SECURETHEBAG at Scaling Bitcoin 2019

Details and Deployment

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 “receiving” transaction.

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 — 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.

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 — 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 — if ever.

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 Bitcoin Improvement Proposal, the development mailing-list discussion on the topic and Rubin’s full presentation at Scaling Bitcoin 2019 in Tel Aviv:

Secure the Bag: Cutting Transactions in Half to Resolve Bitcoin Network Congestion 7
About the author

E-Crypto News was developed to assist all cryptocurrency investors in developing profitable cryptocurrency portfolios through the provision of timely and much-needed information. Investments in cryptocurrency require a level of detail, sensitivity, and accuracy that isn’t required in any other market and as such, we’ve developed our databases to help fill in information gaps.

Related Posts

E-Crypto News Executive Interviews



bitcoin
Bitcoin (BTC) $ 47,937.00
ethereum
Ethereum (ETH) $ 3,612.46
cardano
Cardano (ADA) $ 2.46
tether
Tether (USDT) $ 1.00
binance-coin
Binance Coin (BNB) $ 425.74
xrp
XRP (XRP) $ 1.10
solana
Solana (SOL) $ 156.41
polkadot
Polkadot (DOT) $ 34.96
dogecoin
Dogecoin (DOGE) $ 0.2414
usd-coin
USD Coin (USDC) $ 1.00
USD
EUR
GBP
bitcoinBitcoin (BTC)
$ 47,937.00
ethereumEthereum (ETH)
$ 3,612.46
tetherTether (USDT)
$ 1.00
bitcoin-cashBitcoin Cash (BCH)
$ 635.99
litecoinLitecoin (LTC)
$ 189.64
bitcoinBitcoin (BTC)
40.542,96
ethereumEthereum (ETH)
3.055,26
tetherTether (USDT)
0,845755
bitcoin-cashBitcoin Cash (BCH)
537,89
litecoinLitecoin (LTC)
160,39
bitcoinBitcoin (BTC)
34,551.79
ethereumEthereum (ETH)
2,603.77
tetherTether (USDT)
0.720775
bitcoin-cashBitcoin Cash (BCH)
458.41
litecoinLitecoin (LTC)
136.69

Automated trading with HaasBot Crypto Trading Bots

Crypto Scams

Crypto Scams
Crypto Scams Still Persistent In 2021, SEC Warns About Red Flags To Watch
September 9, 2021
Poly Network
Here’s How Hackers Stole Over $600 million in the Poly Network Attack
August 12, 2021
The World’s Most Infamous Crypto Hacks and Scams
July 31, 2021
Cryptocurrency Exchanges
Cryptocurrency Exchanges and the Plague of Scams and Bans
June 29, 2021
What Role Do Cryptocurrencies Play In The Era Of Ransomware Attacks?
June 9, 2021

Blockchain/Cryptocurrency Questions and Answers

Beginner’s Guide to Investing in Cryptocurrency
August 9, 2021
Short-Sell Cryptocurrency
How to Short-Sell Cryptocurrency: A Brief Overview
July 17, 2021
Klaytn
What Is Klaytn (KLAY) And How Does It Work?
July 16, 2021
Cryptocurrencies
Our Crypto Roundup Interview Asks- Do Cryptocurrencies Have a Future?
July 15, 2021
Solana
What Is Solana (SOL) And How Does It Work?
June 26, 2021


CryptoCurrencyUSDChange 1hChange 24hChange 7d
Bitcoin48,072 0.79 % 0.54 % 4.31 %
Ethereum3,619.7 0.80 % 3.30 % 3.51 %
Cardano2.450 0.79 % 4.67 % 0.98 %
Tether0.9986 0.03 % 0.08 % 0.23 %
Binance Coin426.84 0.72 % 2.03 % 3.10 %
XRP1.100 0.55 % 0.79 % 0.15 %
Solana155.69 0.50 % 3.85 % 17.78 %
Polkadot30.87 2.19 % 17.29 % 10.73 %
Dogecoin0.2417 0.61 % 1.75 % 5.81 %
USD Coin1.000 0.03 % 0.10 % 0.14 %

bitcoin
Bitcoin (BTC) $ 47,937.00
ethereum
Ethereum (ETH) $ 3,612.46
cardano
Cardano (ADA) $ 2.46
tether
Tether (USDT) $ 1.00
binance-coin
Binance Coin (BNB) $ 425.74
xrp
XRP (XRP) $ 1.10
solana
Solana (SOL) $ 156.41
polkadot
Polkadot (DOT) $ 34.96
dogecoin
Dogecoin (DOGE) $ 0.2414
usd-coin
USD Coin (USDC) $ 1.00