在 CHECKMULTISIG 的執行過程中有一個錯誤，需要稍微解決一下。當 CHECKMULTISIG 執行時，它應該消耗堆疊中的 M + N + 2 個項目作為參數。 但是，由於該錯誤，CHECKMULTISIG 會彈出額外的值或超出預期的值。

讓我們用前面的驗證示例更詳細地看一下：

首先，CHECKMULTISIG彈出頂部元素，它是 N（在本例中為＂3＂）。然後它彈出 N 個元素，這是可簽名的公鑰。在這個例子中，是公鑰 A，B 和 C 。然後，它彈出一個項目，即 M ，仲裁數（需要多少個簽名）。這裡 M = 2。此時，CHECKMULTISIG 應該彈出最後的 M 個元素，這是簽名，並查看它們是否有效。然而，不幸的是，實現中的一個錯誤會導致 CHECKMULTISIG 彈出另一個元素（ 總數為M + 1 ）。額外的項目在檢查簽名時被忽略，因此它對 CHECKMULTISIG 本身沒有直接影響。但是，必須存在額外的值，因為如果它不存在，當 CHECKMULTISIG 試圖彈出空堆疊時，它將導致堆疊錯誤和腳本失敗（將交易標記為無效）。由於額外的項目被忽略，它可以是任何東西，但通常使用 0。

由於這個bug成為了共識規則的一部分，現在必須永久複製。因此，正確的腳本驗證將如下所示：

所以，正確的解鎖腳本不是

而是:

從現在起，如果你看到一個 multisig 解鎖腳本，你應該在開始時看到一個額外的 0，其唯一目的是修正意外成為共識規則的錯誤。

P2SH功能的另一個重要部分是將腳本雜湊編碼為地址的能力，如BIP-13中所定義的那樣。P2SH地址是腳本的20字節雜湊的Base58Check編碼，就像比特幣地址是公鑰的20字節雜湊的Base58Check編碼一樣。 P2SH地址使用版本前綴＂5＂，這導致以＂3＂開頭的Base58Check編碼地址。

例如，Mohammed的複雜腳本，通過雜湊和Base58Check編碼，生成P2SH地址 39RF6JqABiHdYHkfChV6USGMe6Nsr66Gzw。我們可以用 bx 命令來確認

現在，Mohammed可以給他的客戶提供這個＂地址＂，他們幾乎可以使用任何比特幣錢包進行簡單付款，就像它是一個比特幣地址一樣。前綴3給他們一個暗示，這是一種特殊的地址類型，對應於腳本而不是公鑰，但是它的作用方式與支付比特幣地址的方式完全相同。

P2SH地址隱藏了所有的複雜性，因此付款人看不到腳本。

與在鎖定輸出時直接使用複雜腳本相比，P2SH具有以下優點：

在Bitcoin Core客戶端版本0.9.2之前，Pay-to-Script-Hash通過 IsStandard() 函數僅限於標準類型的比特幣交易腳本。這意味著消費交易中提供的贖回腳本只能是標準類型之一：P2PK，P2PKH或multisig。

從Bitcoin Cor客戶端版本0.9.2開始，P2SH交易可以包含任何有效的腳本，使P2SH標準更加靈活，並允許對許多新型和複雜類型的交易進行實驗。

你無法將P2SH放入P2SH贖回腳本中，因為P2SH規範不是遞歸的。另外，技術上可以在贖回腳本中包含 RETURN（ 參見 數據記錄輸出 (RETURN) ），規則中的任何內容都無法阻止你這樣做，但沒有實際意義，因為在驗證期間執行 RETURN 將導致交易被標記為無效。

請注意，因為贖回腳本在你嘗試使用P2SH的輸出之前未呈現給網路，所以如果你使用無效的贖回腳本的雜湊鎖定該輸出，它將被忽略。 UTXO將被成功鎖定，但你將無法花費這筆費用，包含贖回腳本的花費交易不會被接受，因為它是無效的腳本。這會產生風險，因為你可以將比特幣鎖定在以後不能使用的P2SH中。網路會接收對應於無效的贖回腳本的鎖定腳本。

