比特幣的網絡擁塞情況千差萬別。在幾天的幾個小時中，成千上萬的交易正等待被包含在一個區塊中，從而導致費用飆升并使許多用戶等待。同時，在較慢的時間內，甚至沒有足夠的交易來填補所有障礙，而且最小的費用就足以快速確認。

對于需要快速進行大量事務的服務，高峰時段的網絡擁塞當然是一個大問題。例如，交易所，挖礦池或薪資服務有時會同時向數百名用戶付款-這些用戶可能不耐煩地想拿錢。因此，這些服務需要支付高額費用，從而使比特幣網絡上的所有其他交易重回隊列。

現在，比特幣核心貢獻者杰里米·魯賓（Jeremy Rubin）認為，他已經找到了如何可靠地緩解網絡擁塞的方法，從而提高了高峰時段比特幣的吞吐量。

他的建議稱為OP_SECURETHEBAG。

固定袋子

要了解OP_SECURETHEBAG（從現在開始，我們將其簡稱為“保護袋子”），我們舉一個實際的例子并從基礎開始。在此示例中，有12個客戶都要求交易所在收取高額費用的同時發出提款。 （實際上，這可能很容易成為1200個客戶，但只有12個客戶，這個概念更容易解釋。）

即使沒有安全袋，交易所也是明智的，并且不會創建12個單獨的交易來分別向每個客戶付款。相反，為了節省費用，它創建了一個“批處理”交易，該交易更為緊湊。交易包括三個輸入（指“發件人”地址，所有三個都屬于交易所）和12個輸出（包括“發件人”地址，屬于不同的客戶）。在此示例中，金額相加很好，因此沒有更改地址。

在下面的圖像中，交易看起來像右邊的交易A-不像左邊所示的12個單獨交易。

圖片來自Jeremy Rubin在Scaling Bitcoin 2019上的OP_SECURETHEBAG演示文稿中拍攝

由于批處理事務包含如此多的輸出（每個客戶一個），因此在數據方面非常大。事務越大，將其包含在塊中的成本越高。而且在高峰時段，交易所要迅速確認交易會非常昂貴。 （雖然不像12個單獨的交易那樣昂貴，但是仍然很昂貴。）

現在，交易所可以改為收取較低的費用，在這種情況下，確認交易只需要一段時間。但是在確認之前，客戶將一直在等待他們的錢，不確定他們是否真的會收到這筆錢：這筆錢可能會被雙花，直到將交易包括在其中。這使客戶不滿意，而交易平臺則不希望如此。 （在某些情況下，甚至可能無法讓客戶等待：例如，根據合約，薪資服務可能有義務在特定的一天確認交易。）

這是“安全袋”進來的地方。

安全袋是提議的“ OpCode”：對比特幣編程語言的補充。該操作碼實質上將使交易所將其批量交易“拆分”為兩個交易：“發送”交易和“接收”交易。

其中第一個（“發送”交易）包括三個原始輸入，指的是交易所擁有的地址。但它僅包含一個特殊輸出。此輸出稱為“提交的輸出”，其中包含一個特殊的加密貨幣哈希：看似隨機但相對較短的數字字符串。

該哈希實質上是一個唯一的序列號，將其鏈接到兩個事務中的另一個：“接收”事務。確保袋子安全的關鍵，可以使用已承諾的輸出的唯一方法是通過此特定的“接收”事務，并通過哈希將其鏈接到該事務。 （用技術術語來說，哈希將提交給除“ prevouts”之外的整個“接收”事務，但這是一個實現細節。）

那么，“收款”交易可以視為原始交易的后半部分。它僅包含一個輸入（指“發送”事務中的已提交輸出）以及所有12個輸出。因此，帶有所有輸出的“接收”交易要比“發送”交易大得多。

在下面的圖像中，你可以在左側看到正常的批量交易，而在右側則看到安全袋付款的兩個分開的交易（“發送”和“接收”）。

圖片來自Jeremy Rubin在Scaling Bitcoin 2019上的OP_SECURETHEBAG演示文稿中拍攝

當它向其12個客戶發出提款時，交易所同時廣播“發送”和“接收”交易。但這兩者之間有一個很大的區別，這就是訣竅的核心。較小的“發送”交易包括相對較大的費用，以確保快速確認。由于該交易很小，從數據角度來說，即使是相對較大的費用也是可以管理的。相比之下，較大的“接收”交易包含的費用要低得多，這意味著交易所可能需要一段時間才能確認。

相比之下，較大的“收款”交易所包含的費用要低得多，這意味著確認可能需要一段時間。但是這一次，等待低價交易確認對客戶來說不是大問題，因為一旦“發送”交易被確認，就可以確保所有的錢都可以保證“接收”??交易。資金錨固在區塊鏈中，除了交易所的客戶之外別無其他。

