摘要：支付協議對于比特幣的各種重要功能的開發至關重要，因此，了解它如何使用比特幣非常重要。單擊比特幣時，將忽略其余部分中的指令它們僅用于向后兼容，并且在給定處找到的數據優先。

支付協議是用于指代BIP70,71,72和73中指定的協議的術語。支付協議旨在通過用可編碼更復雜參數的小文件替換普遍存在的比特幣地址來為比特幣添加附加功能。它指定了直接在資金發送方和接收方之間流動的支付請求，付款和支付方式的格式。

支付協議對于比特幣的各種重要功能的開發至關重要，因此，了解它如何使用比特幣非常重要。本文介紹了基本功能，并顯示了將其集成到錢包應用程序中的一些示例代碼。

具體而言，該協議的第1版提供：

1.接收器/商家使用任意腳本請求多個輸出的方式，而不僅僅是單個付費密鑰哈希類型的輸出。多個獨立交易可以滿足付款，允許將來實施基于規避合并的隱私技術。

2.自由文本備忘錄字段，因此商家可以填寫由錢包存儲的購買細節，及用戶在付款時附加消息。

3.到期時間，過期的付款請求可能會被視為無效。這允許接收器在服務器端綁定其資源使用并放棄從未付費的請求。

4.發行時間，付款請求知道何時發出——有利于記錄保存。

5.二進制cookie-esque字段，在提交支付交易時將簡單地回顯給服務器，允許商家實現無狀態后端。

6.用戶指定的退款地址。

7.使用X.509數字證書對上述所有內容進行簽名的可選功能，從而將付款請求綁定到某種經過驗證的身份。

支付請求本身可以進行數字簽名這一事實可以實現一些非常重要和有用的功能。中間的一個人不能重寫輸出來劫持付款。這對于像Trezor這樣的硬件錢包來說尤其重要，因為Trezor會假設主機受到損害，否則用戶無法知道他們授權的付款與商家要求的付款相同。

此外，數字簽名的付款請求和在區塊鏈上滿足它的交易一起創建非常類似收據的付款證明。收據對于爭議調解和證明購買是有用的，而商家不必保留他們曾經擁有的每個客戶的詳盡數據庫——即使商家刪除了有關你的數據，只需出示收據就足以證明你已進行購買。

協議緩沖區是一種可以輕松擴展的二進制數據序列化格式。因此，我們可以很容易地想象將來可能添加的許多其他功能。

你可以閱讀付款協議的常見問題解答，詳細說明其設計背后的基本原理。

在正常的比特幣支付中，該過程從用戶點擊比特幣URI或復制并將文本地址粘貼到他們的錢包應用程序并手動指定金額開始。

在付款協議處理的付款中，該過程以兩種方式之一啟動：

用戶單擊具有新“r”參數的比特幣URI，該參數包含解析為付款請求文件的（http）URL。

用戶直接打開付款請求文件。

然后，用戶的錢包解析作為協議緩沖區的支付請求數據，并開始正常請求確認的過程。單擊比特幣URI時，將忽略URI其余部分中的指令（它們僅用于向后兼容），并且在給定URL處找到的數據優先。

支付請求由外部“skin”消息組成，該消息包含（可選的）簽名和證書數據，以及包含所請求支付的詳細信息的內部“core”消息的嵌入式序列化。外部PaymentRequest消息與所使用的數字簽名基礎結構的類型無關，但目前僅定義了X.509綁定。這與SSL中使用的系統相同。內部PaymentDetails消息以二進制形式存儲，而不像普通的protobuf消息那樣被嵌入，以確保簽名字節始終匹配。

一旦錢包創建了令人滿意的比特幣交易集，就會格式化付款消息并將其上傳到PaymentDetails指定的目標URL，一旦滿意地接受付款，錢包就會收到PaymentACK消息。

簽名付款請求的目的是在用戶錢包應用中替換此類消息：

Pay 10mBTC to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?

與這樣的一個：

支付10mBTC到satoshin@gmx.com？

支付20mBTC到overstock.com？

向邁克爾赫恩支付30億比特幣？

向加利福尼亞州舊金山的Genius Widgets公司支付100 BTC

......當然，第一種形式是最無用的，因為在這種情況下，身份只是一個沒有意義或穩定性的隨機數。這導致了其他示例中的字符串來自何處的問題。

答案是它們包含在X.509數字證書中，該證書本身由證書頒發機構簽名。盡管有這個名字，但CA只是簽署證書的任何實體，唯一賦予它們權力的是人們對軟件的信任。ID驗證和證書頒發具有競爭市場，這意味著你可以免費獲得非常容易驗證的身份證書（如電子郵件地址或域名）的證書。更復雜的身份，例如人或公司的合法名稱，需要更多的努力來驗證，因此必須付費。

從技術上講，證書只是關于公鑰的聲明，因此要求你必須首先生成私鑰，然后是證書簽名請求（CSR），然后選擇CA并上傳CSR，以及你想要的身份和任何驗證所需的信息。然后，CA會發回一個簽名證書，該證書可以嵌入到付款請求中，同時還可以嵌入到達到一組根證書所需的任何中間證書。然后使用私鑰對PaymentDetails消息進行簽名，現在其他用戶軟件可以驗證所有這些并在用戶界面中顯示經過驗證的ID。它還充當你在指定時間實際發出給定付款請求的加密證明。

