《區塊鍊開發指南》一一1.5 合約應用案例

本節書摘來自華章計算機《區塊鍊開發指南》一書中的第1章，第1.5節,作者：申屠青春　主編 宋　波　張　鵬　汪曉明　季宙棟　左川民　編著更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

1.4節的腳本系統，詳細說明了腳本的運作原理，本節将描述在實際應用場景中如何使用腳本系統建構合約應用。

1.5.1　合約應用原理

每個比特币交易都有一個或多個輸入和輸出，每個輸入或輸出都有一個小的純函數與之相關聯，稱為腳本，腳本可包含簡化形式交易的簽名。

每個交易都有一個鎖定時間，使得該交易處于特定狀态并且可被新交易替換，直至鎖定時間來臨。預定時間可以是塊索引或時間戳（這兩個因素使用同一個記憶體項，小于5億是塊索引，大于5億是時間戳）。當一個交易的鎖定時間到了，則稱之為終結。

每個交易的輸入都有一個序列号，對于正常發送币的交易，該序列号為unit_max，鎖定時間為0。如果鎖定時間還未達到，但所有的序列号為unit_max，則該交易也被認為是終結。序列号用來釋出交易的新版本，無須驗證其他輸入的簽名。例如：在一個交易中，每個輸入都來自于不同的一方，每個輸入的序列号都是0，這些序列号可以獨立增加。

簽名驗證是很靈活的，因為交易的簽名方式可以通過sighash符号來控制，該符号附加在簽名後面。通過這種方式能夠建構特殊的合約，交易的每個輸入方隻對交易的一部分進行簽名，因而每個輸入方都能夠單方面改變該交易的一部分内容，而無需其他輸入方的參與。sighash符号分為兩部分，一種模式和一個anyonecanpay訓示器。簽名模式包含如下幾種模式。

sighash_all：這是預設模式。它訓示一個交易除輸入腳本之外，所有部分都被簽名。對輸入腳本進行簽名顯然是不可能的，那樣将無法建構一個交易，是以腳本總是不被簽名。盡管如此，需要注意的是，輸入的其他屬性如輸出、序列号等都會被簽名。直覺地說，它的意思是“如果每個人都把他們的錢放進去，并且輸出的正是我想要的，那麼我也同意把我的錢放進去。”

sighash_none：輸出沒有被簽名，可以是任何内容。使用這種模式意味着“如果每個人都把他們的錢放進去，我也同意把我的錢放進去，但我不關心輸出的是什麼。”這種模式使得其他輸入方可以通過改變輸入序列号來更新交易。

sighash_single：與sighash_none一樣，輸入被簽名，但序列号沒有被簽名。因而其他人可以建立交易的新版本，然而，唯一的輸出也要被簽名。該模式說明“如果輸出的正是我想要的，那麼我同意把錢放進去，但我不關心其他人的輸入。”

anyonecanpay訓示器可以與以上三種模式聯合使用，當設定了anyonecanpay時，僅僅是該輸入被簽名，其他輸入可以是任意内容。

腳本可以包括checkmultisig操作碼，該操作碼提供了n-of-m的簽名驗證，即：你可以提供多個公鑰m，定義必須出現的有效簽名個數n，簽名個數n可以小于公鑰數量m。如果我們設定以下腳本，則一個輸出需要兩個簽名：

22checkmultisigverify

有如下兩種通用的方式可用來安全地建立合約。

在p2p網絡之外傳遞部分完成或無效的交易。

使用兩個交易：建立一個交易（合約交易），先簽名但不會馬上廣播，在達成合約并且被鎖定在記憶體中之後，廣播另一個交易（支付交易），最後再廣播合約。

采用以上的方式即可保證人們能夠知道他們達成的合約内容。這些特性可以讓我們在區塊鍊的基礎上建立有趣的、創新的金融手段。

1.5.2　示例1：提供押金證明

想象一下，你在一個網站（論壇或wiki）上注冊了一個賬号，現在你希望在網站營運者處建立你的信用，但是你沒有以前的名譽來支撐你的信用。一個解決方案就是向網站付點錢購買信用，但是如果你關閉了賬号，可能會想要回這部分錢。你對該網站的信任程度不足以讓你将錢存到該網站，因為你擔心網站會花掉你的錢。另一個風險是，某一天該網站有可能會消失。

建立信用度的目的是你做出某種奉獻，讓網站知道你不是一個垃圾機器人。但是你不想讓網站花掉你的錢。如果網站營運者消失了，你最終想把錢要回來，而無需他們的任何許可。

