TW202130152A

TW202130152A - 電腦實行系統及方法

Info

Publication number: TW202130152A
Application number: TW109132946A
Authority: TW
Inventors: 安布魯斯沙拉; 史帝芬歌芙蘭; 都蘭威爾聖哈
Original assignee: 安地卡及巴布達商區塊鏈控股有限公司
Priority date: 2019-09-30
Filing date: 2020-09-23
Publication date: 2021-08-01
Also published as: EP4038828A1; CN114556863A; WO2021064504A1; JP2022549625A; US20220405747A1; KR20220071241A

Abstract

在一第一態樣中，本揭露提出用於實施一付款服務的方法、裝置與系統，該付款服務為了能夠使與一客戶相關聯的交易寫入、或儲存在一分散式分類帳，亦即一區塊鏈中。該付款服務係實施為一API，一或多個客戶可取用該API以處理關於一各別客戶之數位資產付款。在一第一態樣中，包括：針對一客戶自複數個礦工獲得一開採費用報價；以及基於一所選擇費用報價處理要將一交易提出至區塊鏈之請求。在一第二態樣中，本揭露提出用於基於在一客戶（付款人）與一顧客（收款人）之間的一數位資產付款而請求一交易的方法、裝置及系統，該交易係與要在一區塊鏈中開採之一數位資產付款相關聯。該請求係與一所選擇費用報價相關聯及/或與在以上的態樣中，所接收費用報價中之所選擇費用報價相關聯的服務層級。在一第三態樣中，該方法包括基於滿足礦工之來自客戶的所選擇費用報價，如以上態樣中所提及由一礦工創建、處理及開採與客戶相關聯之一區塊鏈交易。

Description

電腦實行系統及方法

發明領域

本揭露大致關於用於實施用於一或多個客戶之付款服務或一付款介面的方法與系統。本揭露更特定地，但不限定於致能用於或代表一或多個客戶之與一區塊鏈或分散式帳本相關聯之安全與可靠付款交易，該等交易關於與一顧客或一付款實體相關聯的一數位資產付款。

發明背景

在此文件中我們使用的用字「區塊鍊」來包括所有形式的電子、電腦式、分散式帳本。此等包括了以共識為基礎區塊鏈與交易鏈技術、認許式帳本（permissioned ledger）與非認許式帳本、共享帳本、公鏈與私鏈以及其等變化。雖然也已經提出與研發出其它區塊鏈實施，區塊鏈技術最廣為人知的應用為比特幣分帳本。雖然比特幣在此可為了用於方便與例示的用途而被提及，應當注意的是本揭露不限定於使用比特幣區塊鏈，且與任何種類數位資產相關聯或代表一數位資產者的替代區塊鏈實施與通訊協定皆落入本揭露的範圍內。用字「客戶」、「實體」、「節點」、「使用者」、「發送者」、「接收者」、「付款者」、「收款者」在此可指一電腦或基於處理器之資源。用字「比特幣」在此使用來包括任何版本或或任何由比特幣通訊協定所衍生而出的變化或基於比特幣通訊協定者。用字「數位資產」可指涉任何可交易資產，諸如加密貨幣、代表一財產的至少一部份的代幣（token）、一智能合約、一授權，亦即軟體授權或用於媒體內容之DRM合約等等。可以理解的是用字數位資產於此文件各處使用來代表一商品，該商品可與一價值相關聯，該價值可被移轉或提供以作為從一個實體到另一實體之交易中的一付款。

一區塊鏈為一點對點電子分帳本，其係實施為由接著組成交易之區塊所組成的一電腦式去中心化、分散式系統。各交易為一資料結構，其將於區塊鏈系統中的參與者之間的一數位資產的控制之移轉編碼，並且包括至少一輸入與至少一輸出。各區塊包含先前區塊的一雜湊值，因此區塊變成被鏈接在一起來創造自區塊鏈被創造以來被寫入區塊鏈的所有交易的一永久、不可改變記錄。交易含有嵌入到其輸入和輸出中被稱為腳本（scripts）的小程式，其指定如何以及誰可取用交易的輸出。在比特幣平台上，這些腳本係使用基於堆棧（stack-based）的腳本語言編寫的。

為了將交易寫入區塊鏈，其必須被「驗證」。網路節點（礦工）進行工作以確保各交易為有效，並且無效交易被網路拒絕。安裝在節點上的軟體客戶藉由執行其鎖定與解鎖腳本來對一未花費交易（unspent transaction）進行此驗證工作。若鎖定與解鎖腳本的執行評估為真（TRUE），交易為有效，且該交易接著被寫入區塊鏈。因此，為了將一交易寫入區塊鏈，其必須要一）由接收到該交易的第一節點所驗證，若該交易被驗證，該節點將其中繼（relay）至在網路中的其他節點；以及二）添加到由一礦工所建立的一新區塊中；以及三）開採，亦即添加到過去交易的公用分帳本。

一旦作為一UTXO被儲存在區塊鏈中，一使用者可將相關聯資源的控制移轉到與在另一交易中之一輸入相關聯的另一位址。此移轉通常，但不必要是使用一數位錢包來完成。此數位錢包可為一裝置、一實體媒體、程式、在一計算裝置上的應用程式（app），計算裝置諸如一桌上型電腦、膝上型電腦或一行動終端，或與在諸如網際網路之一網路工作區域上相關聯的一遠端主機服務。數位錢包儲存公鑰與私鑰，且可被使用來追蹤與一使用者相關聯之資源的擁有者、代幣與資產等等，移轉代幣可與諸如加密貨幣、授權或財產或其他類型的資源的數位資產相關。

雖然區塊鏈技術最廣為人知的為加密貨幣實施的使用，數位企業家正在探索使用比特幣所基於的密碼安全系統，以及可以儲存在區塊鏈中以實施新系統的資料兩者。如果區塊鏈可被使用於不限於加密貨幣領域的自動化工作和程序將會是非常有利的。此等的解決方案將能夠利用區塊鏈的好處（例如，永久的、防篡改的事件記錄、分散式處理等等），同時在其應用中更具多樣化。

目前研究的一個領域為區塊鏈用於實施「智能合約」的使用。其為設計來自動化一機器可讀合約或協議的條款之執行的電腦程式。不像將會以自然語言撰寫的一傳統合約，一智能合約為一機器可執行程式，其包含可處理輸入以產生結果的規則，其可接著致使進行根據此等結果的操作。一區塊鏈相關利益的另一領域為「代幣（token）」的使用（或「彩色硬幣」（coloured coins）），可經由區塊鏈來代表並移轉真實世界實體。一潛在敏感或秘密項目可由代幣所代表，其不具有可分辨意義或價值。代幣因此作為一識別符，其允許真實世界項目從區塊鏈中被提及。

以上提及相關於一些資產，亦即，一數位資產的轉移或在使用者或實體間一數位資產的控制的範例或場景。據此，需要實施安全與穩健的系統，其與現有的在兩個實體間交易資產之付款或電子商務系統類似，特別是用於在一商家與一顧客間的數位資產付款，此可關於在實體世界中的一資產，具有一較佳使用者體驗、較便宜的商家或收款人成本以及一更安全層級的安全性。更特定地，需要使用分散式帳本（區塊鏈）技術以及增加記錄的安全性、透明度、與可靠度的優點，以提供一共用平台或介面，其可使任何商家或複數個商家可確保他們個別的顧客的數位資產付款可即時地與安全地被開採或寫入區塊鏈，因而提供此等付款一持久、防竄改與可審核的紀錄。

此等改進的解決方案現在已經被設計出來。本揭露藉由提出一些技術來處理此等技術考量，藉由此等技術，對於身為諸如加密貨幣之數位資產收款人之一或多個客戶，亦即商家或收款實體的交易，可藉由方法、技術與裝置即時地寫入區塊鏈，該等方法、技術與裝置提供此等客戶的一應用程式介面（API）。在此等技術中，礦工將可以動態地或立即地開採或將交易寫入區塊鏈，亦即以一安全與可靠的方式，提供允許即時交易或零確認交易（0-conf）的一服務給客戶。

發明概要

在一第一態樣中，本揭露提出用於實施一付款服務的方法、裝置與系統，此付款服務使得與一客戶相關聯的交易將被寫入或儲存在一分散式帳本，亦即，一區塊鏈。付款服務係實施為一API，一或多個客戶可取用該API而處理關於一個別客戶的數位資產付款。在一第一態樣中包括從複數個礦工中針對一客戶獲得開採費用報價，以及處理基於一所選擇費用報價對該區塊鏈提出（submit）一交易的一請求。

在一第二態樣中，本揭露提出基於在一客戶（付款者）與該客戶的一顧客（收款者）之間的一數位資產付款而用於請求與將在一區塊鏈中被開採的一數位資產付款相關聯之一交易的方法、裝置與系統而。在以上態樣中，使該請求與所接收費用報價中的一所選擇費用報價相關聯。

在一第三態樣中，如以上態樣中所提及之方法包括基於滿足客戶之所選擇費用報價的一礦工，藉由該礦工創造、處理及開採與一客戶相關聯的一區塊鏈交易。

在整個說明書中，用字「包含」或諸如「包括」、「包含有」或「包含了」等變化將可被理解為暗示包括所描述元件、整數或步驟或元件群組、整數或步驟，但不是要排除任何其他元件、數字或步驟或元件群組、整數或步驟。

根據一第一態樣，本揭露提供一種電腦實施方法，該方法可為一或多個客戶之與一區塊鏈相關聯的交易實施一付款服務，該方法藉由與該付款服務相關聯的一付款處理器所實施。在一些實施例中，在此，一客戶可為一計算資源或一節點，或與用於接收及/或處理加密貨幣付款之一數位錢包相關聯的實體，且可與一公鑰或用於此等錢包之公用位址相關聯。在一些實施例中，該客戶可代表一商家實體或終端，諸如，例如販售裝置的一端點，其在實際世界中提供商品或服務，且接收用於此等商品或服務的數位資產付款，但不限定於此。在一些實施例中，該付款處理器係組配為可提供一付款介面給一或多個客戶，作為一相關聯或一第三方服務。在一些實施例中，該付款處理器係指一付款聚合體（aggregator），由於其提供了複數個付款服務，且經由用於客戶之一或多個使用者友善介面和礦工提供與區塊鏈相關聯的功能。在一些實施例中，該付款處理器係實施為一應用程式介面（API），用於提供一基於網路互動給一或多個客戶，亦即，實施為一網路服務，以致使通訊可透過使用對該基於網路服務之標準網際網路通訊協定的網際網路而發生，通訊協定諸如HTTPS、TCP/IP等等。此API對於與付款處理器相關聯之一或多個客戶為已知的或可取得的，或可發送/提供給與付款處理器相關聯之一或多個客戶。在一些實施例中，此API可在一註冊或登入程序後提供客戶以取用由該付款處理器所提供的該服務或功能。在一些範例中，該API可經由API使用者介面來提供或發佈以供客戶使用，API使用者介面諸如Swagger，其係為一種眾所周知的API設計與研發工具或介面，用於希望能夠取用一基於網路服務的客戶或其他實體。

該第一態樣的方法包含下列步驟：從在複數個用於開採該交易的礦工中之各個礦工處獲得一費用報價。此步驟回應於來自一客戶之與開採一交易相關聯之開採費用報價的一第一請求而發生。在一些實施例中，來自該客戶的該第一請求可用於開採一單一交易的一費用報價，或用於開採多個交易的一費用報價或多個報價。在一些實施例中，若有多個交易，付款處理器可與一分離的API或端點相關聯，而一起接收或處置（handle）或處理與二或更多（多個）交易相關聯的請求。此等端點亦可處理單一或各別交易。在其它實施例中，相同的端點，亦即先前所提及之與付款處理器相關聯的API，係被使用於單一以及多個交易。據此，從一或礦工獲得的費用報價可為：（一）從各礦工處獲得用於一單一交易的一費用報價，（二）來自各礦工的複數個分離的費用報價，每一者用於多個交易中的各者，（三）將應用至多個交易的各者之一單一費用報價，（四）或一單一聯合（consolidated）費用報價，其覆蓋了由該客戶在該第一請求中所請求之用於開採所有多個交易的開採費用。在一些實施例中，該等礦工為節點，由一或多個處理器來實施，此等處理器受委託來驗證鎖定和解鎖腳本，並且開採交易或將交易寫入區塊鏈，如亦於以上背景說明中所述者。例如，若比特幣中本聰願景（Bitcoin Satoshi’s Vision，BSV）為將要被交易或移轉的加密貨幣或數位資產，則礦工可以稱為BSV節點。該第一態樣的方法包括提供所獲得費用報價給客戶的步驟。在一些實施例中，不論交易關於什麼或涉及的各方，該等費用報價與一目前費用相關，目前費用係由一礦工徵收或收取而用於將交易開採至區塊鏈中。在其他實施例中，可以將費用報價定制（tailored）為基於可以在請求中識別（identified）的一給定交易。在一些實施例中，付款處理器可將所有接收到的費用報價提供給客戶，或者可提供一個或多個推薦費用報價以從所獲得的費用報價中提供給客戶。

有利地，藉由為一或多個客戶，亦即商家或收款者實體，實施提供作為一API的一付款服務，一或多個客戶為諸如類似比特幣SV（BSV）的一加密貨幣數位資產的接收者，第一態樣的方法藉由允許客戶登入或使用由付款處理器所提供的一網路服務而允許付款交易幾乎為即時地開採（寫入區塊鏈）或在礦工解決了工作證明難題（a proof of work puzzle）後盡快開採。藉由提供一目前費用報價，一給定礦工理論上同意或承諾要將該交易加入該給定礦工將要以該費用開採的下一個區塊內。有利地，這代表著客戶，亦即商家實體，不再需要等待礦工的任何確認。因此，可實施與該客戶及各別礦工相關聯的0-conf交易。使用付款服務API之客戶的身分可有利地維持為匿名，同時與該客戶相關聯的所有交易仍可被可靠地藉由一礦工而被開採，該礦工為符合或滿足開採之一選擇或所選擇費用報價的複數個礦工中之一礦工。因此，一各別客戶或商家可受益於與各別客戶相關聯之所有付款的透明度、可靠度與提供不可修改且可驗證記錄的優點，而不需要實施任何額外的處理或網路資源，且可利用所提出付款服務API。

在第一態樣的一些實施例中，回應於來自該客戶的一第二請求以提出一給定交易，該交易涉及或包括在所獲得的費用報價中之一所選擇費用報價，該方法包括發送一請求給在複數個礦工中的一或多個礦工以為該給定交易產生一區塊鏈交易。在一些實施例中，如以上所提及之來自客戶的請求可為提出多個交易而非一單一交易。這是對於在一段給定時間中處理或處置大量交易之一商家實體的一客戶是有利的，在此，一段時間可動態地定義或預先定義為分鐘數、小時數或天數。這有利地允許根據客戶工作負載/性能需求而使與一區塊鏈網路相關聯的無縫擴展伸縮，且可基於交易及/或由該客戶所處置的顧客的數量。在一些實施例中，若有多個交易，付款處理器可與用於提出多個交易之一分離端點相關聯。在其它實施例中，用於付款處理器的相同API端點係使用來處理來自客戶的請求而提出單一以及多個交易。