從一開始，比特幣就具有交易級別的時間鎖定功能。交易鎖定時間是交易級別的設置（交易資料結構中的一個欄位），用於定義交易有效的最早時間，並且可以在網路上中轉或添加到區塊鏈。Locktime也被稱為 nLocktime ，來自Bitcoin Core程式碼庫中使用的變數名稱。在大多數交易中它被設置為0以表示立即傳播和執行。如果 nLocktime 非零且低於5億，會被解釋為為區塊高度，表示交易無效並且不會在指定區塊高度之前中轉或包含在區塊鏈中。如果它超過5億，它會被解釋為Unix紀元時間戳（自1970年1月1日以來的秒數），表示交易在指定時間之前無效。使用 nLocktime 指定未來區塊或時間的交易必須由發起的系統持有，只有在它們生效後才傳輸到比特幣網路。如果交易在指定的 nLocktime 之前傳輸到網路，交易將被第一個節點認為無效並拒絕，不會被中轉到其他節點。 nLocktime 的使用等同於推遲日期的紙質支票。

2015年12月，一種新的時間鎖形式作為軟分叉升級引入了比特幣。根據BIP-65中的規範，一種名為 CHECKLOCKTIMEVERIFY（CLTV）的腳本操作符添加到腳本語言中。 CLTV 是每個輸出的時間鎖，而不是 使用 nLocktime 情況下的每個交易的時間鎖。允許時間鎖的應用更加靈活。

簡而言之，通過在輸出的贖回腳本中添加 CLTV 操作碼，可以限制輸出只能在指定的時間過後才能使用。

CLTV 並沒有取代 nLocktime，而是限制特定UTXO，以使它們只能在 nLocktime 設置為更大或相等的值的未來交易中使用。

CLTV 操作碼將一個參數作為輸入，該參數以與 nLocktime（區塊高度或Unix紀元時間）相同的格式表示。如 VERIFY 後綴所示，CLTV 是在結果為 FALSE 時停止執行腳本的操作碼。如果結果為TRUE，則繼續執行。

為了用 CLTV 鎖定輸出，可以在創建這筆輸出的交易中，將其插入到輸出的贖回腳本中。例如，如果Alice正在向Bob的地址支付，輸出通常會包含如下所示的P2PKH腳本：

為了將其鎖定一段時間，比如從現在開始3個月，這筆交易將帶有如下的贖回腳本：

其中 <now {plus} 3 months> 是從這筆交易被開採後3個月的區塊高度或者時間戳估計，當前區塊高度 + 12,960 (區塊) 或者 當前Unix時間戳 + 7,760,000 (秒). 現在，不要在意 CHECKLOCKTIMEVERIFY 之後的 DROP 操作符，我們之後會解釋。

當Bob嘗試花費這個UTXO時，構建一個以UTXO作為輸入的交易，在輸入的解鎖腳本中使用他的簽名和公鑰，並將交易的 nLocktime 設置為等於或大於 CHECKLOCKTIMEVERIFY 中Alice設置的 timelock，然後在比特幣網路上廣播交易。

Bob的交易被進行如下的評估，如果Alice設置的 CHECKLOCKTIMEVERIFY 的參數小於或等於消費交易的 nLocktime，則腳本執行繼續（如同執行 "no operation" 或NOP操作碼一樣）。否則，腳本執行會停止，並且交易被視為無效。

更準確地說，CHECKLOCKTIMEVERIFY 失敗並暫停執行，標記交易無效，如果達成以下條件（來源：BIP-65）：

執行後，如果滿足 CLTV，則其前面的時間參數將保留為堆疊頂元素，需要使用 DROP 將其刪除，以正確執行後續腳本操作碼。出於這個原因，你經常會在腳本中看到 CHECKLOCKTIMEVERIFY 和 DROP。

通過將 nLocktime 與 CLTV 結合使用，交易鎖定時間限制 中描述的場景會發生變化。Alice不能再花費這筆資金了（因為它被Bob的密鑰鎖定），Bob在3個月的鎖定時間到期之前也不能花費。

通過將時間鎖功能直接引入腳本語言，CLTV 允許我們開發一些非常有趣的複雜腳本。

標準的定義參見 BIP-65 (CHECKLOCKTIMEVERIFY)。

nLocktime 和 CLTV 都是 絕對的時間鎖 absolute timelocks，表示一個絕對的時間點。接下來我們要研究的兩個時間鎖功能是 相對時間鎖 relative timelocks，它們指定從輸出在區塊鏈中被確認時開始的一段時間，作為花費輸出的條件。

相對時間鎖是有用的，它們允許兩個或多個相互依賴的交易組成的交易鏈進行脫鏈處理，對一個依賴於前一個交易確認後一段時間的交易施加時間限制。換句話說，直到UTXO被記錄在區塊鏈上時，時鐘才會開始計數。這個功能在雙向狀態通道（bidirectional state channels）和閃電網路（Lightning Networks）中特別有用，我們將在 [state_channels] 中看到。