對于該問題，可以通過合約來解決，具體步驟如下。

1）使用者和網站互相發送各自新生成的公鑰。

2）使用者建立交易tx1（支付交易），該交易支出10個btc到網站位址，使用者建立了tx1但不廣播。

3）使用者把tx1交易的hash值發送給網站。

4）網站使用tx1的hash值建立交易tx2（合約），tx2花掉tx1的錢并且支付到使用者位址。注意，tx2需要雙方簽名，因而該交易并不完整，nlocktime被設定成未來時間（比如六個月之後），輸入的序列号為0。

5）最終，這個不完整的交易tx2（一半已簽名）被回送給使用者，使用者檢查合約是否如預期的一樣在執行，即六個月後10btc最終會回到他的位址（除非情況有變）。序列号為0，表示如果雙方同意，則合約可以被修訂。現在，該交易的輸入腳本還不完整，因為使用者未簽名，是以要等使用者對合約進行簽名并且把簽名放到合适的位置上。

6）使用者先廣播tx1，再廣播tx2。

在這個階段，使用者和網站都不能單獨得到10btc。六個月之後，合約完成，即使網站消失了，使用者也能得到币。

如果使用者想要提早關閉賬号，又該怎麼處理呢？網站建立新版的tx2，nlocktime設為0，并且輸入的序列号設為uint＿max，重新簽名，把該交易發回使用者，使用者簽名後廣播該交易，就能提早結束合約并且釋放10btc。

如果六個月快到了，而使用者還想保留他的賬号，又該怎麼辦呢？類似的事情發生後，合約會使用新的nlocktime，序列号比以前的序列号大1，雙方重新簽名，廣播232次。當然，無論發生什麼，雙方都必須同意，才能真正改變合約。

顯然，如果該使用者被證明是存在惡意行為的（例如：垃圾郵件發送者），那麼網站不會同意提早結束合約。如果使用者有太多的濫用行為，則網站可以要求增加存款數量，或者要求延長合約時間。

1.5.3　示例2：擔保和争端調解

一個買家想和他不認識或不信任的某人進行交易，一般情況下若交易能夠正常進行時，買家不想任何第三方參與。但是當交易出現問題時，他想有一個第三方——也許是一個專業的争端調解服務來決定誰能拿到錢。

這個概念同時适用于買家和賣家。例如，調解員可向商家要求郵資證明，以判斷是否發貨。

換句話說，某人想鎖定某些币時，這些币要在第三方同意的情況下，才能被花掉。

該示例的實作步驟具體如下。

1）和商家一起引入一個調解員（如：clearcoin）。

2）得到商家的公鑰k1，得到調解員的公鑰k2，建立自己的公鑰k3。

3）把k2發給商家，商家生成一個随機數挑戰調解員，調解員用k2的私鑰簽名，用來證明k2确實屬于調解員。

4）建立一個交易tx1，使用如下輸出腳本并且廣播該交易。

23checkmultisigverify

現在這些币被鎖定了，如果要解鎖這些币，需要使用以下幾種方式。

客戶和商家同意（無論是成功的交易，還是在沒有調解的情況下商家同意回退給客戶）。

客戶和調解者同意（失敗的交易，調解者認同客戶，客戶得到退款）。

調解者和商家同意（商品已經發送，盡管有争議，商家還是得到币）。

輸入簽名時，内容被設為相關聯的輸出。這樣，為了從這個交易中得到币，客戶要建立包含兩個簽名位的腳本，自己簽一個，再把未完成的交易發給商家或調解員，請求第二個簽名。

1.5.4　示例3：保證合約

保證合約是建造公衆商品時的集資辦法，公衆商品是指一旦建成，任何人都可以免費享受到好處的商品。标準的例子是燈塔，所有人都認同應該建造一個，但是對于航海者個人來說燈塔太貴了，而且燈塔不隻是他一個人用得着，同時也會友善其他的航海者。

一個解決方案就是向所有人集資，隻有當籌集的資金超過所需的建造成本時，每個人才真正付錢；如果集資款不足，則誰都不用付錢。