在一些實施例中，所選擇費用報價係接收自該客戶且被選擇用於給定交易，其接著可與在該客戶與另一節點或實體之間的一付款請求或一付款交易相關，另一節點或實體諸如該客戶之從該客戶處購買之需要用一數位資產付款的商品或服務的顧客。該方法接著包括從滿足所選擇費用報價的複數個礦工中之至少一個礦工接收與區塊鏈交易相關聯的輸出腳本，例如UTXO。例如，在一些實施例中，為滿足費用報價，該至少一礦工應該已提供或與一目前費用報價相關聯，該目前費用報價具有高於或低於所選擇費用報價的值，且在一些案例中，高於所選擇費用報價取決於一或多個規則或取決於與該客戶相關聯的預定標準。該方法接著包括發送一結果給該客戶，該結果包括用於該區塊鏈交易之關於該給定交易的一交易識別符（TxID），該給定交易亦即在客戶與顧客間的付款。

有利地，本揭露的API可實施為一REST（表現狀態轉移）端點，因而允許客戶可使用諸如HTTPS的標準網際網路或基於網路通訊協定來通訊。更進一步地，第一態樣的付款服務有利地使得與一數位資產相關聯的一對應交易可基於所選擇費用報價被瞬間創造並寫入區塊鏈。基於由該客戶所選擇或選定之所選擇費用報價開採交易，或代表客戶的付款處理器，有利地使得在複數個礦工中至少一礦工可幾乎即時地或盡可能快地將一交易寫入該區塊鏈，已經保證一給定礦工將會以匹配符合來自該客戶的所選擇費用報價的一目前費用報價開採該交易。因此，該付款服務API具有允許立即交易或零確認交易（0-conf）的優點，將為該客戶在一區塊鏈中以一安全且可靠的方式被開採，該客戶不需要等待來自一礦工的確認，該確認為一交易確實已被加入一區塊且將會在區塊鏈中被開採。這是因為回應於該第一請求，一給定礦工已經藉由發送要開採該交易之目前費用報價，而指出該給定礦工可進行開採。第一態樣的該方法減少了雙重支付的風險，該風險與允許立即交易可被開採相關聯，由於根據第一態樣開採將基於由該客戶所選定的一所選擇費用報價或為該客戶的所選擇費用報價而發生。因此，只有滿足所選擇費用報價的一礦工才可以開採交易，並且一旦交易被滿足費用報價的一第一礦工添加到與區塊鏈關聯的一區塊中，其他礦工就無法開採該交易。

根據第一態樣之提供由一付款處理器實施一付款服務的該方法的一些實施例，包含基於對該客戶提出之一建議費用的判定而提供所獲得交易開採費用報價，在此所判定費用可為所獲得費用報價的一平均值，或來自複數個礦工之所獲得費用報價的最大值。有利地，在試圖避免雙重支付，該付款處理器可建議該交易係回應於該第一請求而以從該等複數個礦工處所獲得之最高費用值提出。以此方式，所有的礦工可被提供平等的機會以他們個別目前費用報價來開採該交易。然而，若建議為以所有所接收費用報價的中位數或平均值的一費用或高於中位數或平均值來提出交易，有較高報價的礦工可簡單地維持該交易在一記憶池（mempool），諸如一次要記憶體池，且使用其檢查並拒絕該交易的任何雙重支付。類似的優點應用在若所選擇費用報價係基於建議費用報價，或若建議為由客戶所做之選擇的部分。

有利地，該付款處理器建議一費用報價，客戶可接著選定該所選擇費用報價，其在一些實施例中為該客戶願意為提出給該客戶之與一數位資產付款相關聯之交易的最大值。若客戶是一個計算不複雜者，或客戶已經預定由該付款處理器提供的一建議，而非他們自己選擇費用報價，此為有利的。因此，有利地，客戶可以基於建議費用報價來選擇一費用報價，而不是應用新的或單獨的試探法或計算來選擇費用報價，或者任意地選擇費用報價。

在一些實施例中，當從付款服務提供一建議或一建議費用報價，亦即，由該付款處理器提供的API，可提供此建議費用報價，或可提供所有獲得的費用報價，包括建議費用報價，包括一識別符的建議費用報價。有利地，藉由提供一建議以及所接收到的所有費用報價，付款處理器提供給客戶可以使用建議費用報價來提出交易，或也可以從所接收到的費用報價中的其他者選擇一不同的費用報價的選擇。

在一些實施例中，一旦從該等礦工處獲得費用報價，第一態樣的方法包括藉由該付款處理器來將所獲得費用報價分類為服務層級或服務類別。在一些實施例中，這可基於來自各礦工之對一單一或一批次交易所獲得的費用報價。例如，若所獲得費用報價係在一動態地集合或一預定範圍內，那麼為一給定礦工指定一特定服務層級。在一些實施例中，此服務層級可基於一交易費用（例如，此可為由該礦工所報價的費用）以及一中繼費用。此中繼費用為使一給定礦工考慮去驗證一交易，並且隨後將其中繼到區塊鏈網路中對等節點（peer node）的最低費用。在一些案例中，此等費用兩者可為相同的。在大部分的案例中，中繼費用將會低於來自該給定礦工之該報價交易費用。對於一些區塊鏈，由該礦工所報價的費用通常是一組或一預設交易費用，其對於任何交易都維持相同。在一些實施例中，該中繼費用為已知或/或可為一共用的，亦即，對複數個礦工的一預設（default）中繼費。如以上所提及者，在大多數的案例中，此中繼費用係低於交易費用。有時候，其可與交易費用相同。

將在複數個可能服務層級中的一特定服務層級指定給從該礦工處獲得的一費用報價，在一些實施例中，可基於與將在一區塊中被開採的交易相關聯的一優先順序。在一些實施例中，該特定服務層級亦可基於由礦工所供應之雙重支付保護的一程度，以確保與相同交易相關聯之進一步花費資金/數位資產的任何惡意（malign）嘗試會被拒絕。因此，一較高服務層級可指示出在一短時間區段中需要被開採的一較高優先順序交易，諸如少於幾分鐘，亦即，在15至20分鐘內，且具有較佳的雙重支付保護。一較低服務層級可與較長開採時間相關聯，諸如在24至48小時內及/或對於非由給非給定礦工開採的交易不供應雙重支出保護。在一些實施例中，交易的優先順序可由客戶提供，且服務層級係接著基於客戶需求而對所有交易被與此客戶相關聯。在一些實施例中，雙重支付保護可與儲存交易的功能相關聯，該等交易並非由一給定礦工在一次要記憶體池中開採，因此可以實現針對雙重支付的檢查。

在一些實施例中，服務層級的判斷可基於與一組態記錄或檔案登錄相關聯的靜態值與規則，該組態記錄或檔案登錄（file entry）與付款處理器相關聯。在此等案例中，這些用於指定服務層級的值可針對於該付款處理器而被設定。在其他實施例中，亦可能增加新的值或規則或修改組態記錄，以進一步定義與一給定服務層級相關聯的特徵。這可額外地，或在一些範例中，替代一或多個以上描述之用於交易的優先順序與和一給定服務層級相關聯的雙重支付保護。此可接著與為指定服務層級而獲得的費用報價比較。

在一些實施例中，與一給定服務層級相關聯的一交易費用可為由用於該服務層級之該付款處理器來動態地指定或者預先定義為一預設建議或選擇費用。此建議或選擇費用可在一些實施例中連同由一給定礦工所供應的一服務層級指示符，接著被發送給客戶。在一些實施例中，與各服務層級相關聯的費用可能為客戶已知或同意者。例如，基於客戶需求與和該客戶相關聯之用於交易之一所選擇費用的服務層級可在一些案例中為預先同意的。這可以基於一外部服務層級協定或可以在當該客戶註冊要使用由該付款處理器所供應之該服務或功能的時候設定。在一些實施例中，該服務層級與該費用可由該客戶針對各交易選擇，或者在有多個交易的一批次的案例中，針對該批次交易來選擇。

在一些實施例中，由付款處理器預先指定或建議或選擇的一服務層級可基於一或多個服務需求，該服務需求係從該客戶作為第一請求的部分所接收。在一些實施例中，該服務層級係連同所選擇/建議報價（qoute）以及用於創建一區塊鏈交易的請求，一起提供給礦工或使礦工識別。

有利地，基於接著將會與個別礦工相關聯的一組定義的服務層級的開採費用分類，確保透明度以及應用於開採交易的開採費用之數量的標準化，以及與在一指定服務層級開採該交易之一給定礦工相關聯之效能的透明度。隨著將在一區塊鏈上被發佈或提出之交易的數量隨著區塊鏈的使用增加，此等定義數量服務層級的分類確保了對於服務預期費用收費之透明度與較佳的能見度，連同肯定的是，礦工提供了針對雙重支付的所需保護層級。這對於客戶數量成一指數增加來說，確保無縫縮放是重要的，礦工與每個客戶/礦工之由與一區塊鏈相關聯的付款處理器處置的交易。目前，對於所有現有的礦工收費機制，無法保證或無法看到所報價的收費率將實際上提供0-conf的安全性。

在一些實施例中，一旦基於一預設或預定或已知中繼費用而被該付款處理器分類，此等分類將會被使用或應用在用於未來交易的礦工上。此外，有利地此等分類亦會促進礦工對於開採一交易供應較佳或較有競爭性的費用報價，因此他們可能會與一不同或符合一給定客戶之較佳服務層級相關聯，同時堅持開採符合費用報價的交易，亦即，第一個看見的開採。

更進一步地，有利的服務層級分類允許客戶與礦工可以基於服務層級而在交易之間區別。目前，不存在可以區分交易以及為不同的客戶以不同的費率之不同類型的交易的機制。此外，有利地，以上描述之由付款處理器所進行之基於服務層級的分類允許或者使得此等分類可不需要對礦工節點組態作任何修改而實施。這是因為所提出之與服務層級相關聯的機制外在化了（）費用評估給付款處理器，而非礦工或使用付款處理器的API之驗證模式，且因此容易實施，應用於客戶與礦工，並且極大地幫助了諸如 BSV區塊鏈之一區塊鏈的可擴展性。

在一些實施例中，該方法包含了驗證提供一各別費用報價的複數個礦工中之一給定礦工的身份的步驟，其中，該身份係基於與該給定礦工相關聯的一數位簽章所驗證。可以使用包括與各個礦工相關聯的一私鑰和一公鑰（或公共位址）的加密密鑰對，來驗證費用報價確實源自該給定礦工，亦即，由一私鑰簽署的資料可以僅可使用相對應的公鑰來恢復或驗證。如果驗證係基於數位簽章，可以使用和實施標準的公共密鑰基礎結構（PKI）技術。

在其他實施例中，關於該給定礦工的一識別符可額外地或替代地被使用來驗證該礦工的身份。在一些實施例中，該方法包括付款處理器，諸如一MinerID。在一些實施例中，該識別符可與對於該給定礦工的一信譽指示符相關聯。在一些實施例中，MinerID可基於一開採池，一給定礦工為開採池的一部分或該開採池對該給定礦工是特定的。信譽指示符與一礦工效能的衡量有關。例如，在一些範例中，此聲譽可基於該給定礦工在過去如何以所報價費用執行或開採交易。例如，信譽指示符可以指示一良好的信譽，例如，若該礦工規則地以該礦工所報價的費用或在一可接受範圍內的費用開採交易，則值較高。在一些實施例中，一礦工的聲譽分數或指示符可以由通訊式耦接於該礦工的至少一個付款處理器來計算、維護和管理。

在一些實施例中，由該付款處理器實施的第一態樣的方法可包括基於一礦工簽章對從複數個礦工中之一給定礦工所獲得之費用報價之驗證的步驟，礦工簽章係不同於使用PKI技術之用於驗證給定礦工之身分的數位簽章。由該付款處理器使用於驗證步驟之該礦工簽章有利地指示或作為礦工承諾要以提供給付款處理器之個別費用報價開採該交易。礦工簽章的存在亦可有利地作為確認礦工將會拒絕任何衝突交易。據此，基於一礦工簽章的驗證步驟有利地作為一保證，此保證為該給定礦工將會把交易包括在要開採的一區塊中、且他們不會將任何衝突交易包括在內。在一些實施例中，基於由給定礦工提供的擔保來監控一給定礦工的效能可定義或影響與該給定礦工相關聯的礦工聲譽或分數。

在一些實施例中，由複數個礦工中之各礦工提供的費用報價係提供給該付款處理器以作為包括該費用報價值的資料類型（datatype）。在一些實施例中，資料類型為JavaScript 物件表示法（JSON）物件格式。

在一些實施例中，於該付款處理器處從該至少一礦工處所接收之輸出腳本為針對該至少一礦工之與一記憶池（mempool）相關聯之未花費的交易輸出（UTXO），該UTXO包括用於該區塊鏈交易的該交易識別符（TxID），其中，該區塊鏈交易關於在客戶與顧客之間的數位資產付款。

在一些實施例中，為了要讓客戶可以有利地識別或追蹤與顧客之給定付款交易相關之區塊鏈交易，或與該客戶相關聯的任何交易，該方法包含發送一請求至複數個礦工的步驟，以獲得對於該交易識別符之一對應區塊鏈交易，此請求係由該付款處理器回應於與來自該客戶之一交易識別符相關聯的一狀態查詢而發送給至少一礦工。作為回應，該付款處理器獲得來自複數個礦工中至少一礦工在先前產生之對應區塊鏈交易。基於由該至少一礦工對區塊鏈交易的開採狀態，該方法包括發送一狀態結果的步驟，該狀態結果關於所獲得區塊鏈交易，與給該客戶的交易識別符相關聯。該結果可指示出若區塊鏈交易已經被開採，亦即，完成，或者因為一些理由被拒絕，或者因為它可能在此給定礦工之前已經被在複數個礦工中的另一礦工開採而無效。這有利地在對一特定交易之開採已經被一不同礦工完成的狀況下避免了雙重支付。在一些實施例中，該礦工可維護尚未被添加到一區塊中的或者在一次要記憶池中被開採的交易，該次要記憶池可以是與礦工相關聯的主記憶池分離的一個替代，或者作為一替代、或額外的記憶池。該次要記憶池可以是一臨時記憶池，因此可以對TxID檢查雙重支付。這有利地確保即使交易未被一給定礦工所開採，其仍然被維持在次要記憶池內且被使用來在未來檢查並拒絕雙重支付。對於持有一交易可能會有一時間限制，該交易為在一給定礦工的次要記憶池內未被該給定礦工開採或意欲開採的一交易。在一些實施例中，儲存在該次要記憶池的交易可能與到期的一時間相關聯，在該時間後他們將被清除。在一些實施例中，可以有與該礦工相關聯的一分離費用，用於儲存未被該給定礦工於其個別次要記憶池內開採的交易。如以上所提及，在費用報價被分類成為服務層級的狀況中，次要記憶池係與提供雙重支付保護的礦工相關聯。

在一些實施例中，如以上所提及之來自客戶的請求可被用來查詢在一批次中一起的多個交易的狀態，而非每次單一個交易。類似於提出多個交易給區塊鏈來開採；一起在一單一狀態查詢請求中查詢多個交易是有利的，特別是若客戶為一商家實體，其處理或處置一大量的交易且已經一次提出要處理的多個交易。這有利地允許系統無縫地根據客戶的需求來伸縮，且可基於交易及/或由該客戶所處置之顧客的數量。若有多個交易，付款處理器可與分離的端點相關聯，該等端點在一些實施例中係用於查詢多個交易。在其他實施例中，用於付款處理器之相同的端點係使用於來自該客戶的請求以查詢單一以及多個交易。