相對時間鎖與絕對時間鎖一樣，都是通過交易級功能和腳本級操作碼實現的。交易級別的相對時間鎖實現為 nSequence（每個交易輸入中設置的欄位）值的共識規則。腳本級別的相對時間鎖使用 CHECKSEQUENCEVERIFY（CSV）操作碼實現。

相對時間鎖是根據 BIP-68, Relative lock-time using consensus-enforced sequence numbers 和 BIP-112, CHECKSEQUENCEVERIFY 中的規範實現的。

BIP-68和BIP-112於2016年5月作為共識規則的軟分叉升級啟用。

通過設置 nSequence 欄位，可以在交易的每個輸入上設置相對時間鎖。

與CLTV和 nLocktime 一樣，有一個在腳本中使用 nSequence 值作為相對時間鎖的腳本操作碼。該操作碼是 CHECKSEQUENCEVERIFY，通常簡稱為 CSV。

在UTXO的贖回腳本中執行時，CSV 操作碼僅允許輸入的 nSequence 值大於或等於 CSV 參數的交易。從本質上講，這限制了UTXO直到相對於UTXO開採的時間已經過去了一定數量的區塊或秒之後才能被花費。

與CLTV一樣，CSV 中的值必須與相應的 nSequence 值中的格式匹配。如果 CSV 指定的是區塊數量，nSequence 也必須是區塊數量。如果 CSV 指定的是秒，那麼 nSequence 也必須是秒。

當幾個（鏈接的）交易被創建和簽名，但保持＂脫鏈＂狀態不會傳播時，使用 CSV 的相對時間鎖特別有用。直到父交易被傳播，開採和沉澱到相對時間鎖定中指定的時間後，才能使用子交易。可以在 [state_channels] 和 [lightning_network] 中看到這個用例的應用。

CSV 在 BIP-112, CHECKSEQUENCEVERIFY 中詳細定義。

作為啟用相對時間鎖的一部分，時間鎖（絕對和相對）的＂時間＂計算方式有所變化。在比特幣中，實際時間（wall time）和共識時間（consensus time）之間存在著微妙但重要的差異。比特幣是一個去中心化的網路，這意味著每個參與者都有自己的時間視角。網路上的事件並不是每時每刻都在發生。必須在每個節點的角度考慮網路延遲。最終，所有內容都會同步,創建一個公共的賬本。與 過去 一樣，比特幣每隔10分鐘就會對賬本的狀態達成共識。

區塊頭中的時間戳是由礦工設置的。共識規則留有一定的餘地來解決分散的節點之間的時鐘精度差異。然而，這帶來了一種不幸的激勵，促使礦工在一個區塊內對時間撒謊，以便通過納入尚未成熟的時間鎖定交易來收取額外的費用。有關更多訊息，請參見下面的部分。

為了消除對撒謊的激勵，並加強時間鎖的安全性，BIP-113與關於相對時間鎖的BIP同時提出並被啟用，它定義了一個稱為 過去中位時間 Median-Time-Past 的新的一直的時間測量方法。

Median-Time-Past 過去11個區塊的時間戳並的中位數。中位時間成為共識時間，並用於所有時間鎖的計算。通過取過去大約兩個小時的中點，任何一個區塊的時間戳影響都會減小。通過結合11個區塊，沒有一個礦工可以為了獲得尚未成熟的時間鎖定交易費用而影響時間戳。

Median-Time-Past改變了 nLocktime，CLTV，nSequence 和 CSV 的時間計算實現。由Median-Time-Past計算的共識時間總是比實際時間晚大約一個小時。如果你創建時間鎖定交易，應該在估計 nLocktime，nSequence，CLTV 和 CSV 中編碼的時間時考慮這一點。

Median-Time-Past 在 BIP-113 中被定義。

費用狙擊（Fee-sniping）是一種理論上的攻擊場景，表示試圖改寫過去的區塊的礦工＂狙擊＂未來區塊中更高費用的交易，來最大化盈利的方法。

