作者： Elle Mouton
來源：https://btctranscripts.com/advancing-bitcoin/2022/static-invoices-in-lightning
本文為 Elle Mouton 在 Advancing Bitcoin 2022 大會上的演講的轉錄稿，由 b3h3rkz 轉錄。
引言
各位好，我是 Elle，我準備聊聊閃電網絡中的靜態發票（static invoices）。在座大部分人可能都知道，在當前的閃電網絡中，如果你想要獲得支付，你每次都需要創建一個新 “發票（invoice）”。而這一點會給那些完全不瞭解閃電網絡任何事情的人帶來障礙。今天，我準備聊聊為什麼我們應立志實現靜態的發票，然後概述人們一直在討論的三種提議：LNURL、Offer 和 AMP。
那麼，這只是一個簡單的概述。我認為，確保每個人都理解問題在哪裡，是非常重要的。所以我還是會花點時間介紹了一下閃電支付。不是深入探究，只是一個概述，好讓每個人都能理解，要讓支付通過閃電網絡，有哪些先決條件。然後，我們就能理解 BOLT11 發票的作用。然後我會討論這些東西的不足，再進入上述幾種提議。然後，我會給出概要的總結、回顧人們一直再 Twitter 上討論的論據。最後我還會列出一些開放問題。
閃電支付 101
那麼開始吧。在座各位可能都知道，閃電網絡是由許多通道組成的。“通道” 是 Alice 和 Bob 之間的一個合約，基於一個 2-of-2 多簽名腳本，讓他們可以在彼此之間轉移價值，次數不限、非常快速、不需要區塊鏈確認（off-chain）。這非常棒。如果在閃電網絡中，任何兩個人之間都有通道，那靜態發票問題就不存在了，我可以直接結束演講了。
但如果真是這樣，閃電網絡就無法擴展了 —— 你沒法跟你可能要 支付/請求支付 的每一個人都開設一個通道（每一條通道都是一個 UTXO），所以這種模式根本行不通。閃電網絡的美妙之處在於，Alice 的視野看起來有點像這樣，而她需要做的是，如果她要給 Dave 支付的話，就從網絡中找出一條通向 Dave 的路徑（而不必直接跟 Dave 開設一條通道）。
再看仔細一些。Alice 尋找一條觸達 Dave 的路徑，而且她只需要關注路徑就行。那麼現在，Alice 怎麼給 Dave 支付呢？為什麼這個過程不能是靜態的？為什麼她不能直接命令自己的節點 “請給這個人（Dave 的節點 ID）支付這個數量的比特幣”？這就是靜態的了呀。
最天真的方式是 Alice 聯繫 Bob：“嘿 Bob，請幫幫我。我會給你一些比特幣，你從中取出一些交給 Charlie，並讓她再取出一些交給 Dave。”很棒，Dave 得到支付了。但也行不通，因為在比特幣世界裡，我們無法信任 Bob 。事實上，如果 Alice 就像這樣直接給 Bob 一些錢，那根本無法阻止 Bob 直接捲款消失。因此閃電網絡支付也不是這樣工作的。
那到底怎麼工作呢？實際上，在支付開始之前，直白來說，是在我們使用閃電網絡之前，Alice 說：“嘿 Dave，我要給你支付咯，請留意。”Dave 領會了她的意思，就生成一個秘密值，然後將這個秘密值的哈希值發回給 Alice。這都是在閃電網絡之外發生的。現在，Alice 再找到 Bob，但這一次，Alice 會這麼說：“Bob，如果你能找到這個哈希值背後的原像，你就可以拿到我給你的 3 BTC，如果你解不開，那麼一段時間之後，我會收回我的錢。”Bob 看到這些信息之後，就知道了，自己只有把相同的模式繼續傳遞下去、找上 Charlie、最終拿到那個秘密值，才能得到 Alice 的錢。
那麼他也跟 Charlie 建立相同條件的條件式支付，Charlie 也跟 Dave 建立相同條件的合約。Dave 是有這個秘密值的，所以他揭曉這個秘密值，就獲得了 Charlie 的支付；Charlie 轉頭就可以把秘密值交給 Bob，獲得 Bob 的支付；Bob 又可以轉頭找到 Alice。這時候，Alice 就獲得了秘密值，Dave 也得到了支付，這個秘密值就是我們所說的 “支付證據”。
閃電支付 101 差不多就是這樣啦。這裡有兩件事是你需要注意的（好吧實際上是同一件），那麼第一件是：在支付實際發生之前，Alice 和 Dave 必須先在閃電網絡之外有些互動。這就帶來了一個問題：這是為什麼？
Dave 必須給 Alice 交付一個哈希值，但除了哈希值，還有不少其它東西。這就要用到 BOLT11 發票。
BOLT11 發票
BOLT11 規範了 Dave 應該如何構造發送給 Alice 的信息。所以，任何閃電錢包都知道如何構造這些信息，以及如何讀取這些信息。我很確定你們都見過 BOLT11 發票，通常會顯示為一個 QR 碼。注意，這裡展示的是一個 regtest 網絡的發票，給它支付是不安全的，我馬上會講到。
再細緻地瞭解下 BOLT11 發票的樣子。這裡有 prefix（前綴），表明這是一個閃電網絡發票；然後是 Dave 期待的數額、時間戳，一些數據數組（我稍後會回來講解），然後是一個對所有這些東西的簽名。
我已經提到了，其中一個數據是支付哈希值，它非常重要，因為它是保證支付完全性的唯一方法，所以這是首要之物。另一個數據是節點 ID。
如果 Alice 初次走進 Dave 的咖啡館，需要知道在閃電網絡中如何找出 Dave 的節點，那就需要一個節點 ID。Dave 可以在發票中包含的另一個東西叫做 “Hop-Hints（跳躍提示）”，因為 Alice 的網絡視野可能是這樣的，而 Dave 只有私密通道，這是 Alice 無法在公開網絡視圖中發現的，所以 Dave 要告訴她，必須把私密通道之下的 UTXO 告訴她，這樣 Alice 才能找到 Dave。
發票需要包含這些東西。可能還會包含一段描述，比如 “這是為一杯咖啡付的錢”，還有別的一些表示節點特性的信息，相當於 Dave 對 Alice 說：“我能接受具有這些特性的支付”，等等。
還有別的一些東西，但對我今天的演講，知道這些就夠了。那麼它有什麼問題？
我主要關注的東西是：它是一次性的。我聽到人們常常會說，“發票是一次性的，所以，它是不安全的”。我只想解釋一下為什麼。
假設 Alice 和 Bob 都走進了 Dave 的咖啡館。Dave 生成了一個發票，因為他要收取支付。創建一個 BOLT11 發票，展示 QR 碼。Alice 排在簽名，所以先支付，就像我們上面看到的那樣。然後 Dave 揭曉了秘密值，所以 Alice 得到了這個發票的支付證據。但碰巧 Bob 也在同一時間看到了這個發票，而且認為這個發票是給他的，所以他也嘗試支付。所以他也上前一步，掃碼支付。
現在，如果 Eve 和 Charlie 是同一個人，或者串通在一起了，那會怎麼樣？Charlie 在轉發 Alice 的支付時已經知道了那個秘密值，現在只需把那個秘密值發給 Eve，他們就得到了來自 Bob 的錢。Bob 認為：“太棒了，我拿到支付證據了”，但是 Dave 並沒有得到支付。他只得到了一次支付。所以你可以看出，如果你正在支付一個發票，必須確保沒有其他人在之前給這張發票支付過。這是非常重要的。
這就引出了我的下一個結論：這是一種非常弱的支付證據。我剛剛說了，Alice 和 Bob 都得到了相同的支付證據。所以，實際上，擁有一個秘密值只表明相關的支付在某個時刻完成了，不能證明你已經支付了它。
還有一些其它問題。我已經提到，Dave 可能需要在發票中包含跳躍提示。如果他所有的通道都是私密的，這就有點搬起石頭砸自己的腳了，這些通道都不再是私密的了。Alice 可以賣出這些信息。所以這也是不理想的。
另一個事情是發送者和接收者隱私性。在這個例子中，我展示了，當 Alice 給 Dave 支付的時候，Dave 在 Alice 面前是沒有隱私可言的。Alice 確切知道自己的支付會去向哪裡。但 Alice 享有許多隱私性。Dave 不知道給自己的支付的源頭在哪裡，除非 Alice 想要退款，從而不得不揭曉自己在網絡中的位置；這當然並不是一個好選擇。
還有一個小細節是，BOLT11 的簽名在設計初衷上只是為了證明發行人創建了這個發票，它是對整個發票（作為一個扁平結構）的簽名。這是不理想的，如果你希望展示這個簽名是有效的，就只能展示整個發票、暴露所有的信息。
另外是糟糕的用戶體驗。這是一個有效的 BOLT11 發票，包含了 20 個跳躍提示。你也能看出來，這是不理想的。那支付者就沒辦法用手機來掃碼了。而這就證明了，這種出示發票的模式是有很大侷限性的。Dave 可以直接出示給 Alice 的信息量是很受限制的。這就有點尷尬了。
我們都習慣於把錢存到一個不會變化的銀行賬戶裡。現在，我們不得不告訴用戶：“夥計，如果你想獲得支付，那支付的人必須先跟你打一聲招呼，你要讓你的節點生成一張新的發票。然後，你需要把發票發給那個人，然後她會讓自己的節點給你支付。”這不是有點尷尬嗎？
另一個尷尬的事情是取款的流程。假設 Dave 是一家交易所，你希望從交易所取一些錢。再假設你是再電腦上跟交易所交互，但你的節點在你的手機上。現在，你不得不在手機上生成一張發票，然後用某種辦法將發票傳遞到電腦上，然後再發送給 Dave，這樣他才能給你支付。尷尬，還是尷尬。
終於，要講到幾個解決這個問題的提議了。
LNURL
不過，話說回來，我依然主要關注支付場景，暫不考慮取款場景。那麼，“LNURL”，簡單而美妙。LNURL 基本上就是一組規範，指定了 Alice 和 Dave 可以跟彼此交互的不同通信方式。它所指定的所有通信方式都發生在閃電網絡之外。而它能做到的是，在支付場景中，Dave 可以使用一個帶有靜態網絡端點的 HTTP 服務器，比如 “dave.com/payme”。這個 HTTP 服務器會跟 Dave 的節點通信。
現在，Alice 要做的就只是瞭解這個端點了。可以看出，端點不需要變化，它可以是靜態的，可以把它打印出來，也可以把它紋在身上。Alice 訪問這個端點，HTTP 服務器會要求 Dave 的節點生成一張發票並回傳，然後再傳遞給 Alice 的客戶端。任何人都可以訪問這個端點，而且確信自己得到的發票一定是獨一無二的。這真的很棒，如你所見，簡單而美妙。
然後，類似的想法也可以應用到取款流程上。如果你想了解更多，問問樓上的 Coincorner 團隊，他們的卡就使用 “LNURL-withdrawal” 協議。總的來說，它讓我們可以出示這樣的碼，安全地展示給顧客。使用 BOLT11 發票是做不到的，那樣不安全。沒錯，有了 LNURL，使用靜態的端點就是安全的了。
那麼，同樣有趣的地方是，我可以改變它背後的發票的參數，而端點本身不需要改變。比如今天，我的一杯啤酒定價 10 聰，明天，我定價 20 聰；但端點本身不需要改變，對不對？
下面這個是 “LNURL-pay” 協議的一個小插件，叫做 “閃電地址（Lightning Address）”。但背後的原理是完全一樣的，只是更容易在電話裡講清楚，它看起來就像一個郵件地址。
優點與缺點
簡單美妙，這話不假，而且已經能夠服役了。許多錢包都已經集成了 LNURL 。而且不需要改變閃電網絡和 BOLT11，因為通信都發生在閃電網絡之外。它給了我們能夠放在更小的 QR 碼裡的靜態發票，而且支付流程也簡單，容易理解。
一個比較大的缺點是，人們常常說到的，你需要一個 HTTP 服務器，才能使用 LNURL 來收取支付。在此之上，如果你沒有使用 Tor、你不理解域名和TLS 證書，等等（都會帶來一些問題）。沒錯，對手機上的節點也不理想（舉個例子）。
另一件事情是，如果你沒有使用 Tor，不論發送者還是接收者都會有有一些隱私洩露。因為你有了這個服務器。之前我提到，Alice 享有許多匿名性，因為 Dave 不知道支付是從哪裡來的。但現在，她是先向這個 HTTP 服務器發送了請求，所以她會暴露自己的 IP 地址。
Offer
然後是 BOLT12，眾所周知的名字是 “Offer”，是一個非常大的提議，有許多附加功能，來自 Blockstream 的工程師 Rusty Russell。沒錯，從非常抽象的角度看，它跟 LNURL 非常相似，不管是工作流程還是最終效果，除了一點：我在 LNURL 章節講到的發票檢索會發生在網絡內杯，意味著你不需要額外的 HTTP 服務器。所以使用手機的用戶也能用上。它的強大之處在於，沒錯，你不需要任何別的東西。一旦你啟動節點，它就準備好了。
這裡是一個非常粗糙的例子。這回，Dave 要做的是創建一個這樣的東西，叫做 “Offer（要約）”。而且這個 offer 可以是靜態的，它包含了足夠多的信息，讓 Alice 能在閃電網絡中找到 Dave，但不包含任何必須要不斷變更的東西。所以它可以是靜態的。
然後，Alice 可以使用這段信息在閃電網絡中找到 Dave、給他發送一個 “發票請求”。Dave 的節點收到這條消息之後，就會把發票發回來，同樣是通過閃電網絡來傳輸的。現在 Alice 就可以支付這個發票了。
很棒，聽起來非常酷，也很簡單，但為了讓這種發票檢索程序能在閃電網絡中實現，有大量的工作要做。我們來看得仔細些。
首先，我們需要能夠像這樣發送消息。在閃電網絡中通信。好，那麼我們能利用現有的消息傳輸模式嗎？
當前，在閃電網絡中，我們有 “gossip 消息”。有一些消息，是你希望廣播出去的，你希望它像洪水一樣衝遍整個網絡。你希望告訴整個網絡：“各位，這是一條新通道、我是一個新節點、我的通道利用要求更新了”，等等。這並不是請求發票的理想方式，我們並不希望整個網絡都知道我們在請求一個發票，而且我們也絕對不希望整個網絡都看到這張發票。而且，gossip 消息有嚴格的速率限制。大量節點會批量處理他們要發送出去的 gossip 消息，這是非常慢的。你必須等很久，這在我們這個場景中也不理想。
還有另一種消息類型，是支付專屬的信息。還是用我們前面提到的例子。在發送支付時，Alice 必須告訴 Bob 和 Charlie 該把支付轉發到哪裡去、應該使用哪一條通道。這就更接近我們想要的東西了，因為它會沿著 Alice 選擇的具體路徑傳遞消息。但問題在於，它是支付專屬的消息，會觸發添加 HTLC 的流程和作廢 HTLC 的流程。如果要利用這種方法來傳遞消息，你需要創建支付。不過，實際上，真的有人用這種方式在閃電網絡中發送數據。就是製作一筆虛假的支付，隨便填入一個哈希值。Dave 根本不知道它會到來。你在支付專屬消息中添加你希望發送的數據，加密它（使得只有 Dave 可以解密），然後發送給 Dave。Dave 收到消息之後，就知道自己根本沒有那個秘密值，但他可以解密你附加在其中的信息，然後讓支付失敗。這樣就發送了消息。你只需要鎖定少許流動性，只要 Dave 在線，就不會遇到問題；但如果 Dave 離線了，你就不得不等待沿途每一條通道中的 HTLC 的相對時間鎖逐個過期，這對網絡來說可不是好事。
好吧，這就是意味著，要讓 Offer 工作，我們需要一種全新的消息傳遞系統，來發送這些新型的消息。這就是 “閃電網絡中的洋蔥消息（Onion Messaging）” 的由來。沒錯，BOLT12 建立在洋蔥消息上。它的功能恰如其名。它讓 Alice 可以在閃電網絡中發送一條消息給某一個節點，而且，轉遞消息的路徑是由她來決定的。
可能有人會說，這就是一個騙局，為了讓一個局部功能能夠工作，整個網絡都要更新成能夠理解洋蔥消息。但我會說，這不是什麼大問題，因為如果我們能夠從中獲得許多好處，而閃電網絡的規模依然有限，我們就能快速升級。而且人們真的很快升級了。
你還可以用洋蔥消息做很多事情，不僅限於我們前面提到發票請求消息和發票回傳消息；想想，你可以發送任何消息。所以有很多事情可以做，但我在這裡就不講了，你可以繼續關注這個領域。
你可能還聽說別的一些觀點，尤其是在推特上，人們常常說，不應該加上這個功能（洋蔥消息），因為它會帶來 DoS（拒絕服務式攻擊）。人們可以轟炸網絡，人們會通過閃電網絡來傳輸電影，等等。這是人們會有的一個很大的顧慮，因為當前的提案也沒有內置的解決方案。
另一件事情是，Alice 不能夠 —— 至少當前沒有辦法 —— 知道消息是否已經送達。這多多少少也是一個問題。另一件事情是，在這裡，Bob 和 Charlie 是在免費幫助 Alice 。因為 Alice 的消息並不與支付綁定，那他們也就沒有真實的激勵來傳遞消息，除非是出於這種想法：“這一次我幫了你，以後你也會幫我”。我們知道，在比特幣網絡中轉發交易也是這種情形。
我還想說的是，請繼續關注這個領域，因為在過去兩週內，一些意在防止 DoS 攻擊界面的提議出現了。
Offer 還有一些非常酷的附加功能。
首先，我已經介紹了跳躍提示，為什麼它是一個問題（我們最初希望保持隱秘的 UTXO 會被揭曉）。所以，Offer 使用 “盲化路徑”，而不用這樣的跳躍提示。這也基本上就是 Dave 告訴 Alice 如何找到自己的方法：Dave 給出的盲化路徑讓 Alice 可以在網絡中聯繫上自己，但又無需揭曉自己在網絡中的位置。我不會再細講，但真的值得你研究一下。而且這是非常棒的，因為現在，Alice 不再需要知道 Dave 的具體位置，而依然能給 Dave 支付。然後，如果 Alice 想要退款的話，她也可以提供一段盲化路徑，這樣他也不需要放棄自己的匿名性。
另一個非常酷的東西是 “支付者證據”。在 Alice 通過網絡發送給 Dave 的發票請求中，會包含一個屬於她的密鑰，稱為 “支付者密鑰”。當 Dave 發回發票的時候，他需要承諾 Alice 之前發送的消息，因此也承諾了 Alice 的密鑰。這就意味著，當 Alice 拿回 S（哈希值背後的秘密值）的時候，這個 S 值就能證明她是那個發送了支付的的人，因為發票自身證明了她是請求這個發票的人。所以這是很棒的支付證據。
此外，還有對 offer、發票和發票請求消息的簽名：被簽名的東西是一個默克爾根值，而不是整個發票；默克爾樹由發票中所有的字段建構出來。所以，如果你需要向別人展示發票的話，你可以僅展示你願意展示的部分。
無滯支付
好吧，Offer 沒有解決支付滯留（stuck payment）問題，但我還是先介紹一下。所謂 “支付滯留”，就是說，我走進咖啡館，得到了一張發票，我發起支付，然後它卡住了；於是我麻煩店家再給我一張發票，我的節點通過另一條路徑發起支付，這一次就成功了；但就在這時，第一筆支付也報告說成功了。
店家可沒辦法分辨出我只想支付一次。所以 Offer 也考慮到了這一點。那麼當你發起第二次發票請求的時候，你可以表示：“嘿，我想替換掉第一張發票”。這依然是有可能成功的，只需要加入一些合理否認的能力就行。
而且有趣的地方是，你可以用別的貨幣（而不是比特幣）來指定數額，這對靜態端點是有好處的，尤其是在價格劇烈波動的時候。所以你現在有了一個靜態的端點，而且你可以說，我準備用美元來標註支付數額；然後這個端點就可以一直使用了。當人們，支付方的錢包需要一個換算率才能支付。
而且 Offer 還可以用來支持訂閱。比如說，這是一個 Offer，它意味著你會每個月給我訂閱費。等等。但目前，出於時間考慮，這個特性被刪掉了。
優點與缺點
Offer 非常棒的地方在於，它是閃電網絡原生的。所以你啟動節點的一刻，就可以獲得這種好處，無需擔心要用到額外的服務器。因為盲化路徑，支付者和接收者都可以獲得更好的隱私性。而且，再說一次，因為有了靜態的端點，我們有了更好的用戶體驗，以及更好的支付證據。
當然，它也有一些缺點，比如需要整個網絡的升級，這個我已經提過，我個人認為不是一個大問題。然後，當前的問題是還沒有為 DoS 保護設計出解決方案。另外就是人們常常說的，它依賴於許多東西。我已經提到了洋蔥消息和盲化路徑。沒錯，如果我們想要使用 offer，就是要實現這麼多東西。而且它確實給網絡帶來了一些應用層面的東西，這也是一些人不喜歡的。比如我前面提到的，用其它貨幣來指定數額。
原子化多路徑支付（AMP）
在說別的之前，我想先提一句，AMP 真正強大的地方在於它讓你能原子化地使用你所有的通道或一部分通道來發起一筆支付。而它的副作用是，你可以使用一種靜態的發票。
單路徑情形
我準備先聊聊靜態發票。用一個單路徑支付的情形來做例子吧。本來呢，Dave 要創建一張 BOLT11 發票；我前面也介紹過了 BOLT11 發票裡面都有些什麼東西。而每次都要創建新發票的原因在於，你需要更換支付哈希值，以保證支付的安全性。
但在使用 AMP 時，支付哈希值是沒有意義的，Dave 會用發票中的特性位告訴 Alice，這是一張 AMP 發票，你可以安全地多次支付。當然，支付者的節點需要理解這種特性。
到目前為止，我們都假設 Dave 總是需要創建秘密值、計算出哈希值，並將這個哈希值發送給 Alice 。但 AMP 讓事情反轉過來：Alice 換生成一個秘密值、計算出哈希值；她會加密這個秘密值，使得只有 Dave 能解密它；然後，再構造支付專屬消息。當支付專屬消息轉遞給 Dave 的時候，他可以解密消息，得到藏在其中的秘密值，然後用來領取支付；秘密值會一路回傳。
很棒，這樣我們就得到了兩個東西。第一個是 Alice 可以直接發起支付，無需提前通知 Dave。這就允許自發支付。第二個事情是 Alice 無法收到支付證據。因為她一開始就知道那個秘密值，也就意味著最終收回的秘密值是沒有意義的。
現在，現在我希望展示 AMP 真正美麗的地方，用圖像來展示它是怎麼工作的。
Alice 可能希望使用她分散在不同通道中的餘額來給 Dave 支付。所以，她先創建一個叫做 “根種子（root seed）” 的東西，就是一個大體積的數據。然後，她會憑此確定性地生成出四個不一樣的秘密值、再計算出這些秘密值的哈希值。為什麼是四個？因為她想使用自己全部的四條通道。現在，她將根種子分成四份。在發送支付的第一條路徑中，她以第一個哈希值製作 HTLC，並附上根種子的第一個部分。在這份支付送達的時候，Dave 還無法領取支付，因為他還不知道這個哈希值背後的秘密值。
只有當四份支付全部到達的時候，Dave 才能重構出根種子，然後確定性地生成出四個秘密值，再領取支付。這就是它美妙的地方。
好處和缺點
再說一遍，靜態發票。只有 Alice 和 Dave 需要支持 AMP。這讓 Alice 可以直接支付，無需提前聯繫 Dave。而且，我們可以複用 BOLT11 發票。而且，你可以利用你所有的通道，這是很棒的，因為如果一個新用戶進來，他並不知道 “通道” 為何物；應用只需展示一個餘額，而他也確實可以使用全部餘額。那麼，一個大缺點是它沒有支付證據。
結語
好的，那麼到這裡就結束了。這個演講只是想展示各方案在抽象層面的對比。然後我想留一些問題給各位。
先來看看閃電網絡的內部分層。當前的 BOLT1 到 BOLT11 基本上覆蓋了這些層級，組網、發送消息、支付和發票構造。在此之處，我們無論如何逃不過去的是發票的溝通。在此之上，我們可以開發應用。那麼，上面提到的三種方案，位於哪些層級呢？
LNURL 只規定了發票溝通，至少我前面提到的 “LNURL-pay” 協議是隻做這個。AMP 只是一種新型的支付。但 Offer 跨越了許多層級。它觸及了許多東西。
Offer 自身的規範中沒有包含這個，但它確實依賴於洋蔥消息。它還使用不同於 BOLT11 的發票格式，所以包含了一種新的發票構造。它還規定了發票溝通。而且它還包含了一些應用層的東西，比如用別的貨幣單位來指定支付數額。
那麼有幾點需要討論。如果你關注推特上的辯論，有幾個事情是人們經常討論的：
第一個是支付證據的重要性。我已經提到，當前的 BOLT11 發票所提供的支付證據是比較弱的。AMP 則並沒有支付證據。Taproot 和 PTLC（點時間鎖合約）會改變這一切，它們會帶來非常強的支付證據。但是人們還是會爭論。一方會說，沒錯，顯然支付證據是非常重要的，因為當網絡變得非常大的時候，你就會非常、非常、非常想要支付證據。而另一方會說，現在人們到底怎麼使用支付證據？有多頻繁使用？你知道，許多錢包甚至都不向用戶展示支付原像。所以兩方一直爭論。
另一個會爭論的事情是，什麼應該加入協議，什麼不應該加入協議？怎麼畫這條線？
還有，我們需要保持只有一個發票系統嗎？我們能不能別把它們混在一起？
我們需要能夠服務每一種用戶的系統麼？比如說，人們會說，LNURL 對商家是非常友好的，因為他們總是會運行一臺服務器，但對只是想在手機上使用錢包的用戶就不太友好了。沒錯，在商戶一端，LNURL 工作得非常好，而 Offer 是對在手機上使用閃電網絡的用戶非常友好。那麼，我們能兩者兼得嗎？我們需要保證只有一套解決方案嗎？
我對這些問題非常感興趣，所以也留給各位。感謝。
（完）