在一些實施例中，第一態樣的方法進一步包括提供一應用程式介面（API）轉換器的步驟，其係與用來進行下列步驟的付款處理器相關聯，付款處理器進行下列步驟：接收對於費用報價的第一請求，用於提出與一客戶之數位資產付款相關聯之交易的第二請求，及/或用於查詢來自該客戶之該交易的超文本傳輸協議安全（HTTPS）格式的狀態請求；且接著在發送遠端程序呼叫（RPC）給複數個礦工前轉換此等為一遠端程序呼叫（RPC）格式。這是有利的，因為它允許客戶可使用網路式API經由HTTPS傳遞（communicate）與區塊鏈相關聯的請求，並且無縫地提供互通性（interoperability）給複數個礦工，該等複數個礦工於網路服務不使用網際網路通訊協定標準進行通訊。例如，所有目前的BSV礦工或使用遠端程序呼叫的實施。在此實施例中所實施的API轉換器不限於HTTPS到RPC的轉換，且反之亦然，或其他網路式的通訊協定到由個別礦工所支援的替代傳遞通訊協定，或用於一給定的加密貨幣或可被設想到之數位資產的網路。在反向流程路徑中，第一態樣的方法亦包括從複數個礦工中的一個或多個礦工處接收與對應區塊鏈交易相關聯之RPC格式的回應，且據此使用HTTPS為客戶轉換各別回應。因此，當客戶（收款人）與礦工使用不同的無線資料通信協定和機制時，藉由付款處理器有利地實施所提出的介面使得能夠進行無縫地通訊以將交易提出給區塊鏈。

在一些實施例中，可提供與付款處理器相關聯的一API出入口（Gateway）。在此等實施例中，以上提及的API轉換器可與API出入口相關聯。此外，API出入口亦可在一些實施例中於一或多個計算裝置中實施以進行或回應於包括但不限定於下列一或多個的功能： -交易的快取 -在礦工節點故障時進行彈性功能 -保留一個或多個端點或URL的記錄，其可被使用來發送訊息或通知至付款處理器及/或客戶及/或礦工節點，或由付款處理器及/或客戶及/或礦工節點發送訊息或通知 -提供彈性特徵以包括持續追踪由於某種原因未能提出的交易。在一些範例中，這可以被包括在由該付款處理器處持有或設置的一可組配參數；以及一種可清除那些已過期的被追踪交易的機制。該API出入口亦可在失敗情況下，與用於重新提出交易的功能相關聯，因而提供對真正交易進行錯誤處置並區分雙重支付的功能。

根據一第二態樣，本揭露提供一種用於處理與一區塊鏈相關聯之交易的方法，該方法係由與一客戶相關聯的一或多個處理器來實施，該客戶係通訊式耦接於為該客戶實施一付款服務的至少一付款處理器。在一些實施例中，該付款處理器係組配為可實施以上提出之第一態樣的方法以及相關聯的實施例。由該客戶，亦即商家所實施之該第二態樣的方法包含下列步驟：發送一第一請求至該至少一付款處理器中的一付款處理器，該請求關於將經由該付款處理器從複數個礦工處獲得之用於開採一交易或複數個交易的一或多個費用報價。如以上所提及者，所獲得的費用報價與開採任何交易相關，或可為對於來自一顧客之關於一數位資產付款的一給定交易為特定的。如以上所提及者，該第一請求亦可指示開採所需的一服務層級。

在該第二態樣的一些實施例中，回應於從該付款處理器接收到的一或多個費用報價，該方法包括從一或多個所接收費用報價中選擇一費用報價。如在第一態樣中所提及者，所選擇費用報價可為或可不為基於由該付款處理器所作出的一建議。該第二態樣的方法接著包含請求及/或處理來自該顧客的數位資產付款，與所選擇費用報價相關聯的請求。在一些實施例中，此請求係類似於一付款情求，或由該客戶對一顧客的一數位資產付款所發出的一發票。例如，該客戶可為與一數位錢包相關聯的一咖啡店終端，且該顧客可回應於此請求付款，為咖啡支付例如，2 satoshis，該顧客亦與一數位錢包相關聯。由於現在已選定了所選擇的費用報價，因此這可以被添加到來自顧客的付款請求中。該方法接著包括提出用於一給定交易的一第二請求，與先前提及之給付款處理器之顧客付款相關聯，該提出係基於為開採該給定交易的所選擇費用報價。在一些實施例中，所選擇費用報價係清楚地指示或被包括在該第二請求中，因此付款處理器有利地可以識別能以所選擇費用報價或低於所選擇費用報價開採該交易的礦工，或額外地，或可替代地，讓礦工能夠確定他們是否滿足所選擇費用報價。

如以上所提及者，在一些實施例中客戶可基於從付款處理器所接收之最高費用報價中的值來選擇一費用報價，或可以在所接收到的費用報價之值的平均值或中位數或靠近之處選擇一費用報價。與任一選擇相關聯的優點和先前討論者相同，亦即，一最大值允許所有礦工都有機會進行開採，而其他值將藉由可以在所選擇報價或較低報價開採一交易的方式將開採限制於滿足費用報價的礦工，同時無法開採該交易的此等礦工（例如，如果報價太高）仍可在諸如一次要記憶池的一暫時儲存器內維持區塊鏈交易的一紀錄，因此這可以被使用來驗證給定交易的任何雙重支付。

在第二態樣的一些實施例中，該方法亦包括接收用於一區塊鏈交易的一交易識別符，其係由至少一礦工所產生，該區塊鏈交易對應於所提出交易，亦即，在該客戶與顧客之間的交易。在一些實施例中，該方法包括發送與所獲得交易識別符相關聯的一狀態查詢；以及獲得對應於該交易識別符之對該區塊鏈交易的一狀態結果。

與第二態樣相關聯的優點係關於以上關於第一態樣所討論者。第二態樣為第一態樣的補充，但描述了由客戶實施的方法，請求將被寫入區塊鏈的一交易。在一些實施例中，實施第二態樣之方法的客戶可以與至少一個付款處理器通訊，該至少一個付款處理器係被組配為可根據第一態樣的方法將付款服務實施為付款API。

此外，本態樣的方法有利地允許客戶可選取一費用報價以提供給付款服務，其提供了客戶或商家控制或影響的確定性會以即時的方式以一給定開採費用開採他們交易的確定性，因而提供更高的安全性、互操作性（interoperability）、可靠度、效率和即時性給將使用建議付款服務或付款API的一客戶開採的交易。

如以上所提及者，由於藉由付款處理器實施的付款服務為一API，在一些實施例中，來自該客戶的該第一請求及/或狀態查詢為一HTTPS GET請求，並且其中，該第二請求為一HTTPS POST請求。因此，有利地，客戶可使用標準網際網路與網路式通信通訊協定來請求將被開採而進入一區塊鏈的一交易。在一些實施例中，與第一及/或第二請求相關聯的資料，及/或來自該客戶的狀態查詢，係以JavaScript 物件表示法（JSON）物件格式來提供。

根據一第三態樣，本揭露提供一種用於處理與一區塊鏈相關聯之交易的電腦實施方法，該方法係由與複數個礦工中之一個礦工相關聯的一一個或多個處理器來實施，其中，該等複數個礦工係與為一客戶實施一付款服務的至少一付款處理器通訊式耦接。在一些實施例中，付款服務係基於以上相關於第一態樣的方法由該付款處理器而實施。在一些實施例中，該客戶係組配為可實施如與以上討論之第二態樣相關聯的方法。第三態樣的方法，由複數個礦工中之一礦工實施時，包含下列步驟：回應於對與該客戶相關聯的一交易的一費用報價之一第一請求，提供關於該礦工要在該區塊鏈中開採一交易的一目前費用報價。在一些實施例中，該費用報價可作為一資料類型提供給與該客戶相關聯的付款處理器。如以上所討論者，該第一請求可關於用於任何交易或複數個交易或可特別用於在該客戶與一顧客間之一特定交易的一目前費用報價的一請求。

在該第三態樣的一些實施例中，回應於來自該付款處理器代表該客戶的一第二請求，該第二請求關於在一區塊鏈中提出一給定交易，該給定交易係基於一所選擇費用報價，在此該區域可由如在第一與第二態樣中提出之該客戶決定，該方法包含下列步驟。基於與給定交易相關聯的所選擇費用報價符合對該礦工的目前費用報價的一判定，亦即，所選擇費用報價係為目前報價或在目前費用報價以內，給定礦工接著產生與該給定交易相關聯的一對應區塊鏈交易。該方法亦包括為所創造的區塊鏈交易產生一輸出腳本（UTXO），添加所產生的輸出腳本至與該礦工相關聯的一記憶池，並且發送該輸出腳本至該付款處理器，其中，該輸出腳本包括與對應區塊鏈交易相關聯的一交易識別符TxID。在一些實施例中，回應於與該交易識別符相關聯的一狀態的一請求，該礦工包括基於該對應區塊鏈交易的一目前開採狀態而回傳一結果。

與第三態樣相關聯的優點為如同以上關於第一與第二態樣中所討論者相關。第三態樣為第一與第二態樣的補充，但描述了複數個礦工中之一礦工所實施的一方法，與該付款處理器耦接以為該客戶建構一交易，其可被寫入區塊鏈。實施第三態樣之方法的礦工在一些實施例中可與至少一付款處理器通訊，組配為可根據第一態樣的方法來將付款服務實施為一付款API。

在一些實施例中，提供目前費用報價的步驟、及/或發送輸出腳本的步驟，及/或回傳結果的步驟接實施為一遠端程序呼叫（RPC）。這是有利地，若例如像是BSV比特幣網路，礦工係組配為可經由RPC來無線對應。在一些實施例中，該第三態樣的方法為了額外的安全性，可包括在透過一無線通訊網路為該客戶傳遞至該付款處理器之前，發送來自該礦工的RPC至一節點連接器的步驟，以及在礦工池或網路中將資料流串流，亦即，複數個礦工與該付款處理器相關聯。更進一步地，有利地，節點連接器可提供在與該付款處理器相關聯的一API轉換器及在該池中的一或多個礦工之間的一安全通訊通道（channel）。

在一些實施例中，基於與該給定交易相關聯之所選擇費用報價不符合該礦工的目前費用報價的一判定，例如，若目前費用報價高於所選擇費用報價，該方法包括添加與該區塊鏈交易相關聯的一輸出至一次要記憶池，其為與該礦工相關聯的一次要暫時記憶池。如以上所提及者，這可以在此儲存一特定預定時間期間，因此礦工節點可使用此等暫存入口（entry）以檢查且有利地確保不會有與該給定交易相關聯的雙重支付。

本揭露亦提供一種電腦系統，其包含經由一無線通訊網路而與至少一客戶及至少一礦工通訊式耦接的一付款處理器，該付款處理器與用於將來自該客戶的HTTPS請求至該等礦工的RPC請求之轉換的一API轉換器相關聯，且反之亦然，在此該付款處理器係根據第一態樣所實施。該電腦系統亦包括經由該無線通訊網路而與該付款處理器通訊式耦接的一客戶，且可與至少一顧客通訊，在此，該客戶係根據第二態樣之計算裝置所實施。該電腦系統亦包含複數個礦工，各礦工經由該無線通訊網路與該付款處理器通訊式耦接，在此各礦工係根據該第三態樣所實施。

在一些實施例中，提供包含一處理器與記憶體的一計算裝置，該記憶體包括可執行指令，其作為由該處理器執行之結果，致使該裝置進行以上討論之態樣及/或實施例。

在一些實施例中，提供一電腦可讀儲存媒體，其具有可執行指令儲存在上，作為由一電腦系統的一處理器執行之結果，致使該電腦系統進行以上討論之態樣及/或實施例。

現在一些特定實施例現在參照附加圖式以例示說明的方式描述，其中類似的標號指稱類似的特徵。第一態樣—付款處理器

圖1關於本揭露的第一態樣且描述一種由一付款處理器來進行的方法，以如以上所討論者為一客戶實施一付款服務。付款處理器係通訊式耦接於一客戶或複數個客戶，且亦與複數個礦工耦接，該等複數個礦工可包括多於一個網路的礦工或多於一個礦工池。在一些實施例中，該付款處理器可為該客戶的一部份或與該客戶聯合實施。若客戶為一個計算複雜的商家銷售點（POS）終端，這是為真的。本揭露的態樣與實施例係設想來涵蓋此等兩者實施，亦即一遠端付款處理器或作為客戶的一部份。圖4中可見一範例系統架構，其在此稍後會解釋。

在圖1中所描述的範例場景中，關於獲得複數個開採費用報價、基於從所獲得複數個開採費用報價中的一所選擇費用報價提出一交易、以及發送關於一交易識別符的一狀態請求的步驟的實施例全都描述為接續發生，且在圖1的流程圖中被描述為一單一程序。然而，本揭露與第一態樣不應被認為是如此的限定。在以下描述之步驟102至106中所描述之在一第一請求中關於獲得費用報價可分離地且獨立於剩餘步驟而實施。類似地，從步驟108至114關於在一第二請求中提出一交易的步驟亦可分離地實施，且於不同於獲得費用報價之較早步驟的的時間來實施。以同樣的方式，從步驟116開始之關於交易狀態查詢的步驟可以在使客戶知道交易標識符、並且無需遵從圖1的順序後的任何時間而實施。僅為了便於解釋和理解，在此順序地顯示出之所有步驟，在任何情況下都不應被認為本揭露為限於這樣的順序或場景。

步驟102描述從一客戶接收用於與在一區塊鏈中開採一交易相關聯之開採費用報價的一第一請求。如稍早所提及者，該第一請求亦可與複數個交易相關。為了易於解釋與理解，圖1將以關於在與該客戶相關聯的該第一請求中之單一交易來解釋，但是本揭露不以任何方式被如此限制。此步驟表示了來自複數個礦工的開採費用報價的收集，用於代表該客戶開採一交易。該交易係通常關於發生在客戶，亦即一商家計算資源或實體，與一顧客實體之間的一數位資產付款。如先前所提及者，該第一請求係從該客戶經由或使用HTTPS通訊協定所接收，且為JSON形式。該付款處理器為該客戶實施一付款介面為一應用程式介面（API），且因而可如API實施為一網路服務地接受且處理HTTPS。該API端點對客戶為可用的。於該第一請求中有在多個交易的案例中，可使用同一API端點或一分離的API端點於該付款處理器。

例如，在一些實施例中，該付款處理器可使用一標準式界面設計諸如一REST介面來實施付款服務。REST（表現狀態轉移）是一種用於研發網路服務和網路式互動的建築風格。REST API設計標準可以使用下列命令來處理HTTPS請求和通訊：

命令	GET	POST	PUT	DELETE
資源	讀取	創造	更新	刪除

在此將主要討論GET與POST HTTPS請求，但是本申請案不限於這些命令。在步驟102中，付款處理器接收到的第一請求可以是GET getFeeQuote形式的HTTPS請求。

在REST ATP的前後文中的一資源為一種物件，其具有與其他資源相關聯資料、關係的類型，以及在其上運作的一組方法。在一些實施例中，該付款服務係由諸如一API實施而由該付款處理器來提供，以取用一區塊鏈或分散式帳本的狀態，區塊鏈或分散式帳本諸如比特幣（BSV）區塊鏈，且可經由一應用程式介面觸發將會改變其狀態的運作，並且將其暴露作為一REST API。因此，該付款處理器可被認為是用於一或多個客戶的一REST端點。僅為了易於解釋，各處將討論之一個客戶（或商家）和一個付款處理器，但是本揭露不限於此。該客戶可因此與該付款服務經由HTTPS通訊，且更進一步地，該客戶可有利地匿名取用該付款處理器或由該付款處理器實施的該付款服務。當有多於一個客戶以及多於一個付款處理器時，客戶在一些實施例中可負責基於，例如任何該客戶與運行付款處理器（Payment Processor）之一或多個第三方達成的協議，而瞄準（target）或與正確或意欲付款處理器或REST端點接觸。