錢還沒有到位……但是手提包已經放好了。

孩子為父母付費

盡管上面概述的基本示例可以確保*交易所的12個客戶最終獲得他們的資金，但這可能還不能完全滿足他們的所有要求。

（*如果交易費用從未降到所需水平，則“收款”交易實際上不會自行確認；這可以通過相同的技巧來解決，如本文其余部分所述。）

舉例來說，12個客戶之一的愛麗絲必須今天向房東付款。因此，僅僅知道她最終會收到她的錢是不夠的-不管她有多確定自己確實會收到這筆錢。她實際上需要能夠花費她的輸出。

從技術上講這是可能的。愛麗絲可以將未經確認的輸出（12個之一）輸出，并立即用于新交易中。唯一的問題：愛麗絲的交易只有在確認“收款”交易后才能確認。同時，她的房東要求今天進行確認交易。

幸運的是，愛麗絲可以利用舊的比特幣技巧來確保“收款”交易和她自己的交易都可以確認：“孩子為父母付款”（CPFP）。基本上，如果愛麗絲在向房東的交易中包含足夠高的費用，則礦機也將被激勵將大筆“收貨”交易也包括在內-即使他們不關心“收貨”交易本身的費用。畢竟，只有同時確認兩者，他們才能獲得愛麗絲的高額費用。

也就是說，補償大型“收貨”交易將是非常昂貴的。這就是交易所最初使用“安全袋”的原因。現在，Alice無需為交易所而向所有12個客戶支付批量交易的費用。這不會使她成為一個非常滿意的客戶。

幸運的是，安全袋提供了更好的解決方案。

樹木付款

為了解決愛麗絲的問題，交易所可以進一步采取“安全袋”技巧。

在上面顯示的基本示例中，“發送”交易包括一個“安全袋”輸出，而單個“接收”交易包括一個相應的“安全袋”輸入和12個正常輸出。但是可以將這12個輸出進一步拆分為更多的“接收”交易。

例如，“發送”交易可以包括兩個“安全袋”輸出，指的是兩個不同的“接收”交易，每個交易都包括六個正常輸出。當然，這意味著要進行快速確認，“發送”交易要貴一些，但是愛麗絲的費用將減少一半以上：她現在只為五個其他客戶付款，而不是十一個。

更好的是，交易所可以在初始的“發送”交易和最終的“接收”交易之間創建“中間”交易這些“中間”事務都將包括一個“安全袋”輸入和一個或多個“安全袋”輸出以及可能的正常輸出，從而創建樹結構。這樣，即使對于需要立即花費資金的客戶，交易所也可以合理地降低CPFP成本。趕時間的客戶最多需要為與他們相關的中間交易付款，而忽略其余交易。

如下圖所示，交易所可以根據自己的需求選擇最適合自己的方式來創建這種樹。 （更多的中間步驟通常需要在區塊鏈上確認更多的總交易數據，但每位用戶的成本較低。“鏈式”付款類似于樹式付款，但更多地取決于交易的時間順序。）

圖片摘自Jeremy Rubin在Scaling Bitcoin 2019上關于OP_SECURETHEBAG的演講

詳細信息和部署

本文介紹了安全袋的相當基本的實現。實際上，該提案可以各種方式實施和利用。例如，她不必使用CPFP才能向房東付款，而是可以將資金接收到Lightning渠道，并立即能夠通過這些渠道向房東付款。還有其他更復雜的解決方案可以加快“接收”交易的速度。

同樣，嚴格地說，建議的“安全袋操作碼”不是實現兩階段支付解決方案的唯一方法。即使使用當前的比特幣協議，也可以實現類似的目的-但它要求所有接收者進行協調與合作，在交易所及其客戶的例子中這種可能性很小，而且隨著更多用戶加入，這種情況將變得更加困難。其他解決方案（例如契約）將需要升級比特幣協議。

固定袋子也需要通過向后兼容的軟分叉來升級協議。魯賓已經完成了所需的大多數編碼工作-盡管代碼和構想仍需接受審查。此外，即使提案通過了所有同行評審，協議升級也可能需要一段時間才能被采用。因此，目前尚無法確定“安全袋”何時將在比特幣上發布（如果有的話）。

感謝Jeremy Rubin的信息和反饋。有關安全袋的更多信息，仿真數據和其他各種用例，請參閱相關的比特幣改進提案，有關該主題的開發郵件列表討論以及魯賓在特拉維夫的Scaling Bitcoin 2019上的完整演講：

《安全囊：將交易減少一半以解決比特幣網絡擁塞》一文首先出現在《比特幣雜志》上。

—-