使用 DNS 協調比特幣支付

馬特·科拉羅 (Matt Corallo) 一周多前提出了一個 BIP,用於協調比特幣支付。由於不同的原因,使用閃電網路等協議進行比特幣支付一直在鏈上和鏈下協調方面提出一些挑戰。當涉及電子郵件等數位系統或 Paypal、Cashapp 等支付系統時,人們非常習慣單一靜態識別碼的概念。如果您想向 John 發送電子郵件,只需發送電子郵件「john@[插入網域]」。如果您想在 Cashapp 上向 John 匯款,只需在 Cashapp 上向 @John 付款即可。

這是人們熟悉的使用者體驗,當涉及到根深蒂固的使用者行為和對事物的期望時,推動他們的行為發生實質或急劇的改變是非常困難的。如果你提供他們一個需要這樣做的工具,就會產生很大程度的摩擦,並且很可能只會抑制大多數人使用該工具的積極性。

鏈上支付遇到了這種期望的問題,不是因為無法擁有靜態標識符(單個地址),而是因為發布單個鏈上地址並讓與您交互的每個人都使用該地址會帶來隱私影響付錢給你。它將您的整個支付歷史和代幣所有權置於每個人的公共視野中。如果您偶爾很少收到錢,即在領取工作報酬或與人結算酒吧賬單時,那麼只需打開錢包並生成一個新的收款地址就根本不是負擔。然而,如果您經常收到金錢,特別是在您不直接要求付款的情況下,那就會帶來嚴重的負擔。

這就是創建 BTCPay Server 這樣的工具的原因,目的是降低人們啟動所需基礎設施以自動接收資金的門檻,而無需做一些天真的事情,例如發布一個地址供每個向您付款的人重複使用。然而,這需要運行一個始終在線可用的伺服器。雖然該專案大大降低了所需的理解門檻,但對於只想被動接收資金的用戶來說,這仍然是一個沉重的負擔。

對於閃電來說也是如此,除了更糟之外。發票僅適用於單次付款。與可以重複使用的鏈上地址不同,儘管這是一種可怕的做法,但閃電發票不能使用。一旦發票已支付或過期,相關閃電節點將拒絕任何付款嘗試。這種動態導致了 LNURL 規範以及建立在其之上的閃電位址的創建。 LNURL 是一種透過靜態 IP 連接到 HTTP 伺服器的協議,該靜態 IP 可以共享一次,以便從伺服器取得實際的閃電發票進行付款。在此基礎上,閃電位址是 LNURL 之上的命名方案,其結構類似於電子郵件地址:John@[LNURL 伺服器的網域]。

所有這些解決方案都有缺點。除了比特幣錢包或閃電節點之外,還需要運行一個始終保持在線的額外軟體(HTTP 伺服器);向 BTCPay/LNURL 伺服器發出請求會將發送者的 IP 位址洩漏給接收者;依賴 TLS 憑證授權單位。

只需使用 DNS

LNURL 等 HTTP 伺服器工具與 Lightning Address 搭配使用時,會使用網域來解析與 HTTP 伺服器的連線。同樣,BTCPay 伺服器都配置了域名,而不是使用原始 IP 位址。 Matt 的見解是,為什麼不直接消除對 HTTP 的依賴並使用網域名稱系統本身呢?

DNS 可讓您將 TXT 記錄與給定網域名稱關聯起來,建立可從 DNS 伺服器查詢的小型人類(或機器)可讀記錄。與域名系統安全擴展 (DNSSEC) 結合,DNS TXT 記錄提供了一種機制,可用於查詢支付信息,而無需運行 HTTP 伺服器的開銷和負擔,並提供更多的靈活性和開放性。 DNSSEC 提供了許多工具,用於使用 DNS 分層結構中固有的 DNS 金鑰對 DNS 項目(包括 TXT 記錄)進行加密簽署。這保證了您正在查詢的 TXT 記錄是由本地根伺服器/金鑰簽署並分發到較低等級 DNS 伺服器的記錄。

這體現了 DNS 作為獲取支付資料的手段的真正好處:告別必須運行 HTTP 伺服器的要求。 TXT 記錄可以對鏈上比特幣位址進行編碼(儘管如果您無法定期輪換新位址以防止位址重用,則BIP 特別建議不要這樣做),但更重要的是,它還可以包含BOLT 12​​XNUMX 閃電優惠。

這些記錄可以從任何 DNS 伺服器、您自己的本機伺服器、您的 ISP,甚至是 Google 或 Cloudflare 等公共伺服器取得。從這個基本點出發,解決了基於HTTP的解決方案的一個缺點;您不再將您的 IP 位址洩露給您嘗試付款的人。現在,如果在沒有 VPN 或 Tor 的情況下使用您的 ISP 的 DNS 或公共伺服器(例如 Google 或 Cloudflare),您將向他們洩露您的 IP 位址;基於這個原因,BIP 明確鼓勵透過 VPN 或 Tor 支援 DNS 解析。

將此提案與BOLT 12​​12 相結合,無需運行輔助軟體,這對不熟練的用戶來說是一個非常現實的安全問題,並且僅允許域的所有權即可為用戶提供他們所需的一切,讓他們有一個透過簡單的人工操作即可定位支付資訊的機制。可讀標識符。 BOLT XNUMX​​XNUMX 不需要 HTTP 伺服器,直接透過閃電網路透過洋蔥路由連接處理實際發票交付,並支援 Offers,這是一種靜態標識符,可用於查找到該閃電節點的洋蔥路由。問題是報價被編碼為一個巨大的隨機字串,就像發票本身一樣,這使得它成為一個可怕的人類可讀/可用標識符,除非透過使用二維碼或複製和貼上。

透過將報價儲存在 DNS TXT 記錄中,使用者只需在錢包中輸入某個人的網域即可付款,這樣錢包就可以取得 TXT 記錄、取得 BOLT 12​​12 報價,然後進行付款。他們不需要託管任何伺服器或運行閃電節點以外的任何軟體,DNS 系統會為他們處理一切,只要託管他們的 BOLT XNUMX​​XNUMX 就可以為想要付費的用戶找到可以找到的人。

這是一個完全無需信任的系統嗎?不行。它比基於 HTTP 的系統好很多嗎?絕對地。這類問題的問題在於,大多數人對使用者體驗和行為都有一定的期望,因為數位系統應該在他們的腦海中發揮作用。如果不複製這種使用者體驗,大量的人只會使用確實滿足使用者體驗期望的替代方案。鑑於這一現實,在嘗試將比特幣納入這些用戶體驗期望的範圍內時,設計目標應該是透過最少的信任插入、最小的用戶負擔以及最小的潛力來滿足這些用戶需求。以新的方式喪失隱私。我認為與現有解決方案相比,Matt 的 BIP 滿足了所有這些要求。 

資料來源:https://bitcoinmagazine.com/technical/using-dns-to-cooperative-bitcoin- payments