在保證合約集資方面，包括頻繁的、小額的、經常自動進行的集資，例如網際網路電台的資金和網頁翻譯等，比特币要優于傳統的支付方式。假設有一個浏覽器的插件可供你發送一點币，它能檢測目前頁面的語言并且廣播一個集資請求，用于把該頁面翻譯成你的語言。如果使用該插件的許多使用者同時檢視該頁面（例如：該頁面從高流量的網站連結過來），那麼足夠的集資請求就能廣播出去，到達一定的金額時，可自動付錢給一個高品質的翻譯公司，當翻譯完成後該頁面将自動在你的浏覽器中加載。

我們能以比特币的方式建立以下模型，具體步驟如下。

1）主辦方建立新的捐贈位址，宣布如果籌集資金超過1000btc，則将建造該商品，任何人都可以捐贈。

2）捐贈者建立一個新交易，把一定數量的錢打到集資位址上，但是他們并不廣播該交易。該交易與正常的交易相似，但有三個不同點：首先，不能做任何改變，如果你沒有正确的輸出金額1000btc，那麼你必須先建立一個；第二，輸入腳本要以sighash_all|sighash_anyonecanpay的模式簽名；最後，輸出值是1000btc，注意，這不是一個有效的交易，因為輸出值比輸入值大得多。

3）把交易上傳到主辦方的伺服器上，他們把交易儲存到磁盤上，随時更新捐贈的币數量。

4）一旦伺服器獲得了足夠的币，它将把所有捐贈者上傳的獨立交易合并成一個新的交易，該交易隻有一個輸出，僅僅是把錢付到捐贈位址，該輸出與每個捐贈者的交易的輸出部分相同，而輸入部分則是所有捐贈者輸入的集合。

5）廣播完整的交易，發送捐贈的币到捐贈位址中。

這樣的場景依靠了協定的幾個方面，首先使用了sighash符号，sighash_all是預設模式，意味着要簽名所有交易的内容，除了輸入腳本。sighash_anyonecanpay是附加的訓示器，意味着簽名僅覆寫自己的輸入部分，而不會覆寫其他人的輸入，這樣一來，其他人的輸入可以留白。使用這些符号，我們能建立這樣一個簽名，即使在添加進其他輸入之後，該簽名依舊是有效的。但如果輸出内容或其他的交易部分被改變了，那麼該簽名就會無效了。第二，輸入值小于輸出值的交易是無效的（原因很明顯），這也就意味着捐贈者把發送币的交易發送給主辦方是安全的，因為主辦方不可能得到這些捐贈币，除非再加上其他的輸入值等于或超過輸出值。

不使用sighash_anyonecanpay訓示器也可以建立保證合約。不需捐贈者建立交易的集資方式有兩個步驟，一旦達到集資的總金額，主辦方就會建立包含所有捐贈者輸入的交易，然後依次在捐贈者中傳遞，每個捐贈者都對該交易進行簽名。但是，先使用sighash_anyonecanpay訓示器，然後合并交易，這樣可能會更友善一些。

保證合約可以保證下一個塊的資金網絡安全，通過這種方式，即使一個塊中的交易數量比較少，挖礦也能掙錢（因為保證合約的交易一般占用空間較大，因而需要付出更多的網絡轉賬費）。

tabarrok在他的論文“the private provision of public goods via dominant assurance contracts”中詳盡地描述了保證合約的概念，在一個通用的保證合約中，如果合約失敗了（在預定時間内集資不足），主辦方會給捐贈者支付網絡轉賬費，這種類型的合約旨在鼓勵捐贈者積極參與。

1.5.5　示例4：使用外部狀态

腳本被設計成純函數，它們不能通路外部伺服器，也不能導入任何會改變的外部狀态，因為攻擊者會利用該特性突破區塊鍊。而且，腳本語言的功能被嚴格限制了。幸運的是，我們可以以其他的方式建立交易，進而與外部世界相聯系。

考慮一個例子，老人想讓他的孫子繼承遺産，繼承時間是在他死後，或者在孫子年滿18歲時，無論先滿足哪個條件，他的孫子都可以得到遺産。

為了解決這個問題，老人首先向他自己發送孫子要繼承的資産數量，以便有一個正确的繼承數量的唯一輸出；接着，他建立了一個帶有鎖定時間的交易，該交易的意思是：在孫子18歲生日時，把币支付到孫子的位址中，老人對該交易簽名，不進行廣播，直接把該交易給了孫子。當過了孫子的18歲生日之後，孫子廣播了這個交易并且得到他的币。孫子可以在這個時間之前廣播該交易，但他不會提前得到币，有些節點會在記憶體池中把這種交易丢棄掉，因為鎖定時間在遙遠的将來。