例如，假設現在的最高區塊是區塊＃100,000。一些礦工嘗試重新開採區塊 #100,000，而不是嘗試開採區塊＃100,001來增長區塊鏈。這些礦工可以選擇在他們的候選區塊＃100,000中包含任何有效的交易（尚未開採）。他們不必通過相同的交易來重新開採區塊。事實上，他們有動力選擇最有利可圖的（每KB最高費用）交易幷包含在他們的區塊中。它們可以包括任何在＂舊＂區塊＃100,000中的交易，也可以包含來自當前mempool的任何交易。本質上，當他們重新創建區塊＃100,000時，他們可以選擇將交易從＂現在＂轉移到重寫的＂過去＂。

今天，這種攻擊不是很有利可圖，因為區塊獎勵遠高於每個區塊的總費用。但是在將來，交易費用將成為獎勵的一大部分（甚至獎勵的全部）。那時候，這種情況就不可避免了。

在Bitcoin Core創建交易時，為了防止＂費用狙擊＂，會預設使用 nLocktime 將其限制為＂下一個區塊＂。在我們的場景中，Bitcoin Core會在其創建的任何交易中將 nLocktime 設置為100,001。正常情況下，這個 nLocktime 不起作用 —— 無論如何，交易只能包含在＃100001區塊中；這是下一個區塊。

但是，在區塊鏈分叉攻擊下，礦工們將無法從mempool中獲取高額交易，因為所有這些交易都會被鎖定到＃100,001區塊。他們只能使用當時有效的交易重新計算＃100,000，實質上不會獲得新的費用。

為此，Bitcoin Core將所有新交易的 nLocktime 設置為 <當前區塊＃+ 1>，並將所有輸入的 nSequence 設置為0xFFFFFFFE以啟用 nLocktime。

比特幣腳本中另外一種條件形式是以 VERIFY 結尾的任何操作碼。VERIFY 後綴表示如果所評估的條件不是 TRUE，腳本將立即終止執行，並且交易被視為無效。

與 IF 語句提供不同的執行路徑不同，VERIFY 後綴用作 守護語句 guard clause, 只有滿足前面的條件時繼續執行。

例如，以下腳本需要Bob的簽名和產生特定雜湊的原象（pre-image）（密鑰）。必須滿足這兩個條件才能解鎖：

為了贖回這筆資金, Bob 必須創建提供原象（pre-image）和簽名的解鎖腳本：

在不提供原象的情況下，Bob無法執行到檢查其簽名的腳本部分。

這個腳本可以用 IF 語句寫成:

Bob的解鎖腳本是相同的:

帶 IF 的腳本與使用 VERIFY 後綴的操作碼的功能相同；他們都作為守護語句運行。但是，VERIFY 構造更高效，使用兩個較少的操作碼。

那什麼時候使用 VERIFY，什麼時候使用 IF 呢？如果我們只是附加一個先決條件（guard clause），那麼 VERIFY 更好。但是，如果有多個執行路徑（流程控制），那麼需要使用 IF...ELSE 流程控制語句。

比特幣腳本中，流程控制的一個常見用途是構建贖回腳本，提供多個執行路徑，每種贖回方式都可以贖回UTXO。

看一個簡單的例子，有兩個簽名者，Alice和Bob，任何一個都可以兌換。使用multisig時，這將表示為 1-of-2 的多重簽名腳本。為了演示，我們使用 IF 語句做同樣的事情：

看到這個贖回腳本，你可能會想：＂條件在哪裡？在 IF 語句之前沒有任何東西啊！＂

條件不是贖回腳本的一部分。而是在解鎖腳本中提供，從而允許 Alice 和 Bob ＂選擇＂ 他們想要的執行路徑。

Alice使用以下解鎖腳本進行贖回：

最後的 1 作為條件（TRUE），使 IF 語句執行Alice簽名的第一個贖回路徑。

如果Bob要贖回，他必須通過給 IF 語句提供一個 FALSE 值來選擇第二個執行路徑：

Bob的解鎖腳本在堆疊上放置了 0，導致 IF 語句執行第二個（ ELSE ）腳本，從而需要Bob的簽名。

由於 IF 語句可以嵌套，我們可以創建執行路徑的＂迷宮＂。解鎖腳本可以提供一個選擇執行路徑實際執行的＂映射＂：

在這種情況下，有三個執行路徑（腳本A，腳本B 和 腳本C）。解鎖腳本以 TRUE 或 FALSE 值的順序提供路徑。例如，要選擇路徑 腳本B，解鎖腳本必須以 1 0（ TRUE，FALSE ）結尾。這些值將被壓入堆疊，以便第二個值（ FALSE ）作為堆疊頂部。外層的 IF 語句彈出 FALSE 並執行第一個 ELSE 語句。然後 TRUE 移動到堆疊頂，並由內部的（嵌套的）IF 判斷，從而選擇 B 執行路徑。