實際上，上述手動創建密鑰，創建CSR，上傳密碼等過程通常會自動取消最終用戶電子郵件地址證書：相反，任何支持HTML5的現代Web瀏覽器都可以用來自動完成整個過程。在訪問發布Comodo等免費證書的CA后，用戶輸入所請求的電子郵件地址并單擊按鈕。然后他們的瀏覽器生成一個新的私鑰并記錄下來。當用戶單擊傳遞到其電子郵件地址的驗證鏈接時，簽名過程完成，證書將安裝在本地密鑰存儲中，可以在其中使用或導出到其他設備。整個過程與注冊網站沒有太大區別。

在0.12中，bitcoinj中的支付協議支持是有限的。它支持錢包應用程序中基本支持所需的一切，用于簽名和使用付款請求。但是，它不支持將它們存儲在錢包中以供將來參考。bitcoinj也沒有利用這個機會向收件人提交多個獨立交易以規避合并。

盡管如此，這里還是我們如何使用新功能的演示。

String url = QRCodeScanner.scanFromCamera(.....);
ListenableFuture future;
if (url.startsWith("http")) {
    // URL may serve either HTML or a payment request depending on how it"s fetched. 
    // Try here to get a payment request.
    future = PaymentSession.createFromUrl(url);
} else if (url.startsWith("bitcoin:")) {
    future = PaymentSession.createFromBitcoinUri(new BitcoinURI(url));
}

PaymentSession session = future.get();    // may throw PaymentRequestException.

String memo = session.getMemo();
Coin amountWanted = session.getValue();

if (session.isExpired()) {
    showUserErrorMessage();
}

PaymentSession.PkiVerificationData identity = null;
try {
    identity = session.verifyPki();
} catch (Exception e) {
    log.error(e);
    // Don"t show errors that occur during PKI verification to the user!
    // Just treat such payment requests as if they were unsigned. This way
    // new features and PKI roots can be introduced in future without
    // being disruptive.
}

if (identity != null) {
    showUserConfirmation(identity.domainName, identity.orgName);
} else { 
    showUserConfirmation();
}

// a bit later when the user has confirmed the payment

SendRequest req = session.getSendRequest();
wallet.completeTx(req);  // may throw InsufficientMoneyException
// No refund address specified, no user specified memo field.
ListenableFuture ack = session.sendPayment(ImmutableList.of(req.tx), null, null);
Futures.addCallback(ack, new FutureCallback() {
    @Override public onSuccess(PaymentSession.Ack ack) {
        wallet.commitTx(req.tx);
        displayMessage(ack.getMemo());
    }
});

以特定方式提交付款協議確認非常重要。

首先，如果簽名的PKI數據可用，你應該以一些具有視覺意義的方式向用戶表明，因此他們知道所呈現的字符串是由第三方驗證的ID。第三方（即CA）的名稱也應該是可見的，盡管默認情況下將其隱藏在切換/滑塊后面是可以接受的。

其次，如果提供了簽名的PKI數據但未能驗證，則應以與完全丟失簽名數據完全相同的方式呈現付款。打開錯誤簽名的請求的經驗永遠不會比打開一個完全沒有簽名的請求更糟糕。這使我們可以靈活地引入新的證書頒發機構或簽署系統。

如果你的應用程序集成了掃描QR碼的支持，你應該注意BIP 73.它說如果錢包應用程序掃描QR碼并找到HTTP URL而不是比特幣URI，它應該執行HTTP [S] GET到具有特殊HTTP標頭的URL，該標頭要求服務器提供付款請求。

這種機制的目的是讓商家和支付處理商可以提供可以在任何類型的QR掃描儀上工作的QR碼，如果用戶沒有帶有集成掃描儀的錢包，那么帶有說明的一個漂亮的HTML發票頁面和可以顯示可點擊的比特幣鏈接。

如果要編寫錢包應用程序，你應該注冊處理比特幣URI，你還應注冊處理類型為application/bitcoin-paymentrequest的文件，擴展名為.bitcoinpaymentrequest。

通過這樣做，你可以確保你的應用可以處理附加到電子郵件的付款請求，通過IM應用程序發送等等。

理想情況下，你還可以允許用戶創建付款請求。PaymentRequest消息的pki_type可以為“none”，因此創建此類文件是有效的。為了簡單的用戶體驗，我們建議：

在桌面上，允許用戶拖放支付請求文件（將其表示為圖標）。例如，用戶可以將其拖動到電子郵件撰寫窗口以將付款請求附加到電子郵件與手動復制/粘貼地址和金額。 Gmail支持將文件拖放到編輯器上，其他HTML5應用也可以接受拖放數據。

在移動設備上，允許用戶“共享”支付請求文件，這將允許用戶通過聊天應用程序發送，附加到電子郵件，通過DropBox/Google Drive等共享。

Gavin在這里運行一個簡單的付款請求生成器應用：

https://bitcoincore.org/~gavi...

你可以使用它來測試你的錢包實現。

分享一個java比特幣開發教程，面向初學者，內容即涵蓋比特幣的核心概念，例如區塊鏈存儲、去中心化共識機制、密鑰與腳本、交易與UTXO等，同時也詳細講解如何在Java代碼中集成比特幣支持功能，例如創建地址、管理錢包、構造裸交易等，是Java工程師不可多得的比特幣開發學習課程。

匯智網（專業區塊鏈教程網站）原創翻譯，轉載請標明出處。這里是原文