死亡條件則很難判斷，因為比特币節點不會檢測主觀條件，我們必須依靠預言，預言是指具有密鑰對的伺服器，當使用者自定義的表達式被證明是真的，它就能按照要求對交易進行簽名。

以下是例子，老人建立了一個交易花掉了他的币，把輸出設為：

op_drop2checkmultisig

這是一個預言腳本，具有與衆不同的形式——它把資料推到堆棧中，然後立即删除。公鑰釋出在預言伺服器的網站上，為公衆所知，hash值設為使用者自定義表達式的hash值，該表達式以預言伺服器能夠了解的方式進行編寫，以确認老人已經死亡。舉個例子，可能是以下字元串的hash值：

以上語言是假設的，由預言伺服器定義該語言，其可能是任何一種語言。傳回值是一個輸出：币數量和孫子的位址。

再一次，老人建立了一個交易，沒有廣播而是直接給了孫子，他另外還提供了一個表達式和預言伺服器的名字，hash值被寫入交易，預言伺服器則能解鎖表達式。算法的具體實作如下。

1）預言伺服器接受評估請求，請求包括了使用者提供的使用者自定義表達式、輸出腳本和部分完成的交易，交易中除了scriptsig簽名之外，其他部分都已經完成，簽名僅包括了孫子的簽名，還不足以解鎖輸出。

2）預言伺服器檢查表達式，得到其hash值，并且與交易中的hash值對照，如果兩者不一緻，則傳回錯誤。

3）預言伺服器評估表達式，如果表達式的結果不是交易輸出的目标位址，則傳回錯誤。

4）預言伺服器簽名交易，傳回簽名給使用者。

對一個比特币交易進行簽名時，輸入腳本被設為相關聯的輸出腳本。原因是當op_checksig操作起作用時，包含該操作碼的腳本被放到輸入中，腳本并不包含簽名本身。預言伺服器并不知道完整的輸出，也沒有必要知道，因為它知道輸出腳本、自己的公鑰和表達式的hash值，這就足以使它檢查輸出腳本并且完成交易。

5）使用者接受新簽名，插入到交易的scriptsig項中，廣播交易。

當且僅當預言伺服器認為老人死了，孫子才能廣播兩個交易（合約和申報），并且得到币。

預言伺服器可以評估任何事情，然而區塊鍊中的輸出腳本的形式總是一樣的，可考慮以下的可能性。

給定一個日期，假定mtgox比特币的美元價格在12.5～13.5之間：

打賭我會做一些我從來不會做的事情（比如，獲得奧林匹克金牌）：

歐洲電視台的歌唱比賽，選擇兩個優勝者之一進行打賭：

這些條件可使預言伺服器的簽名變得任意複雜，但是區塊鍊僅需要包含一個hash值即可。

1.?信任最小化：挑戰

有許多方法可以降低對預言伺服器的信任程度。

回到我們的第一個例子，預言伺服器還沒有看到孫子想解鎖的交易，因為該交易從沒被廣播過。這樣，它不會支援孫子贖回币，因為它不知道該交易是否存在。我們能做到，并且也應該做到，以自動方式定期挑戰預言伺服器，確定它總是按照我們想象的方式進行輸出。挑戰無須花費任何币，因為要簽名的交易是無效的（例如：與一個并不存在的交易進行關聯），預言伺服器沒法知道簽名請求是随意的還是真實的，如何以一個尚未成真的條件來挑戰預言伺服器，是一個開放的研究課題。

2.?信任最小化：多個獨立預言伺服器

如果需要，checkmultisig中的簽名個數n可以增加至能夠達到n-of-m的預言伺服器模式（即m個預言伺服器中需要有n個預言伺服器簽名才能使交易有效）。當然，檢查預言伺服器是獨立的而非串通的，這一點也是很重要的。

3.?信任最小化：可信的硬體

使用合适的硬體，即可進行信任計算。比如，以inteltxt或amd等硬體來建立一個封閉的運作環境，然後用tpm晶片向第三方證明其可信度。第三方可判定硬體是否處于所需狀态。如果硬體失敗，則需要有人介入cpu程式的執行過程，甚至在極端的情況下，記憶體總線沒有資料流過（如果程式足夠小，則完全可以使用緩存來運作程式）。

4.?信任最小化：亞馬遜aws預言伺服器