使用這種構造，我們可以用數十或數百個執行路徑構贖回腳本，每個腳本都提供了一種不同的方式來贖回UTXO。為了花費UTXO，我們構建一個解鎖腳本，通過在每個流程控制點的堆疊上放置相應的 TRUE 和 FALSE 來選擇執行路徑。

隔離見證是一種體系結構變化，它對比特幣的可擴展性，安全性，經濟效益和性能有以下影響：

隔離見證看起來改變了交易如何構建，是交易層面的特性，但事實並非如此。相反，隔離見證是對如何花費單個UTXO的改變，因此是每個輸出層面的特性。

交易可以花費隔離見證的輸出或傳統（內聯見證）的輸出，或同時花費兩者。因此，將交易稱為＂隔離見證交易＂沒有什麼意義。我們應該將具體的交易輸出稱為＂隔離見證輸出＂。

當交易花費UTXO時，它必須提供見證。在傳統的UTXO中，鎖定腳本要求在花費UTXO的交易的輸入部分提供 在線的 見證數據。然而，隔離見證UTXO指定了一個鎖定腳本，它可以被輸入之外的（隔離的）見證數據滿足。

隔離見證是輸出和交易架構方式的重大變化。這種改變通常需要每個比特幣節點和錢包同時改變以升級共識規則 —— 所謂的硬分叉。然而，隔離見證的引入具有較少的破壞性變化，是向後兼容的，被稱為軟分叉。這種類型的升級允許非升級軟體忽略更改並繼續運行而不會中斷。

隔離見證構建的輸出，使不能識別"見證"的舊系統仍然可以驗證它們。對於舊的錢包或節點，隔離見證輸出看起來像是任何人都可以花費的輸出。這樣的輸出可以用一個空的簽名來花費，交易內部沒有簽名（隔離的）並不會使交易失效。然而，較新的錢包和挖礦節點會看到隔離見證輸出，並期望在交易的見證數據中找到有效的見證。

讓我們來看一些示例交易，看它們將如何隨著隔離見證改變。首先看一下如何使用隔離見證程序來轉換Pay-to-Public-Key-Hash（P2PKH）。然後，看一下Pay-to-Script-Hash（P2SH）腳本的隔離見證等價物。最後，我們將看看如何將之前的隔離見證程序嵌入到P2SH腳本中。

從前面的例子可以看出，升級為隔離見證是一個兩步的過程。首先，錢包必須創建特殊的隔離型輸出。然後，這些輸出可以被知道如何構建隔離見證交易的錢包花費。在這些例子中，Alice的錢包支持segwit，能夠使用Segregated Witness腳本創建特殊輸出。 Bob 的錢包也是支持segwit的，能夠花費那些輸出。從這個例子中可能不明顯的是，在實踐中，Alice的錢包需要知道Bob使用了一個支持segwit的錢包並可以使用這些輸出。否則，如果Bob的錢包沒有升級，當Alice試圖向Bob進行segwit支付，那麼Bob的錢包將無法檢測到這些支付。

隔離見證不會在整個網路中同時實施。而是向後兼容的升級，新老客戶可以共存。錢包開發人員將獨立升級錢包軟體以添加隔離見證功能。當付款人和收款人都支持隔離見證時，可以使用P2WPKH和P2WSH付款類型。傳統的P2PKH和P2SH將繼續為沒有升級的錢包工作。這留下了兩個重要的場景，下一節將討論這些：

隔離見證修改了四種簽名驗證函數（CHECKSIG，CHECKSIGVERIFY，CHECKMULTISIG 和 CHECKMULTISIGVERIFY）的語義，改變了交易保證雜湊的計算方式。

比特幣交易中的簽名應用於commitment hash，這是根據交易數據計算的，鎖定數據的特定部分，表明簽名者對這些值的保證。例如，在簡單的 SIGHASH_ALL 類型簽名中，保證雜湊包括所有輸入和輸出。

不幸的是，計算保證雜湊的方式引入了驗證簽名的節點可能被迫執行大量雜湊計算的可能性。具體而言，雜湊操作相對於交易中的簽名操作的數量以 O(n²) 的複雜度增長。因此，攻擊者可以創建帶有大量簽名操作的交易，導致整個比特幣網路必須執行數百或數千次雜湊操作才能驗證交易。

