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.
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.
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 special 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, then, 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.
As it issues the withdrawal to its 12 customers, the exchange broadcasts both the “sending” and “receiving” transactions. But there is one big difference…