最終，也許是目前最現實的方法就是使用亞馬遜的網頁服務，截至2013年11月，最合适的預言伺服器的解決方案是“this recipe for creating a trusted computing environment using aws”，該方案基于“this project for doing selective ssl logging and decryption”。基本思想是：預言伺服器使用亞馬遜作為其信任根，并且能用亞馬遜api證明其是值得信任的，該預言伺服器記錄線上銀行接口的加密ssl會話，如果以後産生交易争端，那麼會話記錄将被解密，争端就可以得到解決。

1.5.6　示例5：跨鍊交易

比特币技術可以用來建立多個獨立的貨币，與比特币實作理念相同的山寨币，可以在有限信任的條件下與比特币進行自由交易。域名币（namecoin）就是一個例子，它與比特币的運作規則有些不同，它可以在域名空間中租用域名。

舉個例子，想象一個财團發行了歐元币（eurcoins），即一種以财團的銀行存款1:1支援的加密貨币。這樣的貨币與比特币存在不同的交易集：更中心化，但沒有外彙風險。人們可能希望在比特币與歐元币之間來回交易，為了實作這個想法，可以使用tiernolan提出的協定。實作步驟具體如下。

1）a産生一些随機資料x（秘密）。

2）a産生tx1交易（支付）包含了帶跨鍊交易腳本的輸出。它允許币以a和b共同簽名的方式釋放，也可以以私密x和b簽名的方式釋放，該交易未廣播，塊鍊的釋放腳本包含了私密的hash值，并非真正的私密x本身。

3）a産生tx2（合約），花掉tx1并且輸出到a的位址，該交易有個未來的鎖定時間，輸入的序列号為0，因而可以被替換。a簽名tx2并且發送給b，b給tx2簽名後發送回a。

4）a廣播tx1和tx2，b可以看到币但是不能花掉它們，因為并沒有輸出到b的位址，該交易還沒有終結。

5）b在山寨币塊鍊上執行相同的操作，b的鎖定時間應該大于a的鎖定時間，雙方的交易都待定但未完全。

6）因為a知道私密x，a能馬上申報他的币，然而，a在申報币的過程中，向b釋放了私密x，是以b可以以私密x和簽名b來完成山寨币塊鍊的交易。

自動化交易完全是以點對點的方式進行的，其能確定貨币的流動性，該協定使得這種交易更為靈活。跨鍊交易的腳本如下所示：

if

合約輸入的腳本如下所示：

由合約輸入腳本中的1或0來決定應該使用哪種方式。如果為1，則跨鍊交易的腳本執行第一段代碼：

2 2 checkmultisigverify

如果是0，則跨鍊交易的腳本執行第二段代碼：

checksigverify sha256 equalverify

參考“atomic cross-chain trading”（見參考資料[9]）能夠得到更詳細的說明。

歐元币是一個很自然的想法，還有其他方法也能夠實作點對貨币的交易（把比特币換成菲亞特汽車，反之亦然），看“ripple currency exchange”（見參考資料［10］）可以得到更多的資訊。

sergio demian-lerner提出了p2ptradex協定，一種塊鍊交易的解決方案，該方案需要把一個塊鍊中的确認規則有效地編碼進另一個塊鍊的确認規則中。

1.5.7　示例6：支付證明合約

在示例4中，我們看到了如何基于任意程式的輸出來實作條件支付，這些程式非常有用，能夠實作任何正常程式所能實作的功能，比如擷取網頁。缺點是需要一個第三方（預言伺服器），盡管我們可以用技術來降低預言伺服器的信任度，但誰都不能降低到0。

對于受限的程式、純函數，新加密技術已經出現，這些技術能從将信任度降低到0，無需第三方參加。這些程式不能進行任何i/o操作，但是在許多情況下，這種限制被證明并不重要，或者可以以其他的方式繞過，比如給程式一個簽過名并且打過時間戳的文檔作為輸入，無需程式自己從網上下載下傳。

若想進一步詳細了解，可以閱讀一下該協定的解釋“zero knowledge contingent payment”（見參考資料[11]）。

1.5.8　示例7：特定對象的快速調整（微）支付

與傳統支付系統相比，比特币交易的費用非常便宜，但是還是需要一些費用以便礦工來挖礦，以及融合到區塊鍊上。有些情況下，你可能想要快速和便宜地調整發送到某個特定位址的貨币金額，而不會導緻産生廣播交易的費用。