Segwit提供了通過改變保證雜湊計算方式來解決這個問題的機會。對於segwit版本0見證程序，使用BIP-143中規定的改進的保證雜湊演算法進行簽名驗證。

新演算法實現了兩個重要目標。首先，雜湊操作的數量隨著簽名操作的數量逐漸以 O(n) 增長，減少了用過於複雜的交易創建拒絕服務攻擊的機會。其次，保證雜湊現在還將每個輸入的值（金額）作為雜湊的一部分，這意味著簽名者無需＂獲取＂並檢查輸入引用的前一個交易就可以保證特定的輸入值。對於離線設備（例如硬體錢包），這大大簡化了主機與硬體錢包之間的通信，消除了對以前的交易進行驗證的需要。硬體錢包可以接受不受信任的主機＂所聲明的＂輸入值，因為如果輸入值不正確則簽名無效，硬體錢包在簽名輸入前不需要驗證該值。

比特幣挖礦節點和完整節點會產生用於支持比特幣網路和區塊鏈的資源的成本。隨著比特幣交易量的增加，資源成本（CPU，網路頻寬，硬碟空間，內存）也不斷增加。礦工通過收取與每次交易的大小（位元組）成比例的費用來補償這些成本。非挖礦（Nonmining）完整節點沒有得到補償，蒙受了損失，因為他們需要運行一個權威的完全驗證的全索引節點，可能是因為他們使用節點來經營比特幣業務。

如果沒有交易費用，比特幣數據的增長可能會大幅增加。費用旨在通過基於市場的價格發現機制，將比特幣用戶的需求與交易對網路帶來的負擔相匹配。

基於交易規模的費用計算將交易中的所有數據視為成本相同的。但是從完整節點和礦工的角度來看，交易的某些部分承擔了更高的成本。添加到比特幣網路的每筆交易都會影響節點上四種資源的消耗：

從列表中可以看出，並非交易的每個部分都對運行節點的成本或比特幣支持更多交易的能力產生同等影響。交易中最昂貴的部分是新創建的輸出，因為它們被添加到內存中的UTXO集合中。相比之下，簽名（又名見證數據）為增加了最小的網路負擔和節點運行成本，因為見證數據只被驗證一次，然後再也不會使用。此外，在收到新的交易並驗證見證數據之後，節點立即丟棄該見證數據。如果費用是根據交易規模計算的，而不區分這兩種數據，那麼市場化的費用激勵就不符合交易實際施加的成本。實際上，目前的費用結構實際上鼓勵了相反的行為，因為見證數據是交易的最大部分。

交易在其輸入中花費UTXO，並在輸出中創建新的UTXO。因此，一個輸入數量大於輸出數量的交易將導致UTXO集的減少，而一個輸出數量大於輸入數量的交易將導致UTXO集的增加。讓我們考慮輸入和輸出之間的差異，並稱之為"淨增UTXO"（"Net-new-UTXO"）。這是一個重要的指標，因為它告訴我們一個交易將對網路中最昂貴的資源(即內存裡的UTXO集)產生什麼影響。Net-new-UTXO為正的交易增加負擔，Net-new-UTXO為負的交易減少負擔。因此，我們希望鼓勵Net-new-UTXO為負或為0的交易。

讓我們看一個例子，說明在有無隔離見證的情況下，交易費用計算產生了哪些激勵。我們將看兩個不同的交易。交易A是有3個輸入2個輸出的交易，Net-new-UTXO為-1。交易B是2個輸入3個輸出的交易，Net-new-UTXO為1，意味著它增加了一個UTXO到UTXO集，給整個比特幣網路帶來了額外的成本。這兩筆交易都使用多重簽名（2-of-3）腳本來說明覆雜腳本如何增加隔離見證對費用的影響。假設交易費為每位元組30 satoshi，見證數據擁有75％的費用折扣：

這兩種交易在實施隔離見證時都較為便宜。但是比較這兩筆交易的成本，我們發現在隔離見證之前，Net-new-UTXO為負的交易費用較高。在隔離見證後，交易費用與鼓勵減少新的UTXO產生的激勵相一致，不會無意地懲罰有許多輸入的交易。

因此，隔離見證對比特幣用戶支付的費用有兩個主要影響。首先，segwit通過見證數據折扣，和增加比特幣區塊鏈的能力，來降低交易的總體成本。其次，segwit對見證數據的折扣糾正了可能無意中導致UTXO集合中更加膨脹的激勵錯配。