步驟104描述從複數個礦工中的各礦工獲得用於開採該交易的一費用報價。在此步驟中，與該付款處理器耦接的所有的礦工可由該付款處理器輪詢（polled）或接觸、並且詢問以回傳用於開採一交易的一目前費用報價，亦即，在驗證該鎖定與非鎖定腳本之後，將該交易寫入區塊鏈。目前有些區塊鏈網路諸如BSV網路經由遠端程序呼叫（RPC）來支援通訊。因此，在此案例中，與該付款處理器相關聯的一API轉換器係被使用來轉換HTTPS第一請求，亦即GET getFeeQuote，成為一RPC第一請求，亦即RPC getFeeQuote()，且反之亦然。此等轉換在需要支援此等BSV節點實施或僅支援ROC的其他實施的實施例中是必須的。如以上所提及者，API轉換器可為與該付款處理器相關聯之API出入口或出入口處理器，在此HTTP/RPC轉換僅為由一API出入口供應的其中之一種功能。發送至該等礦工之RPC形式的getFeeQuote()目的為通知客戶由各礦工所收取的費用。不需要輸入參數，但一RPC介面可能會需要以關連於RPC getFeeQuote()的方式來實施，因此，此命令回傳來自各礦工之JavaScript 物件表示法JSON物件形式的一資料類型，亦即MinerFeeQuote，其包含從各礦工處收集到之與費用相關的資料。

關於從各礦工處收集到之所獲得費用報價的資料可被定義為JSON物件，如在以下範例中所給定者。