舉個例子，有一個你尚不信任的網際網路接入點，就像你從來沒有去過的咖啡屋中的一個wi-fi熱點一樣。每使用10k位元組的流量你得向咖啡屋支付0.001btc，而無須注冊咖啡屋賬号。零信任解決方案意味着可以全自動完成整個過程，因而你在月初預先轉了一筆錢到你的手機錢包中，然後你的手機會自動與ap協商并且按需給ap支付費用，咖啡屋也希望任何人都能來付錢給它，而無須擔心被詐騙。

為了達到這個目标，可以使用下面的協定。該協定依賴nlocktime與原設計不同的行為，從2013年開始，時間鎖定的交易被認為是非标準協定，不能進入記憶體池，這樣就不能在鎖定時間過期之前廣播出去。當nlocktime的行為恢複回中本聰的初始設計時，就需要修改以下讨論的協定了。

可定義用戶端為發送币的那一方，服務端為接收币的另一方，以下協定的實施過程是從客戶的角度來進行的，具體步驟如下。

1）建立公鑰k1，向服務端請求公鑰k2。

2）建立、簽名，但不廣播交易t1，支付10btc到輸出，需要服務端和你自己的公鑰，使用op_checkmultisig是一個好辦法。

3）建立退款交易t2，與t1的輸出相關聯，發送所有币回到你的位址。該交易有一個鎖定時間，例如幾小時後，不簽名并且把該交易發送給服務端，正常來說，輸出腳本是“2 k1 k2 2 checkmultisig”。

4）服務端用k2簽名t2，傳回給客戶，注意，服務端目前還未看到t1，僅僅看到了t1的hash值（該hash值在未簽名的t2中）。

5）客戶驗證服務端的簽名是否正确，如果不正确則中止。

6）客戶簽名t1并且把簽名傳回給服務端，服務端廣播t1（如果他們雙方有聯系的話，每一方都可以廣播t1），币被鎖定。

7）客戶建立一個新交易t3，與t1相聯系，類似于退款交易，有k1和k2兩個輸出，把所有币配置設定給第一個輸出k1，它做了與退款交易相同的事情，但是沒有鎖定時間，客戶簽名t3，發送給服務端。

8）服務端驗證輸出到它的位址的币數量是正确的，驗證客戶提供的簽名是正确的。

9）當客戶想付錢給服務端時就調整t3，向服務端的輸出增加足夠的币，同時減少他自己的币數量，然後重新簽名t3，發送給服務端。客戶無須發送整個交易，隻需要發送簽名和增加的币數量即可。服務端調整t3内容與新的币數量相吻合，驗證客戶的簽名并且繼續。

整個過程會持續到會話結束，或者到1天的時間快到時，此時，ap會簽名和廣播最終版本的交易，向它自己配置設定最終的币數量。退款交易需要處理服務端消息中斷和未配置設定币的情況，如果發生了這些事件，一旦鎖定時間過期，客服就可以廣播退款交易，拿回所有的錢。

這個協定已經用bitcoinj實作了。

當nlocktime的交易能夠進入記憶體池、交易替換重新啟用時，本協定必須被修改。在這種情況下，無需退款交易。t3有一個序列号，每次都比前一次大1，t3的鎖定時間與之前的時間相一緻。每次的支付都使得序列号增加1，以確定會優先發生最後版本。如果沒有正常關閉通道協定，則意味着向服務端支付币不會成功，直到鎖定時間過期，客戶拿回所有币為止。為了避免這種情況，雙方共同簽名t3交易，序列号為0xffffffff，導緻立即确認，而不用考慮nlocktime的值。

鎖定時間和序列号可以避免一種攻擊，在這種攻擊中：ap提供連通性，客戶使用tx2的第一版本雙花，使币回到他自己的位址中，阻止咖啡屋申報賬單。如果客戶嘗試這麼做，該交易不會馬上被包括進去，ap在一段時間内可以觀察到該交易被廣播，然後廣播它看到的最後一個版本，就能推翻客戶的雙花企圖。

後一種協定依賴交易替換，具有更大的靈活性，因為在通道的生命周期中，隻要客戶能收到服務端的簽名，協定就能使客戶為自己配置設定的币的數量越來越少。但是在許多用例中，這個功能是不必要的。交易替換同樣允許配置更複雜的超過兩方的通道，如何在這種使用場景下詳盡地描述協定，就留給讀者作為練習吧。

1.5.9　示例8：多方去中心化彩票

使用示例6的一些技術和一些進階的腳本，使得建構無人值守的多方彩票系統成為可能。準确協定在“secure multiparty computations on bitcoin”（見參考資料[12]）中已經有較長的描述。

參考資料