比特幣如何使用BIP70支付協(xié)議API

這期內(nèi)容當中小編將會給大家?guī)碛嘘P(guān)比特幣如何使用BIP70支付協(xié)議API，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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

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

具體而言，該協(xié)議的第1版提供：

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

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

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

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

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

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

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

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

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

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

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

協(xié)議概述

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

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

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

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

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

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

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

簽名和證書

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

Pay 10mBTC to 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?

與這樣的一個：

• 支付10mBTC到satoshin@gmx.com？

• 支付20mBTC到overstock.com？

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

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

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

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

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

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

bitcoinj中的支付協(xié)議API

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

盡管如此，這里還是我們?nèi)绾问褂眯鹿δ艿难菔尽?/p>

String url = QRCodeScanner.scanFromCamera(.....);
ListenableFuture<PaymentSession> 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<PaymentSession.Ack> 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());
    }
});

用戶界面注意事項

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

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

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

二維碼

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

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

操作系統(tǒng)集成

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

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

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

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

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

上述就是小編為大家分享的比特幣如何使用BIP70支付協(xié)議API了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道。