從各礦工回傳之JSON物件FeeQuotes 係顯示如下。雖然顯示一單一交易的範例，本揭露並非如此限制，並且表示多個交易的採礦費用的費用報價也適用相同的內容： [ {# MinerFeeQuote “MinerID” : ＜Alphanumeric＞, # If MinerID is null (empty) then “NO-ID” is defaulted “CurrentHighestBlockHash“ : ＜Alphanumeric＞, “MinerSignature“ : ＜Alphanumeric＞, # Includes Current Block Hash + Block Height “SignatureTimestamp“ : ＜UTC Timestamp＞, # Miner guarantees fee from this time until superseded “MinerReputation” : ＜Alphanumeric＞, # If this is blank (null), return “Unknown” [ { # FeeTypes “FeeType” : ＜“SPB“ || “SPDB“ || …＞, # Satoshis-per-byte, Satoshis-per-data-byte, etc “CurrentFee” : ＜Floating Point Number＞, “Expiry” : ＜Integer＞, duration or date/time at which Fee expires, “ FeeOnExpiry” : ＜Floating Point Number＞, # If Expiry is 0 then this should be set to CurrentFee “GuaranteeFee“ : ＜Floating Point Number＞ # Guarantees to process Tx at this fee (none if 0) “KeepInMempoolFee” : ＜Floating Point Number＞, # Fee for retaining Tx in secondary mempool }, {…} ] “Margin“ : ＜Floating Point Number＞, # Acceptable margin for error due to use of FP numbers “APIversion“ : ＜Numeric＞ # API version NN.nn (major.minor version no.) }, { # MinerFeeQuote “MinerID” : ＜Alphanumeric＞, # If MinerID is null (empty) then “NO-ID” is defaulted “CurrentHighestBlockHash“ : ＜Alphanumeric＞, “MinerSignature“ : ＜Alphanumeric＞, # Includes Current Block Hash + Block Height “SignatureTimestamp“ : ＜UTC Timestamp＞, # Miner guarantees fee from this time until superseded “MinerReputation” : ＜Alphanumeric＞, # If this is blank (null), return “Unknown” [ { # FeeTypes “FeeType” : ＜“SPB“ || “SPDB“ || …＞, # Satoshis-per-byte, Satoshis-per-data-byte, etc “CurrentFee” : ＜Floating Point Number＞, “Expiry” : ＜Integer＞, duration or date/time at which Fee expires, if 0 fee is not guaranteed to not change “FeeOnExpiry” : ＜Floating Point Number＞, # If Expiry is 0 then this should be set to CurrentFee “GuaranteeFee“ : ＜Floating Point Number＞ # Guarantees to process Tx at this fee (none if 0) “KeepInMempoolFee” : ＜Floating Point Number＞, # Fee for retaining Tx in secondary mempool }, {….} ] “Margin“ : ＜Floating Point Number＞, # Acceptable margin for error due to use of FP numbers “APIversion“ : ＜Numeric＞ # API version NN.nn (major.minor version no.) }, MinerFeeQuote may repeat as necessary – one per miner ]

在相同實施例中的JSON FeeQuotes含有一陣列的礦工詳情與所收取費用，而MinerFeeQuote是一個JSON結構，其含有礦工和從單一個礦工收到的費用資料。以上的JSON物件中的一些術語解釋如下。

CurrentHighestBlockHash 可使用作為一標示器，以在getFeeQuote()被呼叫時，識別區塊鏈在此成長之在該點的區塊雜湊。

MinerSignature 可含有礦工的簽章，如以上所討論者，該礦工同意要保證此交易。這與使用來驗證一礦工之身分的一數位簽章是不同的。藉此，一礦工可保證該礦工將會很快將該交易包括在一區塊內，且選擇性地不會將任何衝突的交易包括在內。若一礦工不願意保證此交易，那麼可將其設定為空（Null）。

SignatureTimestamp 指示一時間，礦工保證要在此時間以所描述目前費用來開採一交易，亦即該費用是從此時間點起得到保證，直到被取代（superseded）為止。如果客戶端作出一隨後呼叫getFeeQuote()，則此時間被取代。

MinerReputation 關於一礦工效能的量測，亦即一礦工以承諾或報價目前費用執行交易的情況為如何。各付款處理器可計算、維持與管理信譽分數/指示符。

Miner ID 可為一兩部分資料，其係當開採一個區塊時被添加到一個幣庫（coinbase）交易中。若不存在礦工ID，則付款處理器可以用「Null」的礦工ID標記該礦工，或者簡單地留白。

在各個MinerFeeQuote,內，一陣列的FeeTypes物件可被使用來擷取目前可取得的各種費用類型。在未來費用類型可被引入，而不需對由付款處理器提供的getFeeQuote()介面進行任何更改。所有交易可能具有一個FeeTypes陣列。

步驟106描述藉由該付款處理器提供所獲得費用報價給該客戶。在一些實施例中，這可包括由該付款處理器所決定的一建議費用報價。如以上所提及之關於第一態樣者，此步驟可包括藉由一API轉換器從RPC至HTTPS的一轉換，以致使該客戶可以使用網路式API來取用該等細節。

在步驟108中，從該客戶處接收一第二請求，該第二請求可為用於提出關於從所獲得費用報價中一所選擇費用報價的一給定交易的一請求。該給定交易在一些實施例中，係基於一數位資產付款，其係由一顧客回應於來自該客戶的一付款請求，而對該客戶所做出。例如，這可以是聰（satoshis）或其它類型的數位資產付款，如果客戶是在一咖啡店的商家終端，則可以換一杯咖啡。在此步驟中，該客戶經由藉由該付款處理器實施之付款服務API來請求將此數位資產付款寫入區塊鏈。

如以上所提及者，來自該客戶的第二請求在一些實施例中，可為提出多個交易的一請求。關於提出多個交易的請求，可被發送至相同付款處理器API或與該付款處理器相關聯的另一端點。與該付款處理器相關聯的所有端點可為客戶所知或提供給客戶。在多個交易的情況下，所選擇費用報價可以與開採所有的多個交易相關聯，亦即，對於在該批次之多個交易中開採10個交易的所選擇費用為10聰；或可為用來以所選擇費用報價開採多個交易中各者的所選擇費用，亦即，所選擇費用為1聰/交易來開採在該批次中的10個交易中之各交易。

在多個交易的案例中，第二請求的本體之形式可為原始交易（raw transactions）的一陣列。此端點係使用來發送多個原始交易至一礦工以被包括在該礦工作創建的下一個區塊中。

Request本體之一範例形式係顯示如下：POST /mapi/txs [ "010000000135ff04d97f7f5d214b66dcc401cee7967c.......", "0100000001569c0e1df6cdbbc99bdfbc25dc153ce5e........", "etc …" ]

範例回應可以為：{ "apiVersion":"string", "timestamp":"string", "errorCount":"integer (count of where txn returnResult ＜＞ success)", "txs":[ { "txid":"string", "minerid":"string | null", "returnResult":"string", "resultDescription":"string", "currentHighestBlockHash":"string", "currentHighestBlockHeight":"integer", "txSecondMempoolExpiry":"string", "confirmations": "integer (0 for unconfirmed)" } ] }

在第二交易中的所選擇費用報價可基於由該付款處理器所作出的一建議，或可由該客戶對一或多個交易而被選擇。

如以上所提及者，所選擇報價可基於所有所獲得費用報價的一平均值或最大值。

如以上所提及者，在一些實施例中，所選擇費用報價可以是基於一服務層級的一者，在此，所獲得費用報價被該付款處理器分類為多個服務層級。

在一些實施例中，將會與各服務層級相關聯之用於開採的費用與特徵/功能可由該付款處理器預先定義。接著，基於一給定客戶的需求，一服務層級以及用於開採的相關聯費用（所選擇費用報價）將會指定給該客戶。該客戶需求可基於該客戶處置的交易類型。服務層級可預先指定或預先同意，例如，基於一外部服務層級協議。因此，預先指定將基於與交易相關聯的優先順序以及基於由滿足所選擇費用報價/服務層級所之該（等）礦工所提供之免於雙重支付的安全保護的層級。

因此，用於將被開採之該交易的與一服務層級相關聯之費用，可由該付款處理器預先定義且由該客戶同意。若一服務層級或費用沒有被該客戶選擇，那麼被分類為多個服務層級之所獲得費用報價的詳情可提供給該客戶來選擇，各服務層級與其個別費用相關聯 。

可替代地，對於服務層級及相關聯費用也可能如同所選擇費用報價由該付款處理器所建議。服務層級之此等建議可基於來自與該客戶相關聯之較早交易的學習資料與統計。或在一些案例中，建議係由付款處理器基於該客戶的輸入所提供。

如以上所提及者，在一些實施例中，為了開採一或多個交易的一礦工，該等服務層級被基於所獲得費用報價與最低可能費用，亦即中繼費用，指定給礦工。因此，有利地不同費用可應用於不同交易類型或使用案例。交易類型或服務需求在一些實施例中可由該客戶獲得。

服務層級亦可直接地由付款處理器基於從該礦工處所獲得之交易費用報價的知識、以及對該礦工之中繼費用的知識所決定。這使得付款處理器可分類費用，且無論該客戶是否指出一最低服務層級，選擇性地甚至為該客戶建議費用。一旦其獲得費用，該付款處理器可通知為該服務層級的客戶，其為該交易的任何所選擇/建議費用中可預期者。這些可能包括與服務層級相關聯的屬性。

以下的表格提供了一矩陣一矩陣的一範例，該矩陣矩陣可由該付款處理器使用來基於中繼費用與交易（txn）費用而將費用分類成服務層級（SL）0至4。在此範例中，費用的單位係以每個位元組幾聰表示，然而，本揭露不限於此。對於某些交易，此可以每個位元組幾聰來表示。可以使用其他數位資產或加密貨幣。此矩陣可以儲存在與付款處理器相關聯的靜態或動態組文件或入口（entry）中，因此可以基於此邏輯對服務層級進行分類。

在以下的範例中，對服務層級考量兩個特徵（一）交易的優先性以及（二）對雙重支付提供的保護。然而，本揭露並非如此限制，且服務層級也可基於其他特徵與屬性。

在此範例中：

對於服務層級（SL）0，亦即SL0，沒有礦工保證會開採且沒有雙重支付保護，在此minRelayrfee ＜ 0.20 聰，亦即不保證任何開採服務。沒有額外的雙重支付保護，因為費用不涵蓋將不會被包括在一次要記憶池開採的交易以檢查雙重支付。

SL1為低優先次序，若(minRelayrfee) =＜ 0.20 聰且 (txnfee) =＜0.3聰，沒有雙重支付保護，亦即，該交易將不會比在一開採佇列中其它交易更早開採，且因此可能在（例如）下一個24小時或左右才被開採。沒有額外的雙重支付保護，因為費用不涵蓋將不會被包括在一次要記憶池開採的交易以檢查雙重支付。

SL2中等優先次序，若(minRelayrfee) = 0.25 聰且 (txnfee) =＜ 0.4 聰，存在雙重支付保護，亦即，交易比在一開採佇列中的一些、但不是所有或大部分的其它交易有優先性，且因而可在（例如）12至24小時期間或左右被開採。有額外的雙重支付保護，因為費用有涵蓋將不會被包括在一次要記憶池開採的交易，其將被使用來檢查雙重支付。

SL3高等優先次序，若(minRelayrfee) ＞= 0.25 聰且(txnfee) = 0.5 聰，存在雙重支付保護，亦即，交易比在一開採佇列中的大部分的其它交易有優先性，且因而可在（例如）12小時期間內或左右被開採。有額外的雙重支付保護，因為費用有涵蓋將不會被包括在一次要記憶池開採的交易，其將被使用來檢查雙重支付。

SL4最高等優先次序，存在完整雙重支付保護，在此txnfee ＞ 0.5聰，亦即，交易比在一開採佇列中的所有其它交易有優先性，且因而可在（例如）2小時期間或左右被開採。有額外的雙重支付保護，因為費用有涵蓋將不會被包括在一次要記憶池開採的交易，其將被使用來檢查雙重支付。

在此案例中，以上提及之在步驟104中提出的JSON物件FeeQuotes 亦可包括：[ { # MinerFeeQuote “minerID” : ＜Alphanumeric＞, # Null indicates no minerID “currentHighestBlockHash“ : ＜Alphanumeric＞, “currentHighestBlockHeight“ : ＜Alphanumeric＞, “timeStamp“ : ＜UTC timestamp＞, # Fee timeStamp “minerSignature“ : ＜Alphanumeric＞, # Includes Current Block Hash + Block Height “minerReputation” : ＜Alphanumeric＞, # Can be Null [ { # FeeTypes “feeType” : ＜“SPB“ || “SPDB“ ＞, # Satoshis-per-byte, Satoshis-per-data-byte, etc { # currentFee # Fee unit tuple (x satoshis / y bytes) “satoshis“ : ＜Unsigned Integer＞ “bytes“ : ＜Unsigned Integer＞ } “expiry” : ＜Integer＞, expiry datetime as set by miner “feeOnExpiry” : ＜Floating Point Number＞, # If expiry is 0 then this should be set to currentFee “keepInMempoolFee” : ＜Floating Point Number＞, # Fee for retaining Tx in secondary mempool “mempoolExpiryFee” : ＜Floating Point Number＞, # Fee once keepInMempoolFee expires }, {…} ] { # Service Level “service level”: ＜Unsigned Integer＞ “SLDescription”: ＜String＞ } “apiVersion“ : ＜Numeric＞# Merchant API version NN.nn (major.minor version no.) },

在一些實施例中，第二請求為POST submitTransaction(Tx)形式的一HTTPS請求，在此Tx在一些實施例中為與用於在客戶與顧客之間付款之給定交易相關聯之JSON格式的一物件。因此，該Tx（JSON物件）包含在該區塊鏈上創造一交易所需的資料，該客戶可在提出用於該付款處理器以傳遞給該等礦工之該第二請求以前，提供或建構如一JSON結構。

步驟110描繪發送一請求至複數個礦工中的一或多個礦工以產生在步驟108中對應於該給定交易之一區塊鏈交易的步驟。在此步驟中，付款處理器在一些實施例中轉換在先前步驟中之HTTPS POST請求為一RPC請求而提出給該等礦工。這可以由RPC createRawTransaction(Tx)請求來完成，在此Tx包括與給定交易相關聯的資料，如在步驟108中討論之給定為JSON物件。該RPC createRawTransaction(Tx)為一RPC呼叫，可創造一交易花費給定輸入且創造新輸出，在此，輸出可為位址或資料。RPC請求可發送至複數個礦工或至符合或滿足在步驟108中由客戶所選擇費用報價的礦工。如以上所提及者，已提供在所選擇費用報價或低於所選擇費用報價的目前費用報價的礦工，被認為是滿足所選擇費用報價的需求，由於他們可以其個別目前費用報價開採該交易。作為回應，滿足所選擇費用報價的一礦工創造對應於給定交易的一區塊鏈交易。在一些實施例中，對應於給定交易的一十六進位（hex-encoded）編碼原始交易被回傳至該付款處理器。

在步驟112，一輸出或與一對應區塊鏈交易相關聯的輸出腳本在該付款處理器處被接收，該區塊鏈交易為由複數個該等礦工當中符合所選擇費用報價的至少一礦工所創造。該輸出腳本可為由個別礦工所創造之與該對應區塊鏈交易相關聯的的一UTXO。在一些實施例中，該UTXO亦可儲存在符合所選擇費用報價的個別礦工的一記憶池內。在此步驟內的該輸出將包括一交易識別符（TxID）以用於由個別礦工所創造的對應區塊鏈交易。TxID是對將被提出給礦工的記憶池之十六進位編碼交易的參考，其接著相應地由該付款處理器映射（mapped）至區塊鏈交易。

此區塊鏈交易可接著被開採或立即地或在一稍晚的時間以目前費用報價完成開採程序。在一些案例中，所創造交易因為另一礦工已經將其寫入區塊鏈、或因為諸如一雙重支付、或時間延遲、或無效的一些原因未定或被拒絕，而可不被開採。

步驟114描述發送一交易結果TxResult至該客戶，該結果包括用於該區塊鏈交易的一交易識別符TxID，該區塊鏈交易係藉由一個別礦工在步驟108中被創造來對應於給定交易。在一些實施例中，該交易結果TxResult為一JSON物件，其係基於在步驟110與112中由滿足所選擇費用報價的一個別礦工所創建之對應區塊鏈交易的細節，而使用HTTPS通訊協定從該付款處理器被發送至該客戶。為該客戶之在TxResult物件中呈現之細節的一範例係給定如下：

用於個別礦工之JSON物件TxResult 顯示如下，且包括一些用字與物件，其係作為在步驟104中作為FeeQuotes JSON 物件的部分被討論。[ { “ReturnResult“ : ＜Alphanumeric＞, # ReturnResult is defined below “ResultDescription“ : ＜Alphanumeric＞, # Reason for failure (e.g. which policy failed and why) “DoubleSpendTxID“ : ＜Alphanumeric＞, # Tx ID of double spend transaction “ExceptionTimestamp“ : ＜UTC Timestamp＞, #Time exception was detected (e.g. doublespend time) “BlockHash“ : ＜Alphanumeric＞, # Block that includes this transaction “BlockHeight“ : ＜Integer＞, “MinerID“ : ＜Alphanumeric＞, # If MinerID is null (empty) then “NO-ID” is defaulted “MinerSignature“ : ＜Alphanumeric＞, # Block Hash + Block Height + TxID “SignatureValidFrom“ : ＜UTC Timestamp＞, # MinerSignature validity time (from getFeeQuote) “TxID“ : ＜Alphanumeric＞, # Transaction ID assigned when submitted to mempool “txSecondMempoolExpiry“ : ＜Integer＞, # Duration (minutes) Tx will be kept in secondary mempool” “APIversion“ : ＜Numeric＞ # API version NN.nn (major.minor version no.) } ]

以上提出的ReturnResult 可含有下列可能數值中之一者，其為如下： •Submitted -沒有問題，交易已提出至記憶池 •Rejected_DS -因為雙重支付被拒絕- DoubleSpendTxID不能為Null •Rejected_Policy – 因為違反政策被拒絕 •Rejected_Invalid – 因為交易無效被拒絕 •Rejected_FeeTooLow – 費用太低所以礦工將不會把Tx包括在一區塊中 •Rejected_KeepInMemPool – Tx 被拒絕但維持在一記憶池內以檢查雙重支付。

在有與該客戶相關聯、且使用與該付款處理器相關聯之相同或一分離端點一起提出的多個交易之案例中，該回應本體回傳該第二請求可為下列JSON格式： { “payload”: “{\”apiverison\”:\”1.0.1”,\”timestamp\”: ……………………………….}, “signature”: “30456598f65…………”, “publickey”: “03fcfcfcfcfd08433fc…….”, “encoding”: “UTF-8”, “mimetype”: “application/json” }

在一些實施例中，對在該第二請求中提出的多個交易，該回應本體提供以下內容： - 該回應將標頭（Header）資訊與交易（Transaction）層級（酬載）資訊分組 - 該回應針對各交易對一回傳結果（Result）（或目前狀態）報告。 - 該回應回傳錯誤計數：計數（returnResult ＜＞ success） - 該回應回傳一錯誤（Error）閾值，在此，若錯誤計數＞X，該交易的進一步處理被停頓（halted），且在第二請求中提出的所有多個交易被拒絕，在此，X為一可組態參數，其可為預先定義或動態地定義。若在該第二請求中一起提出的一批多個交易因為錯誤計數大於X而被一礦工拒絕開採，可以對於該代碼的一恰當描述而指定一錯誤代碼。

下面提出JSON封包用字及他們功能的解釋：

欄位	功能
酬載	主要資料酬載-基於交易層級資訊
簽章	酬載字串上的簽章
公鑰	驗證簽章的公鑰
編碼	編碼類型
mime類型	多用途網際網路郵件擴展類型

酬載或訊息欄位回傳的一範例在以下給出： { "apiVersion":"string", "timestamp":"string", "errorCount":"integer (count of where txn returnResult ＜＞ success)", "txs":[ { "txid":"string", "minerid":"string | null", "returnResult":"string", "resultDescription":"string", "currentHighestBlockHash":"string", "currentHighestBlockHeight":"integer", "txSecondMempoolExpiry":"string", "confirmations": "integer (0 for unconfirmed)" } ] }

步驟116描述接收來自該客戶之用於發送至該等複數個礦工的與一交易識別符TxID相關聯之一狀態查詢的步驟。此步驟在從複數個開採費用報價中選擇一費用報價之後，可開始對於配置來提出一交易的以上步驟為非同步地發生，且可不被認為對於第一態樣的操作為必要的。該實施例從步驟116開始關於一場景，在此，客戶希望知道在步驟108中所作之一或多個第二請求的狀態。

步驟116使得客戶可查詢交易的狀態，該交易為在步驟108中討論之該客戶經由HTTPS POST submitTransaction(Tx)提出至該付款處理器者。因此，在此步驟中的TxID可對應於任何第二請求，該第二請求為針對關於在客戶及其顧客之間的一數位資產付款的任何給定交易。如在以上的步驟中所討論者，狀態查詢係使用HTTPS作為一傳輸通訊協定而從客戶處接收，該請求係以一JSON格式被發送，諸如GET queryTransactionStatus(TxID)，其係接著被轉換成為一RPC請求，RPC getRawTransaction(TxID)用於發送至在該等複數個礦工中之一或多個礦工。

如以上所提及者，若由一客戶在該第二請求中提出多個交易，在一些實施例中多個交易的狀態可被該客戶在一單一查詢交易狀態請求中查詢，而非針對各交易發送分離的請求。與查詢多個交易相關的請求可被發送至相同付款處理器API或與該付款處理器相關聯的另一端點。與該付款處理器相關聯所有端點將會被該客戶所知或提供給該客戶。這可以在一客戶註冊與該付款處理器相關聯的服務時提供。如以上所提及者，已知諸如Swagger之類的開放API工具可使用來為客戶提供API。

在多個交易被查詢的案例中，第二請求的本體可為交易識別符（TxID）矩陣的形式。請求格式的一範例顯示如下： POST /mapi/txs [ "txId", "txId", “etc….." ]

在步驟118中，付款處理器接收來自在該等複數個礦工中的一個別礦工的一回應，該等礦工與創造及/或處理與該TxID相關聯之區塊鏈交易相關聯。在一些實施例中，以上RPC getRawTransaction(TxID)可包括一Verbose 參數，其可相關於被設定為1的引數（argument）。在此案例中，來自一個別礦工的一回傳結果若為成功，在一些實施例中將為含有在步驟110與112中經解碼對應區塊鏈交易的一JSON格式。這有利地提供擷取與處理在內資料的彈性。若Verbose 參數被設定為0，那麼替代於JSON資料類型或文件格式，十六進位編碼交易係被回傳至該付款處理器。若沒有此等與TxID相關的交易，可回傳Null ，其接著將會造成一ReturnResult 物件被設定為「未知」。任何其他回傳錯誤亦可藉由一礦工經由ReturnResult 與ResultDescription 物件向該付款處理器報告。此等物件已經相對於步驟114而指示出。

在步驟120，關於TxID的一TxResult被回傳至該客戶，該回應係使用HTTPS發送。此代表一開採結果，其係與由該客戶在步驟116中發送之狀態查詢中的一給定TxID相關聯。從該付款處理器發送給該客戶的TxResult之一範例在以下給出。

JSON物件TxStatus 顯示如下：[ { “ReturnResult“ : ＜Alphanumeric＞, # ReturnResult is defined below “ResultDescription“ : ＜Alphanumeric＞, # Reason for failure (e.g. which policy failed and why) “DoubleSpendTxID“ : ＜Alphanumeric＞, # Tx ID of double spend transaction “ExceptionTimestamp“ : ＜UTC Timestamp＞,# Time exception was detected (e.g. doublespend time) “BlockHash“ : ＜ Alphanumeric＞, “BlockHeight“ : ＜Integer＞, “Confirmations“ : ＜Integer＞, # 0 if not yet unconfirmed “MinerID“ : ＜Alphanumeric＞, # If MinerID is null (empty) then “NO-ID” is defaulted “MinerSignature“ : ＜Alphanumeric＞, # Block Hash + Block Height + TxID “SignatureValidFrom“ : ＜UTC Timestamp＞, # MinerSignature validity time “APIversion“ : ＜Numeric＞ # API version NN.nn (major.minor version no.) } ]

若該交易已經被個別礦工成功開採且標誌為確認（Confirmed），亦即被添加至一區塊內，BlockHash 與 MinerID可被填充。若一礦工沒有設定好他們的MinerID那麼那麼將會被設定為「空（NULL）」。

ReturnResult物件可含有下列開採結果其中一者： • Submitted –沒有問題，交易已提出至記憶池 • Confirmed –交易確認， Confirmations 不能為0 或空（Null） • Rejected_DS – 因為雙重支付被拒絕– DoubleSpendTxID 不能為空 • Rejected_Policy –因為違反政策被拒絕 • Rejected_Invalid –因為交易無效被拒絕 • Rejected_FeeTooLow –費用太低所以礦工將不會把Tx包括在一區塊中 • Rejected_KeepInMemPool –Tx 被拒絕但維持在一記憶池內以檢查雙重支付 • Unknown – 沒有看到交易或交易部存在-可能是在該記憶池或區塊鏈中不存在提供TxID的交易。若是如此，這將會在ResultDescription中被陳述。

在有與該客戶相關聯的多個交易將使用相同或與該付款處理器相關聯之一分離端點來一起查詢的案例中，回傳的該回應本體可為以下JSON格式： { “payload”: “{\”apiverison\”:\”1.0.1”,\”timestamp\”: ……………………………….}, “signature”: “30456598f65…………”, “publickey”: “03fcfcfcfcfd08433fc…….”, “encoding”: “UTF-8”, “mimetype”: “application/json” }

在一些實施例中，針對多個交易查詢，回應本體將Header資訊與交易層級（酬載）資訊分組在一起

回傳的酬載或訊息欄位的範例給定如下： { "apiVersion":"string", "timestamp":"string" "txs":[ { "txid":"string", "minerid":"string | null", "returnResult":"string", "resultDescription":"string", "currentHighestBlockHash":"string", "currentHighestBlockHeight":"integer", "txSecondMempoolExpiry":"string", "confirmations": "integer (0 for unconfirmed)" } ] } 第二態樣-客戶

圖2關於本揭露的第二態樣，且描述了由與客戶相關聯之一或多個處理器所進行的一種方法，在此該客戶係通訊式耦接於如關於第一態樣所描述之實施該方法的至少一付款處理器。該付款處理器實施如以上所討論之關於圖1所描述的用於一客戶付款服務或付款API。

在描述於圖2的範例場景中，關於下列步驟之實施例全部被描述為接續發生，下列步驟為獲得複數個開採費用報價、基於從所獲得複數個開採費用報價中之一所選擇費用報價提出一交易，以及發送關於一交易識別符的一狀態查詢，亦即，在圖2的流程圖中被描述為一單一流程者。然而，本揭露與第二態樣並不被認為是如此限制。下列描述在步驟202至206中，關於在一第一請求中獲得費用報價的步驟可分離地或獨立於剩餘步驟而實施。類似地，從步驟208至212中關於在第二請求中提出一交易的步驟可分離地實施，且可在獲得費用報價的較早步驟的一不同時間實施。以同樣的方式，關於一交易狀態查詢的步驟從步驟214開始可在客戶已經知道交易識別符之後的任何時間實施，且不需要遵循圖2中的順序。所有在此依序顯示的步驟僅只是用於便於解釋與理解，且在本揭露的任何情況下都不應被認為被限制在此等順序或場景。更進一步地，如關於圖1中先前討論者，費用報價可針對每次一個單一交易，或針對由該客戶在一單一請求中，亦即，在同樣時間提出的一組或一批複數個交易被請求及/或獲得及/或提出及/或查詢。為了便於解釋與理解，圖2將在與該客戶相關聯的一第一請求/第二請求與一狀態查詢中以關於一單一交易的方式來解釋，但本揭露在任何方面都不是如此限制。

步驟202描述了發送一第一請求至與該客戶相關聯之至少一付款處理器中的一付款處理器，以提供一個別付款服務。如關連於圖1之步驟102所討論者，該請求係關於為該客戶用於開採一交易的一或多個費用報價。此第一請求關於步驟102中討論的HTTPS GET getFeeQuote。如以上討論者，該請求可用於為該客戶開採任何交易，或可為用於取得開採一交易的費用報價，該交易為關於來自與該客戶相關聯之一顧客的一數位資產付款。如以上所討論者，在一些實施例中，該第一請求亦可包括對於一或多個將被開採交易所需之服務層級的細節。這可與開採速度及/或針對由一礦工提供的雙重支付的保護有關。

在步驟204中，從該付款處理器處接收複數個開採費用報價，該費用報價關於針對通訊式耦接於為客戶服務的付款處理器之複數個礦工中之各者的開採費用。所接收費用報價的結構與細節已在圖1關於步驟104中討論。

步驟206描述從在步驟204中所接收之一或多個費用報價中選擇一費用報價。在一些實施例中，所選擇費用報價可基於由該付款處理器所提出的一建議費用報價。在一些實施例中，選擇係由與該客戶相關聯的一或多個處理器所作出。所選擇費用報價可為所獲得費用報價的一平均值或中位數，或從複數個礦工處所獲得之費用報價中的最大值、或在一次要記憶池中最高費用報價，如此上所討論者。因此，客戶可回應於該第一請求，選擇從該等複數個礦工處獲得之最高費用值。如此一來，所有的礦工可以他們個別目前費用報價而對於開採該交易被提供相同的機會。然而，客戶可替代地選擇位於或高於所接收所有費用報價的中位數或平均值的一費用報價，因此有較高報價的礦工將簡單地維持該交易在一次要記憶池中且使用其來檢查及/或拒絕交易的任何雙重支付。

步驟208描述請求及/或處理來自與該客戶相關聯之顧客的數位資產付款的步驟。這可以是由該客戶發送給該顧客的一付款請求或一發票，其係使用適用於雙方各自的數位錢包實施的已知方法而用於該數位資產付款。由於用於在區塊鏈開採任何交易的所選擇費用報價是已知的，該請求可包括或可與所選擇費用報價相關聯。

步驟210描述發送一第二請求以提出一給定交易至區塊鏈的步驟，一給定交易與來自該顧客至該付款處理器的該數位資產付款相關聯。在此步驟中之提出係基於用於開採在步驟206中給定交易的所選擇費用報價。此步驟關於客戶發送在圖1之步驟108中的HTTPS POST submitTransaction(Tx)請求至該付款處理器，以及對於該給定交易的JSON資料類型格式中的相關細節。

步驟212描述接收用於對應於所提出交易之一區塊鏈交易的一交易識別符（TxID）的步驟。如在圖1的步驟110與112中所討論者，TxID係由滿足所選擇費用報價的至少一礦工所創造。在一些實施例中，這可以相關聯於或作為一交易結果的一部分而被發送，亦即，TxResult顯示對於個別礦工之對應區塊鏈交易的目前開採狀態。在圖1關於步驟114對此進行了描述。

步驟214關於當客戶希望要查詢先前在步驟210中提出的一交易的開採狀態，客戶發送一狀態查詢。由於該客戶將會接收到在步驟212中所提出交易的TxID，此請求將會基於TxID且如圖1的步驟116中所描述的為HTTPS GET queryTransactionStatus(TxID)格式。

步驟216描述獲得對應於在步驟214中所查詢之交易識別符TxID之區塊鏈交易的一開採狀態結果。這可以為JSON格式且在該付款處理器接收到對應交易的細節後，使用HTTPS由該付款處理器發送至該客戶。該狀態結果可為如圖1的步驟120中所見的TxResult JSON物件之形式。第三態樣-礦工實施

圖3關於本揭露的第二態樣且描述由在複數個礦工中之一礦工所進行的一種方法，在此該等複數個礦工係通訊式耦接至如關於第一態樣所討論之實施該方法的至少一付款處理器。該付款處理器對一客戶實施該付款服務、或關於圖1中所討論的付款API。該客戶係組配為可實施關於圖2中所討論的方法。

在圖3中所描繪的範例場景中，關於提供複數個開採費用報價的步驟之實施例、基於在所獲得複數個費用報價中的一所選擇費用報價來產生/創造一區塊鏈交易，以及提供關於一交易識別符的一開採狀態，全部被描述為依序發生，亦即在圖3的流程圖中被描述為一單一程序。然而，本揭露與第三態樣不應被認為如此限制。以下描述之回應於在步驟302與304之一第一請求的關於提供目前費用報價的步驟，可分離地與獨立於剩餘步驟而實施。類似地，回應於從步驟308至314之第二請求的關於產生一對應區塊鏈交易的步驟可被分離地實施，且在獲得費用報價之較早步驟的不同時間點實施。以同樣的方式，關於在步驟316中提供一交易狀態的步驟可在該客戶已經得知交易識別符後的任何時間點實施，且不需要遵循圖3的順序。所有在此依照順序顯示的步驟僅為了易於解釋與理解，本揭露在任何狀況下不應被認為被限制於此等順序或場景。更進一步地，如以上所討論之關於圖1和2者，費用報價可針對每次一單一交易，或針對由該客戶在一單一請求中，亦即在同樣時間，提出的一組或一批複數個交易被請求及/或獲得及/或提出及/或查詢。為了便於解釋與理解，圖3將在與該客戶相關聯的一第一請求/第二請求與一狀態查詢中以關於一單一交易的方式來解釋，但本揭露在任何方面都不是如此限制。

步驟302描述從一付款處理器接收一第一請求，該第一請求用於對代表一客戶開採的一交易提供一費用報價。此請求關於從該付款處理器所發送的RPC getFeeQuote()請求，如關於圖1的步驟104中所提出者。

步驟304描述了提供關於複數個礦工中之各礦工對開採在該區塊鏈中的該交易的一目前費用報價。該費用報價可以如圖1之關於步驟104中所提出的JSON物件FeeQuotes的形式提供。

步驟306描繪了在該等複數個礦工中的一礦工接收一第二請求的步驟，該請求相關於提出與該客戶相關聯的一給定交易至該區塊鏈，在此，給定交易係基於來自該客戶的一所選擇費用報價。該給定交易係關於圖2之步驟210中在POST submitTransaction(Tx)的Tx，亦即，在該客戶與一顧客間的一給定數位資產付款交易。從該付款處理器所接收之該RPC版本為用於該給定交易的RPC createRawTransaction(Tx)，如圖1之關於步驟110中所解釋者。

步驟308描繪檢查符合或滿足來自該客戶之所選擇費用報價的礦工。這可包括由在步驟304中的個別礦工提供給該付款處理器的目前費用報價是否位於或低於所選擇費用報價的一決定，該所選擇費用報價為該客戶願意為開採該給定交易Tx所付費者。

若該目前費用報價滿足所選擇費用報價，接著在步驟310中創造對應於該給定交易的一區塊鏈交易。這在關於圖1的步驟110中討論。在一些實施例中，對應於該給定交易的一十六進位編碼原始交易被回傳至該付款處理器。如圖1之步驟112中所討論者，一輸出腳本或UTXO亦被提供給該付款處理器，在此該輸出腳本包括由該等個別礦工所創造之與該對應區塊鏈交易相關聯的一交易識別符(TxID)。用於該區塊鏈交易的該輸出腳本可接著被添加至與用於立即或在一較晚時間開採的該礦工相關聯的記憶池。

若目前費用報價不滿足所選擇費用報價，亦即，若個別礦工的目前費用報價係高於該客戶所允許或選擇者，那麼個別礦工在一些實施例中可選擇以比該目前費用報價較低費用開採，或由於所選擇費用報價係低於他們個別目前費用報價，而可選擇不要開採該給定交易。在一些實施例中，在此個別礦工選擇不要以較低選擇費用報價開採該交易，在步驟312中，該個別礦工可替代地在與該個別礦工相關聯的一次要記憶體池中，添加與為該給定交易建構的一區塊鏈交易相關的細節。此交易在一些實施例中可被保存在該次要記憶池中，且使用來檢查雙重支付。儲存在該次要記憶池中的所有交易可能有一個到期時間，之後可以將其清除。

在一區塊鏈交易已經被創造的假設下，亦即，該個別礦工符合由該客戶所設定之所選擇費用報價的需求，步驟316關於個別礦工接收與為該客戶所創造之該區塊鏈交易的TxID相關聯之一狀態查詢。此狀態查詢係基於經由關於圖1之步驟116與118中所討論之API轉換器所接收的RPC請求RPC getRawTransaction(TxID)。

在步驟318，基於對應關於一個別礦工的區塊鏈交易的一目前開採狀態之一結果被提供給該付款處理器。這可基於如在圖1中關於步驟120中所解釋之用於TxStatus的一JSON物件結構。

圖4為由一付款處理器404提供給一客戶402之作為API之付款服務的部屬架構的一概要圖。可以有多於一個此等付款處理器404，且一或多個付款處理器404亦可實施作為一客戶的部分，或可與該客戶相關聯，或可分離地實施於該客戶且可透過諸如網際網路的一通訊網路與該客戶通訊。如以上態樣中所討論者，在客戶402與付款處理器404之間的通訊使用HTTPS通訊協定。一API轉換器406亦分離地顯示在此概要圖中，但在一些實施例中可實施作為付款處理器404的一部分。在一些實施例中，API轉換器406可由複數個礦工412-1至412-n所操作或與其關連地實施。API轉換器406允許在發送至一或多個礦工412-1至412-n前，轉換HTTPS請求為RPC請求，該等礦工與該付款處理器耦接以為該客戶402提供一服務。該API轉換器406顯示為經由一防火牆408而與礦工412-1至412-n連接。所有與礦工412-1至412-n相關聯的通訊使用RPC。一節點連接器410亦顯示用於經由該防火牆408而連接複數個礦工412-1至412-n至該付款處理器404。在一些實施例中，該節點連接器可確保或處理與一或多個付款處理器相關聯的RPC呼叫，該一或多個付款處理器404如關於圖1中所討論者實施一個別付款服務。該節點連接器410在該API轉換器406與一或多個礦工412-1至412-n間提供一安全通訊頻道。

可有一或多個付款處理器404經由該API轉換器406連接至該等礦工412-1至412-n。該客戶402將最可能會包括一數位錢包應用以獲得對於礦工費用的報價（getFeeQuote）、提出交易（submitTransaction）以及查詢一交易的狀態（queryTransactionStatus），如關於第一至第三態樣對個別或複數個交易中所解釋者。該付款處理器404為該客戶402作為一REST端點，且該客戶可匿名取用此服務。礦工412-1至412-n可開採一或多個節點以交換開採獎勵，其在一些實施例中可由區塊獎勵與礦工費用所組成。一旦一礦工412成功地開採一區塊，一區塊獎勵被稱為BSV或所獎勵加密貨幣。一礦工費用為一礦工412在他們確認一交易且將其添加至一新開採區塊時所接收到的獎勵。

圖5為一概要圖，描繪在圖4中顯示之用於實施命令getFeeQuote或來自該客戶之模版的架構的組件之間的資料流。這已經在關於圖1至3中詳細討論，且圖4簡單地提出為了獲得開採費用報價，該客戶、付款處理器與礦工的概要互動。當在步驟501中HTTPS GET getFeeQuote命令被發送至該付款處理器404時，該流程從客戶402起始。在步驟502中該GET命令被發送至API轉換器406，其將此在步驟503中轉換至一RPC命令RPC getFeeQuote()。在步驟504中，MinerFeeQuote以一JSON物件格式從複數個礦工412-1至412-n中的各礦工412，被回傳至該API轉換器406，其接著在步驟505中被提供給該付款處理器404。對在該等複數個礦工412-1至412-n中之各礦工重複步驟502至505，且結果（費用報價）於步驟506中在HTTP傳輸中被發送至該客戶402。

圖6為描繪在圖4中顯示之用於實施submitTransaction命令或來自該客戶之樣版的架構的組件之間資料流的一概要圖。這已經在關於圖1至3中詳細討論、且圖4簡單地提出為提供與一客戶之一付款相關聯的一區塊鏈交易，該客戶、付款處理器與礦工的概要互動。此流程在當HTTPS POST submitTransaction(Tx) 命令於步驟601針對在該客戶402與一顧客之間的一給定交易Tx被發送至該付款處理器404時，由客戶402處起始。如關連於以上態樣中所提及者，Tx可與一所選擇費用報價相關聯（未顯示在此圖式中）。在步驟602中，該POST命令被發送至該API轉換器406，其將此在步驟603中轉換至一RPC命令RPC createRawTransaction(Tx)。該區塊鏈交易接著針對符合所選擇費用報價的各礦工412而被建構。在步驟604中，十六進位區塊鏈交易被回傳至該API轉換器406。該交易包括一特定識別符TxID，如在以上態樣中所討論者。在步驟605中，與該區塊鏈交易相關聯的一輸出被發送至該付款處理器404。關於區塊鏈交易的一結果接著作為JSON TxResult物件而被回傳給該客戶，該物件包括在步驟606中的TxID。

圖7為描述在圖4中顯示之用於實施queryTransactionStatus命令或來自該客戶之樣版的架構的組件之間資料流的一概要圖。這已經在關於圖1至3中詳細討論、且圖4簡單地提出為提供與一客戶之一付款相關聯的一區塊鏈交易，該客戶、付款處理器與礦工的概要互動。當該HTTPS GET queryTransactionStatus(TxID)命令在步驟701中為關於一區塊鏈交易的一給定交易TxID而被發送至該付款處理器404時，該流程從該客戶402處起始，該區塊鏈交易為在圖6中作為submitTransaction流的一部分先前被回傳至該客戶者。在步驟702中，該GET命令被發送至該API轉換器406，其將此在步驟703中轉換成一RPC命令getRawTransaction(TxID)。與關於該TxID之一給定礦工412相關聯的該區塊鏈交易接著被識別。在步驟704中，該經識別十六進位區塊鏈交易與其相關聯狀態被回傳至該API轉換器406。在步驟705中，與關於該TxID之該區塊鏈交易相關聯的一狀態結果被發送至該付款處理器404。針對TxID之關於該區塊鏈交易的狀態結果接著在步驟706中作為一JSON TxStatus物件被回傳至該客戶。

更進一步地，如以上關於圖1至3所討論者，該費用報價可分離地針對每次一單一交易，或針對由該客戶在一單一請求中，亦即在同樣時間，提出的一組或一批複數個交易被請求及/或獲得及/或提出及/或查詢。為了便於解釋與理解，圖4至7以在與該客戶相關聯的一第一請求/第二請求及/或一狀態查詢中關於一單一交易的方式來解釋，但可以理解本揭露在任何方面都不是如此限制。

接著到圖8，提供一計算裝置2600的一例示性、簡化方塊圖，其可使用來實施本揭露的至少一實施例。在各種實施例中，該計算裝置2600可被使用來實施以上例示說明與描述的任何系統。例如，該計算裝置2600可組配為可作為圖式之DBMS的一或多個組件來使用，或該計算裝置2600可組配為可與一給定使用者相關聯的一客戶實體，該客戶實體對一資料庫作出資料庫請求，該資料庫係由圖8之DBMS所管理。因此，計算裝置2600可為一可攜式計算裝置、一個人電腦或任何電子計算裝置。如圖8中所顯示者，該計算裝置2600可包括具有一或多個快取記憶體層級與一記憶體控制器（聯合地被標示為2602）的一或多個處理器，其可被組配為可與一儲存子系統2606通訊，該儲存子系統2606包括主記憶體2608與持久儲存器2610。該主記憶體2608可如顯示包括動態隨機存取記憶體（DRAM）2618與僅讀記憶體（ROM）2620。儲存子系統2606與快取記憶體2602且可被使用來儲存資訊，諸如在本揭露中所描述之與交易及區塊相關聯的細節。該（等）處理器2602可被利用來提供本揭露中所描述任何實施例的步驟或功能。

該（等）處理器2602亦可與一或多個使用者介面輸入裝置2612、一或多個使用者介面輸出裝置2614以及一網路界面子系統2616通訊。

一匯流排子系統2604可提供一機構用來使得計算裝置2600的各種組件與子系統可以如意圖地與彼此通訊。雖然匯流排子系統2604係概要地顯示為為一單一匯流排，匯流排子系統的替代實施例可利用多個匯流排。

該網路界面子系統2616可提供一介面至其他計算裝置與網路。該網路界面子系統2616可作為用來由該計算裝置2600從其他系統接收資料及發送資料的一介面。例如，該網路界面子系統2616可使得一資料技師可將該裝置連接至一網路，因此當在一遠端位置時，該資料技師可以傳輸資料至該裝置且從該裝置接收資料，諸如一資料中心。

該使用者介面輸入裝置2612可包括一或多個使用者輸入裝置，諸如一鍵盤；諸如一整合滑鼠、軌跡球、觸控板或繪圖平板的一指向裝置；一掃描器；一條碼掃描器；整合入顯示器的一觸控螢幕；諸如語音識別系統、麥克風的音訊輸入裝置；以及其他類型的輸入裝置。一般來說使用「輸入裝置」的用字意欲包括用於輸入資訊至該計算裝置2600的所有可能類型的裝置與機構。

該一或多個使用者介面輸出裝置2614可包括一顯示器子系統、一印表機或非視覺顯示器諸如音訊輸出裝置等等。顯示子系統可為一陰極射線管（CRT）、諸如一液晶顯示器（LCD）的一平面式裝置、發光二極體（LED）顯示器、或一投影機或其它顯示裝置。一般來說，用字「輸出裝置」的使用意欲包括用於從該計算裝置2600輸出資訊的所有可能類型的裝置與機構。一或多個使用者介面輸出裝置2614可被使用來，當此等互動為恰當時，例如呈現使用者介面以促進使用者與進行所描述之程序及其中的變化的應用程式互動。

該儲存子系統2606可提供用於儲存可提供本揭露之至少一實施例的功能的基本程式與資料結構的一電腦可讀儲存媒體。應用程式（程式、代碼模組、指令）當由一或多個處理器執行時可提供本揭露之一或多個實施例的功能、且可被儲存在儲存子系統2606中。此等應用程式模組或指令可由一或多個處理器2602執行。該儲存子系統2606可附加地提供用於儲存根據本揭露所使用之資料的一資料庫（repository）。例如，主記憶體2608與快取記憶體2602可提供依電性儲存器給程式與資料。持久性儲存器2610可提供持久（非依電性）儲存器給程式與資料且可包括快閃記憶體、一或多個固態硬碟、一或多個磁性硬碟驅動機、具有相關聯可移除媒體的一或多個軟碟驅動機、以相關聯於可移除媒體驅動的一或多個光學驅動機（例如，CD-ROM或DVD或藍光）以及其他類似的儲存媒體。此等程式與資料可包括用於完成在本揭露中所描述之一或多個實施例的步驟的程式，以及如在本揭露中所描述之與交易及區塊相關聯的資料。

該計算裝置2600可為各種類型，包括一可攜式電腦裝置、平板電腦、一工作站或以下描述的任何其它裝置。此外，計算裝置2600可包括另一裝置，其可與該計算裝置2600透過一或多個埠（例如，USB、耳機接口、Lightening連接器）連接。可與該計算裝置2600連接的該裝置可包括複數個埠，其係組配為可接收光纖連接器。據此，此裝置可組配為可轉換光學訊號成為電子訊號，其可透過連接該裝置之埠而傳輸至該計算裝置2600而用於處理。因為電腦與網路不斷變化的本質，在圖8中描繪之計算裝置2600的描述僅用作為例示說明該裝置的較佳實施例的一特定範例。較圖8中所描繪之系統具有更多或較少組件的許多其它組態亦為可能的。列舉的範例實施例

因此，本揭露在此基於與以上態樣有關的下列簡短而討論，其係在此提工作為示例性實施例，以更好地解釋、描述和理解所請求態樣與實施例。

1.一種為一或多個客戶對與一區塊鏈相關聯之交易提供一付款服務的電腦實施方法，該方法由一付款處理器實施且包含下列步驟：從一客戶處接收與在一區塊鏈中開採一交易相關聯的一第一請求；發送一費用報價的一請求給與該付款處理器通訊式耦接之複數個礦工中的各個礦工；從各個礦工處獲得用於開採該交易的一費用報價；以及提供從該等複數個礦工處所獲得的費用報價給該客戶，其中用於開採該交易的一所選擇費用報價係基於所獲得礦工而判定；或基於所獲得費用報價而判定用於為該客戶開採該交易的一所選擇費用報價。

2.如子句1中所提出的方法，其中，與該第一請求相關聯的該交易包括一批多個交易。

3.如子句1或2中所提出的方法，包含下列步驟：回應於來自該客戶的一第二請求，該第二請求為要提出關於在所獲得費用報價中的該所選擇費用報價的一給定交易，而發送一請求至該等複數個礦工中之一或多個礦工以產生對應於該給定交易的一區塊鏈交易；從該等複數個礦工中滿足該所選擇費用報價的至少一礦工處，接收與該對應區塊鏈交易相關聯的一輸出腳本；以及發送一結果至該客戶，該結果包括用於對應於該給定交易之該區塊鏈交易的一交易識別符。

4.如子句3中所提出的方法，其中，該給定交易包括一批多個交易。

5.如先前任意子句中所提出的方法，其中，提供所獲得費用報價的步驟進一步包含基於所獲得費用報價的平均值或在所獲得費用報價中的最大值而判定一建議費用報價。

6.如子句5中所提出的方法，進一步包含提供該建議費用報價或提供包括該建議費用報價的全部所獲得費用報價，其中該建議費用報價包括一識別符。

7.如子句5或7任一者所提出的方法，其中，所選擇費用報價與該建議費用報價相同或與該建議費用報價不同，其中不同費用報價為預定或任意選擇。

8.如先前任一子句中所提出的方法，其中，判定一所選擇費用報價的步驟包含從複數個服務層級中指定一服務層級至所獲得費用報價的各者，各服務層級係與用於開採該交易的一各別所選擇費用報價相關聯。

9.如子句8中所提出的方法，其中，該服務層級係基於所獲得費用報價與一最小中繼費用而指定，該最小中繼費用係與關於該各別費用報價的礦工相關聯。

10.如子句8或9中所提出的方法，其中，該指定服務層級係指示要開採該交易的一優先性，及/或針對該建議費用之與一交易相關聯的雙重花費保護的一層級。

11.如子句8至10中任一者所提出的方法，其中，針對將要被開採之該交易的該服務層級係基於從該客戶處所獲得的一或多個服務需求而被指定。

12.如先前任一子句中所提出的方法，包含驗證該等複數個礦工中之一給定礦工的身分的步驟，其中，該驗證係基於與該給定礦工相關聯的一數位簽章或基於關於該給定礦工的一識別符而作成，該識別符係可選擇地與針對該給定礦工的一信譽指示器相關聯。

13.如先前任一子句中所提出的方法，包含基於一礦工簽章而驗證從該等複數個礦工中之一給定礦工處所獲得的一各別費用報價的步驟，該礦工簽章作為來自該給定礦工要以該各別費用報價開採該交易的一承諾，且可選擇地可拒絕任何衝突交易。

14.如先前任一子句中所提出的方法，其中，從各礦工處獲得的該費用報價係以一資料類型提供，該資料類型為JavaScript 物件表示法（JSON）物件格式。

15.如先前任一子句中所提出的方法，其中，該所接收輸出腳本為與針對該至少一礦工之一記憶池相關聯的未花費交易輸出(UTXO)，該UTXO包括用於該區塊鏈交易的交易識別符（TxID）。

16.如先前任一子句中所提出的方法，包含下列步驟：回應於來自該客戶之與一交易識別符相關聯的一狀態查詢，發送一請求至該等複數個礦工以獲得對應於該交易識別符的一區塊鏈交易；從該等複數個礦工中之至少一礦工處獲得該對應區塊鏈交易；以及發送關於所獲得區塊鏈交易的一狀態結果給該客戶。

17. 如先前任一子句中所提出的方法，其中該付款處理器係實施為用於一或多個客戶的一表現狀態轉移(REST)端點，並且其中，該方法進一步包含提供與該付款處理器相關聯之一應用程式介面（API）轉換器的步驟以進行下列步驟：從該客戶處使用一超文本傳輸協定安全 (HTTPS)傳輸格式來接收該第一請求及/或該第二請求及/或關於該給定交易的一狀態查詢；轉換該各別請求為一遠端程序呼叫 (RPC)格式，且發送該RPC至該等複數個礦工之一或多者；從該等複數個礦工之中之一或多個礦工處接收以一RPC格式之與一對應區塊鏈交易相關聯的回應；以及轉換該等各別回應因此他們可使用HTTP傳輸通訊協定而被發送至該客戶。

18.一種用於處理與一區塊鏈相關聯之交易的電腦實施方法，該方法係由與一客戶相關聯之一或多個處理器實施，該客戶係與為該客戶實施一付款服務的至少一付款處理器通訊式耦接，該方法包含下列步驟：發送一第一請求到至少一付款處理器中的一付款處理器，該請求關於用於開採一交易的一或多個費用報價，該交易相關於來自一顧客的一數位資產付款；以及回應於從該付款處理器之一或多個費用報價的接收，從該一或多個所接收費用報價中選擇一費用報價。

19.如子句18中所提出的方法，包含下列步驟：請求及/或處理來自該顧客的該數位資產付款，該請求與該所選擇費用報價相關聯；發送一第二請求以將來自該顧客至該付款處理器之與數位資產付款相關聯的一給定交易提出給該區塊鏈，該提出係基於用於開採該給定交易的該所選擇費用報價；以及獲得對應於所提出交易之一區塊鏈交易的一交易識別符(TxID)。

20.如子句19中所提出的方法，其中在該第二請求中之該給定交易包括一批多個交易。

21.如子句18至20任一者中所提出的方法，包含下列步驟：發送與該所獲得交易識別符相關聯的一狀態查詢；以及獲得對應於該區塊鏈識別符之該區塊鏈交易的一狀態結果。

22.如子句18至21任一者中所提出的方法，其中，該客戶包括該至少一付款處理器或與該至少一付款處理器通訊式耦接，該至少一付款處理器係組配為可實施如子句1至17中任一者所提出的方法。

23.如子句18至22任一者中所提出的方法，其中，該第一請求及/或該狀態查詢為一HTTPS GET請求，並且其中，該第二請求係為一HTTPS POST請求。

24.如子句18至23任一者中所提出的方法，其中，選擇一費用報價的步驟包含判定該等所獲得費用報價的一平均值，以及基於所判定平均來選擇一費用報價。

25.如子句18至24任一者中所提出的方法，其中，選擇一費用報價的步驟包含判定在所獲得費用報價中一費用報價的最大值，以及基於該最大值來選擇一費用報價。

26.如子句18至25任一者中所提出的方法，其中，與該第一及/或第二請求及/或該狀態查詢相關聯的資料係以一JavaScript 物件表示法（JSON）物件格式提供。

27.一種用於處理與一區塊鏈相關聯之交易的電腦實施方法，該方法係由與複數個礦工中之一礦工相關聯的一或多個處理器來實施，該等複數個礦工係通訊式耦接於為一客戶實施一付款服務的至少一付款處理器，該方法包含下列步驟：從一付款處理器處接收用於開採與該客戶相關聯之一交易的一費用報價的一第一請求；以及提供關於該礦工在該區塊鏈中開採該交易的一目前費用報價，其中，該目前費用報價代表要以該目前費用報價開採一交易的一承諾（undertaking）。

28.如子句27中所提出的方法，包含下列步驟：回應於關於要提出與該客戶相關聯之一給定交易給該區塊鏈的一第二請求，該給定交易係基於一所選擇費用報價，該方法進一步包含下列步驟：基於與該給定交易相關聯之所選擇費用報價滿足該礦工之該目前費用報價的一判定，產生對應於該給定交易的一區塊鏈交易；針對該區塊鏈交易產生一輸出腳本（UTXO）；添加產生之輸出腳本至與該礦工相關聯之一記憶池；以及發送該輸出腳本至該付款處理器，其中，該輸出腳本包括與該對應區塊鏈交易相關聯的一交易識別符（TxID）。

29.如子句28中所提出的方法，包含回應於用於與該交易識別符相關聯之一狀態的一請求，基於該對應區塊鏈交易的一開採狀態回傳一結果。

30.如子句27至29任一者中所提出的方法，其中，提供該目前費用報價的步驟及/或發送該輸出腳本的步驟及/或回傳該結果的步驟係實施為一遠端程序呼叫（Remote Procedure Call RPC）。

31.如子句30中所提出的方法，包括在為該客戶透過一無線通訊網路傳遞該RPC至該付款處理器以前，從該礦工處發送該RPC至一節點連接器的步驟，且選擇地為該等複數礦工提供一防火牆。

32.如子句27至31任一者中所提出的方法，其中，基於與該給定交易相關聯的該所選擇費用報價不滿足該礦工的該目前費用報價的一判定，添加與一對應區塊鏈交易相關聯的一輸出至與該礦工相關聯的一次要記憶池。

33如子句27至32任一者中所提出的方法，其中，該礦工係與至少一付款處理器通訊式耦接，該付款處理器係組配為可實施子句1至9中任一者所提出之方法，並且其中，該至少一付款處理器係與一客戶相關聯的或與一客戶通訊式耦接，該客戶係組配為可實施子句12至19中任一者所提出之方法。

34.一種為一或多個客戶提供針對與一區塊鏈相關聯之交易的一付款服務的電腦實施方法，該方法係由一付款處理器實施，且包含下列步驟：接收或同意來自一客戶之用於將在一區塊鏈中被開採的交易的一或多個服務要求；接收來自一客戶之用於在一區塊鏈中開採一或多個交易的一第一請求；發送針對一費用報價的一請求給與該付款處理器通訊式耦接的複數個礦工中的各礦工；從各礦工處獲得用於開採該一或多個交易的一費用報價；分類所獲得費用報價成為提供來開採之複數個服務層級中之一給定服務層級，各服務層級係與一組開採費用相關聯；基於所接收到的該一或多個服務要求而為該客戶判定一服務層級；其中，與所判定服務層級相關聯的該組開採費用係用於開採與該客戶相關聯的一或多個交易之該所選擇費用報價，並且其中，該所判定服務層級係指示要開採該交易的優先性，及/或防止雙重花費之保護的一層級。

35.一種計算裝置，其包含一處理器與記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令致使該裝置可進行如子句1至17與33任一者中所提出之電腦實施方法，該計算裝置關於一付款處理器。

36.一種計算裝置，其包含一處理器與記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令致使該裝置進行如子句18至26任一者中所提出之電腦實施方法，該計算裝置關於一客戶。

37.一種計算裝置，包含一處理器與記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令致使該裝置進行如子句27至33任一者中所提出之電腦實施方法，該計算裝置關於一礦工。

38.一種電腦系統，其包含：一付款處理器，其經由一無線通訊網路通訊式耦接於至少一客戶與至少一礦工，該付款處理器選擇性地與一API轉換器相關聯，以用於使來自該客戶之HTTPS請求至用於該礦工之RPC請求的轉換，且反之亦然，其中，該付款處理器係根據子句35中所提出之計算裝置而實施；一客戶，其經由該無線通訊網路通訊式耦接於該付款處理器，且其可與至少一客戶通訊；該客戶係根據如子句36中所提出之計算裝置而實施；以及複數個礦工，其經由該無線通訊網路通訊式耦接於該付款處理器，各礦工係根據如子句37中所提出之計算裝置而實施。

39.一種具有可執行指令儲存在上的電腦可讀儲存媒體，作為被一電腦的一處理器執行之結果，該等可執行指令致使該電腦進行子句1至34任一者的方法。

應當注意的是以上提出的態樣與實施例例示說明不適用來限制本揭露且習於此技藝者將可以設計許多替代實施例而不偏離於本揭露如附加請求項中所界定之範圍。在請求項中，放在括號中的任何參考符號不應被解釋為對請求項的限制。用字「包含」和「包含有」與類似者不排除任何請求項或整個說明書中所列出的元件或步驟之外的元件或步驟的存在。在本說明書中，「包含」代表「包括」或「由……組成」，且「包含有」代表「包括或由……組成」。一元件的單數形式並不排除此類元件的複數形式，反之亦然。本揭露可以藉由包含許多不同元件的硬體之構件以及藉由適當程式化的電腦來實施。在列舉許多構件的一裝置請求項中，此等構件中的許多者可由一個且相同的硬體來實施。在互不相同的附屬請求項中記載特定措施的事實，並不表示不能利用這些措施的組合無法利用。

102、104、106、108、110、112、114、116、118、120:步驟 202、204、206、208、210、212、214、216:步驟 302、304、306、308、310、312、316、318:步驟 402:客戶 404:付款處理器 406:API轉換器 408:防火牆 410:節點連接器 412、412-1～412-n:礦工 501、502、503、504、505、506:步驟 601、602、603、604、605:步驟 701、702、703、704、705、706:步驟 2600:計算裝置 2602:快取記憶體 2604:匯流排子系統 2606:儲存子系統 2608:主記憶體 2610:持久儲存器 2612:使用者介面輸入裝置 2614:使用者介面輸出裝置 2616:網路界面子系統 2618:DRAM 2620:ROM

本揭露的態樣與實施例現在將以範例的方式並參照附加圖式描述，在其中：圖1為一流程圖，描述用於實施一付款服務或付款介面的一種方法，該方法用於為一或多個客戶啟用與一區塊鏈相關聯的數位資產交易，該方法藉由一付款處理器根據一第一態樣所實施。圖2為一流程圖，描述用於請求處理一區塊鏈交易之的一種方法，該區塊鏈交易與相關聯於一客戶的一數位資產付款方法相關聯，在此，該方法係根據一第二態樣由與一客戶相關聯之一或多個處理器所實施。圖3為一流程圖，描述處理一區塊鏈交易的一種方法，該區塊鏈交易與用於一客戶的一數位資產付款相關聯，在此，該方法係根據一第三態樣藉由與一礦工相關聯的一或多個處理器所實施。圖4為一概要圖，例示說明用於提供一付款服務或付款介面的一系統，以使一客戶可用區塊鏈交易。圖5為一概要圖，描述與一第一請求相關聯之資料流，該第一請求用於獲得與複數個礦工相關聯之費用報價。圖6為一概要圖，描述與一第二請求相關聯之資料流，該第二請求用於基於一所選擇費用報價而提出一交易。圖7為一概要圖，描述與基於一區塊鏈交易識別符之一狀態查詢相關聯的資料流。圖8為一概要圖，例示說明一電腦環境，在其中可實施本揭露各種態樣與實施例。

402:客戶

404:付款處理器

406:API轉換器

408:防火牆

410:節點連接器

412-1、412-2~412-n:礦工

Claims

一種電腦實施方法，其為一或多個客戶對與一區塊鏈相關聯之交易提供一付款服務，該方法由一付款處理器實施且包含下列步驟：從一客戶處接收與在一區塊鏈中開採一交易相關聯的一第一請求；發送一費用報價的一請求給與該付款處理器通訊式耦接之複數個礦工中的各個礦工；從各個礦工處獲得用於開採該交易的一費用報價；以及提供從該等複數個礦工處所獲得的費用報價給該客戶，其中用於開採該交易的一所選擇費用報價係基於所獲得費用報價而判定；或基於所獲得費用報價而判定用於為該客戶開採該交易的一所選擇費用報價。
如請求項1中所請求的方法，其中與該第一請求相關聯的該交易包括一批多個交易。
如請求項1或2中所請求的方法，包含下列步驟：回應於來自該客戶的一第二請求，該第二請求為提出關於在所獲得費用報價中的該所選擇費用報價的一給定交易，發送一請求至該等複數個礦工中之一或多個礦工以產生對應於該給定交易的一區塊鏈交易；從該等複數個礦工中滿足該所選擇費用報價的至少一礦工處，接收與該對應區塊鏈交易相關聯的一輸出腳本；以及發送一結果至該客戶，該結果包括用於對應於該給定交易之該區塊鏈交易的一交易識別符。
如請求項3中所請求的方法，其中該給定交易包括一批多個交易。
如任一先前請求項中所請求的方法，其中提供所獲得費用報價的步驟進一步包含基於所獲得費用報價的平均值或在所獲得費用報價中的最大值而判定一建議費用報價。
如請求項5所請求的方法，進一步包含提供該建議費用報價或提供包括該建議費用報價的全部所獲得費用報價，其中該建議費用報價包括一識別符。
如請求項5或7任一者所請求的方法，其中所選擇費用報價與該建議費用報價相同或與該建議費用報價不同，其中不同費用報價為預定或任意選擇。
如任一先前請求項中所請求的方法，其中判定一所選擇費用報價的步驟包含從複數個服務層級中指定一服務層級至所獲得費用報價的各者，各服務層級係與用於開採該交易的一各別所選擇費用報價相關聯。
如請求項8所請求的方法，其中該服務層級係基於所獲得費用報價與一最小中繼費用而指定，該最小中繼費用係與關於該各別費用報價的礦工相關聯。
如請求項8或9任一者所請求的方法，其中該指定服務層級係指示要開採該交易的一優先性，及/或針對該建議費用之與一交易相關聯的雙重花費保護的一層級。
如請求項8至10任一者所請求的方法，其中針對將要被開採之該交易的該服務層級係基於從該客戶處所獲得的一或多個服務需求而被指定。
如先前任一請求項中所提出的方法，包含驗證該等複數個礦工中之一給定礦工的身分的步驟，其中該驗證係基於與該給定礦工相關聯的一數位簽章或基於關於該給定礦工的一識別符，該識別符係可選擇地與針對該給定礦工的一信譽指示器相關聯。
如任一先前請求項中所請求的方法，包含基於一礦工簽章而驗證從該等複數個礦工中之一給定礦工處所獲得的一各別費用報價的步驟，該礦工簽章作為來自該給定礦工以該各別費用報價開採該交易並可選擇地拒絕任何衝突交易的一承諾。
如任一先前請求項中所請求的方法，其中從各礦工處獲得的該費用報價係以一資料類型提供，該資料類型為JavaScript 物件表示法（JSON）物件格式。
如任一先前請求項中所請求的方法，其中該所接收輸出腳本為與針對該至少一礦工之一記憶池相關聯的未花費交易輸出(UTXO)，該UTXO包括用於該區塊鏈交易的交易識別符（TxID）。
如任一先前請求項中所請求的方法，包含下列步驟：回應於來自該客戶之與一交易識別符相關聯的一狀態查詢，發送一請求至該等複數個礦工以獲得對應於該交易識別符的一區塊鏈交易；從該等複數個礦工中之至少一礦工處獲得該對應區塊鏈交易；以及發送關於所獲得區塊鏈交易的一狀態結果給該客戶。
如任一先前請求項中所請求的方法，其中該付款處理器係實施為用於一或多個客戶的一表現狀態轉移(REST)端點，並且其中該方法進一步包含提供與該付款處理器相關聯之一應用程式介面（API）轉換器的步驟以進行下列步驟：使用一超文本傳輸協定安全 (HTTPS)傳輸協定格式從該客戶處接收該第一請求及/或該第二請求及/或關於該給定交易的一狀態查詢；轉換該各別請求為一遠端程序呼叫 (RPC)格式，且發送該RPC至該等複數個礦工之一或多者；以一RPC格式從該等複數個礦工之中之一或多個礦工處接收與一對應區塊鏈交易相關聯的回應；以及轉換該等各別回應使其可使用HTTP傳輸協定被發送至該客戶。
一種電腦實施方法，用於處理與一區塊鏈相關聯之交易，該方法係由與一客戶相關聯之一或多個處理器實施，該客戶係與為該客戶實施一付款服務的至少一付款處理器通訊式耦接，該方法包含下列步驟：發送一第一請求到至少一付款處理器中的一付款處理器，該請求關於用於開採一交易的一或多個費用報價，該交易相關於來自一顧客的一數位資產付款；以及回應於來自該付款處理器之一或多個費用報價的接收，從該一或多個所接收費用報價中選擇一費用報價。
如請求項18所請求的方法，包含下列步驟：請求及/或處理來自該顧客的該數位資產付款，該請求與該所選擇費用報價相關聯；發送一第二請求至該付款處理器以將與來自該顧客之該數位資產付款相關聯的一給定交易提出給該區塊鏈，該提出係基於用於開採該給定交易的該所選擇費用報價；以及獲得對應於所提出交易之一區塊鏈交易的一交易識別符(TxID)。
如請求項19所請求的方法，其中在該第二請求中之該給定交易包括一批多個交易。
如請求項18至20中任一者所請求的方法，包含下列步驟：發送與該所獲得交易識別符相關聯的一狀態查詢；以及獲得對應於該區塊鏈識別符之該區塊鏈交易的一狀態結果。
如請求項18至21中任一者所請求的方法，其中該客戶包括該至少一付款處理器或與該至少一付款處理器通訊式耦接，該至少一付款處理器係組配以實施如請求項1至17中任一者所請求的方法。
如在請求項18至22中任一者所請求的方法，其中該第一請求及/或該狀態查詢為一HTTPS GET請求，並且其中該第二請求係為一HTTPS POST請求。
如請求項18至23中任一者所請求的方法，其中選擇一費用報價的步驟包含判定該等所獲得費用報價的一平均值，以及基於所判定平均來選擇一費用報價。
如請求項18至24中任一者所請求的方法，其中選擇一費用報價的步驟包含判定在所獲得費用報價中一費用報價的最大值，以及基於該最大值來選擇一費用報價。
如請求項18至25中任一者所請求的方法，其中與該第一及/或第二請求及/或該狀態查詢相關聯的資料係以一JavaScript 物件表示法（JSON）物件格式提供。
一種電腦實施方法，用於處理與一區塊鏈相關聯之交易，該方法係由與複數個礦工中之一礦工相關聯的一或多個處理器來實施，該等複數個礦工係通訊式耦接於為一客戶實施一付款服務的至少一付款處理器，該方法包含下列步驟：從一付款處理器處接收用於開採與該客戶相關聯之一交易的一費用報價的一第一請求；以及提供關於該礦工在該區塊鏈中開採該交易的一目前費用報價，其中該目前費用報價代表以該目前費用報價開採一交易的一承諾（undertaking）。
如請求項27所請求的方法，包含下列步驟：回應於關於要提出與該客戶相關聯之一給定交易給該區塊鏈的一第二請求，該給定交易係基於一所選擇費用報價，該方法進一步包含下列步驟：基於與該給定交易相關聯之所選擇費用報價滿足該礦工之該目前費用報價的一判定，產生對應於該給定交易的一區塊鏈交易；針對該區塊鏈交易產生一輸出腳本（UTXO）；添加產生之輸出腳本至與該礦工相關聯之一記憶池；以及發送該輸出腳本至該付款處理器，其中該輸出腳本包括與該對應區塊鏈交易相關聯的一交易識別符（TxID）。
如請求項28所請求的方法，其中包含回應於對與該交易識別符相關聯之一狀態的一請求，基於該對應區塊鏈交易的一開採狀態回傳一結果。
如請求項27至29中任一者所請求的方法，其中提供該目前費用報價的步驟及/或發送該輸出腳本的步驟及/或回傳該結果的步驟係實施為一遠端程序呼叫（RPC）。
如請求項30所請求的方法，包括在為該客戶透過一無線通訊網路傳遞該RPC至該付款處理器以前，從該礦工處發送該RPC至一節點連接器，且選擇地針對該等複數礦工之一防火牆的步驟。
如請求項27至31中任一者所請求的方法，其中基於與該給定交易相關聯的該所選擇費用報價不滿足該礦工的該目前費用報價的一判定，添加與一對應區塊鏈交易相關聯的一輸出至與該礦工相關聯的一次要記憶池。
如請求項27至32中任一者所請求的方法，其中該礦工係與至少一付款處理器通訊式耦接，該付款處理器係組配以實施請求項1至9中任一者所請求之方法，並且其中該至少一付款處理器係與一客戶相關聯或與一客戶通訊式耦接，該客戶係組配以實施請求項12至19中任一者所請求之方法。
一種電腦實施方法，其為一或多個客戶提供針對與一區塊鏈相關聯之交易的一付款服務，該方法係由一付款處理器實施，且包含下列步驟：接收或同意來自一客戶之用於將在一區塊鏈中被開採的交易的一或多個服務要求；接收來自一客戶之用於在一區塊鏈中開採一或多個交易的一第一請求；發送針對一費用報價的一請求給與該付款處理器通訊式耦接的複數個礦工中的各礦工；從各礦工處獲得用於開採該一或多個交易的一費用報價；分類所獲得費用報價成為提供來開採之複數個服務層級中之一給定服務層級，各服務層級係與一組開採費用相關聯；基於所接收到的該一或多個服務要求而為該客戶判定一服務層級；其中與所判定服務層級相關聯的該組開採費用係用於開採與該客戶相關聯的一或多個交易之該所選擇費用報價，並且其中該所判定服務層級係指示開採該交易的優先性及/或防止雙重花費之保護的一層級。
一種計算裝置，其包含一處理器與記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令致使該裝置進行如請求項1至17與33任一者中所請求之電腦實施方法，該計算裝置關於一付款處理器。
一種計算裝置，其包含一處理器與記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令致使該裝置進行如請求項18至26任一者中所請求之電腦實施方法，該計算裝置關於一客戶。
一種計算裝置，包含一處理器與記憶體，該記憶體包括可執行指令，作為由該處理器執行之一結果，該等可執行指令致使該裝置進行如請求項27至33任一者中所請求之電腦實施方法，該計算裝置關於一礦工。
一種電腦系統，其包含：一付款處理器，其經由一無線通訊網路通訊式耦接於至少一客戶與至少一礦工，該付款處理器選擇性地與一API轉換器相關聯，以用於來自該客戶之HTTPS請求至用於該礦工之RPC請求的轉換，且反之亦然，其中該付款處理器係根據請求項35中所請求之計算裝置而實施；一客戶，其經由該無線通訊網路通訊式耦接於該付款處理器，且其可與至少一顧客通訊；該客戶係根據如請求項36中所請求之計算裝置而實施；以及複數個礦工，其經由該無線通訊網路通訊式耦接於該付款處理器，各礦工係根據如請求項37中所請求之計算裝置而實施。
一種電腦可讀儲存媒體，其上儲存有可執行指令，作為被一電腦的一處理器執行之結果，該等可執行指令致使該電腦進行請求項1至34任一者的方法。