### 獲取當前區塊 ``` {"method":"omni_getinfo"} ``` ### 獲取地址余額 ``` $this->bitcoin->omni_getbalance("n4cjbUjEL4hKBfbyK96W5CWWvsQWxok6wG",31) ``` ### 獲取所有錢包地址 ``` $this->bitcoin->getaddressesbyaccount('') ``` ### 根據區塊高度獲取區塊hash ``` $this->bitcoin->getblockhash(628087); ``` ### 根據區塊hash查詢區塊信息 ``` $this->bitcoin->getblock($hash); ``` ### 獲取測試幣 [水龍頭網站，需要翻墻 https://coinfaucet.eu/en/btc-testnet/](https://coinfaucet.eu/en/btc-testnet/) ### ``` $ ./omnicore-cli getinfo { "version": 130200, "protocolversion": 70015, "walletversion": 130000, "balance": 4.85909131, //錢包比特幣總余額 "blocks": 1413349, "timeoffset": 0, "connections": 0, "proxy": "", "difficulty": 56234572.68927951, "testnet": true, //是否是測試網 "keypoololdest": 1535371434, "keypoolsize": 100, "paytxfee": 0.00010000, "relayfee": 0.00001000, "errors": "" } ``` ``` $ ./omnicore-cli omni_getinfo { "omnicoreversion_int": 30001000, "omnicoreversion": "0.3.1", //omni core 版本 "mastercoreversion": "0.3.1", "bitcoincoreversion": "0.13.2", //基于比特幣版本 "block": 1413349,//區塊要舉高高 "blocktime": 1536841368, "blocktransactions": 0, "totaltrades": 15601, "totaltransactions": 43731, "alerts": [ ] } ``` ### 四.中心化錢包模式 中心化錢包的本質是代替用戶托管資產，錢包保存了所有地址的私鑰，對上面的令牌有完全的使用權。對于用戶而言，對資產的流動有知情權，但并沒有實際控制權。一個完整的中心化錢包可以分為兩層，記賬層和區塊底層，至少需要集成四個基本的業務功能： 1.地址生成 USDT地址即比特幣區塊鏈上的地址，借助比特幣內核`getnewaddress`可以從同一個種子推導出無數個地址，生成地址的過程類似與把一枚硬幣連續拋255次。服務端需要在自己的用戶系統中為每個用戶生成不同的地址，用戶的看到的資產實際上服務端的記賬狀態，并非真實資產。 2.掃描充值事務 錢包一旦啟動，會開啟同步區塊的守護進程，服務端不需要進行手動的區塊同步操作。但服務端需要定期的掃描區塊以發現并確認充值事務。通過`omni_listtransactions`可以查詢當前錢包內的事務列表，根據業務需要，可以定時每小時全量掃描一次，每次最多返回100條事務。遍歷每條事務，如果事務已經驗證且確認數大于等于6，那么被認為是一條有效的充值記錄。然后判斷記賬層是否已經記錄了該事務，如果沒有記錄則寫入充值記錄表，同時查詢綁定該地址的用戶，在余額表中該用戶的可用余額加上充值金額。如果已經寫入了那么跳過本次事務。單次的事務處理流程如下:  這是最簡易的模式，根據業務情景可以適當調整掃描周期和最大事務數。 3.轉移充值余額 用戶充值后USDT保留在用戶綁定的區塊地址中，需要及時的轉移到中央地址中去。中央地址即保存整個平臺資產的一個或者多個地址。可以使用與普通用戶相同的“種子”，也可以單獨使用一個錢包，或者直接使用冷錢包離線保存。在保證安全和效率的情況下，越少的轉賬次數越好，可以最大限度的節省手續費。獲取錢包地址USDT余額列表有多種方式 ，從v0.3.1開始可以使用`omni_getwalletaddressbalances`直接返回所有每個地址的所有令牌列表。一旦檢測id=31的令牌余額不為0，且大于最小額度（一般大于預估的手續費）則使用`omni_funded_sendall`轉移所有的USDT到指定的中央錢包。 但需要注意的是，在Omnicore上從發送者轉賬轉移指定id的令牌到接受者，當交易被創建且被發送成功后，交易驗證需要一定時間，發送者的令牌余額不會立即變化。所以如果掃描余額的時間周期太短，會造成一個地址上的余額被多次轉移，雖然只會有一次成功但會重復消耗手續費，所以建議2-6hour掃描一次本地錢包余額列表。 4.提現事件 提現是指用戶把實際資產從平臺錢包中轉移出去，只要判斷是本人操作而且提現金額小于可用額度就被認為是有效的提現請求。根據提現地址的不同有兩種情況： 當提現地址是錢包內的地址時（即平臺內的另外一個用戶）屬于內部轉賬。這種方式并不需在從中央錢包發送USDT到指定地址，只需要在記賬層進行依次對兩個賬戶上的USDT余額進行修改，幾乎沒有時間延遲。 當提現地址是不是錢包內的地址時（非平臺用戶）屬于外部轉賬。這種方式需要操作區塊鏈，不會馬上進行確認，根據手續費設定和當前比特幣主網擁堵狀況可能需要幾小時到一天的確認時間。 對于外部轉賬，如果用戶綁定的區塊地址上還存在余額，那么優先使用該地址進行轉賬，其次選擇中央錢包進行轉賬。可以使用`omni_funded_send`來進行創建USDT交易并廣播，交易發送成功后會生成的事務哈希。根據事務哈希，通過`omni_gettransaction`可以進行提現進度的跟蹤。  ### 五.補充 ### 1.omni\_funded\_send -212錯誤 從v0.3.1開始omnicore提供了新的轉賬api[omni\_funded\_send](https://github.com/OmniLayer/omnicore/blob/master/src/omnicore/doc/rpc-api.md#omni_funded_send)來支持USDT的轉賬操作。與之前的方式不同在于，omni\_funded\_send支持從第三方支付手續費。但在實際操作，明明擁有充足的btc用于支付手續費，也有充分的usdt用于轉賬，還是會頻繁出現編號**\-212**錯誤： ~~~ $ ./omnicore-cli omni_funded_send "mrAVAPxdQEZxFkunh56skB6sgJa6vrfrpo" "msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV" 31 "100.01" "mpaumxor659PhoJhXp1VCVHVwbFCZSRmuf"error code: -212error message:Error choosing inputs for the send transaction ~~~ [issues/760#](https://github.com/OmniLayer/omnicore/issues/760#issuecomment-434745561)詳細討論了這個問題。 USDT的轉賬本質上屬于比特幣的一種特殊交易(**OP\_RETUTRN**)，需要一部分BTC來支付礦工費用。同時，根據omnilayer協議，還需要微量的比特幣用于標記omni事務的接受者，這部分btc無法從手續費地址扣除，只能從發送地址扣除。因此，當發送地址缺乏btc（也就是UTXO）時，會出現 “*Error choosing inputs for the send transaction*”的錯誤。經過測試，默認情況下用于標記omni事務的BTC為0.0000546。因此解決這個問題的唯一方法是向發送地址中轉入>0.0000546的BTC。 但需要注意的是，發送地址上的某個UTXO將全部消耗掉，不會有找零。例如A地址向B地址轉移USDT，A地址中擁有兩個UTXO，分別為0.0001和0.0002，那么轉賬成功后，0.0001的UTXO將會被消耗掉，只剩下額度為0.0002的UTXO。 但在交易所模式下，這種錯誤幾乎不會發生。因為在中心化錢包的模式下，充值的過程會自動攜帶了微量的btc，這一部分比特幣足夠用于標記omni事務，用于下一次轉賬，但也僅限一次。因此，只要不使用同一個地址發送兩次USDT，這種錯誤幾乎不會出現。 ### 2\. 錢包安全 數字資產不同于一般性的資產，一旦被盜或丟失，幾乎無法找回，也無法進行數據回滾。對于中心化的錢包而言，用戶本身對資產沒有直接控制權，所有的資產安全性全部取決于中心化錢包的安全策略，因此非常有必要對安全性進行設計。以下方式僅供參考。 2.1 限制訪問權限 omnicore基于bitcore，自帶有加密訪問權限設置,可以通過bitcoin.conf文件可以進行配置。 ~~~ rpcuser=你的rpc用戶名rpcpassword=你的rpc密碼rpcallowip=127.0.0.1 rpcport=8332 ~~~ 其中`rpcuser`和`rpcpassword`分別配置訪問用戶和訪問密碼，`rpcallowip`和`rpcport`分別配置可訪問的網絡地址。測試環境下，該地址可以為0.0.0.0/0 為全地址訪問。正式環境下，需要配置為制定的訪問服務器地址或者本地地址。值得注意的是，這里的安全原理是限定錢包訪問對象，一旦密碼泄漏或服務器被黑，那么整個錢包相當于裸奔。 2.2 離線生成地址 資產的唯一憑證是私鑰，因此私鑰的保存非常重要。一般情況下，根據業務需求，服務端需要給每個用戶分配一個地址。這里的建議是不應該分配地址的時候“即使”的去調用`getnewaddresss`，而是通過離線的方式批量生產大量地址，然后連同地址、私鑰保存到數據庫，同時導出地址列表給服務端進行使用。這樣服務端需要分配地址時，只需要從數據庫讀取即可，而不需要與錢包進行交互。 > 為了私鑰的安全性，保存到數據庫時可以進行二次加密。 2.3 錢包文件備份 錢包文件的備份可以直接使用bitcore的導出數據方式`dumpwallet`,每天定期保存到文件,例如： ~~~ /*** * 導出錢包數據以人類可讀的方式 * @param: [] * @return: java.lang.String **/ public String dumpWallet() { System.currentTimeMillis(); String time = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()); String file = String.format("wallet-%s.txt", time); http.engine("dumpwallet", file); return file; } ~~~ 一旦需要恢復，使用`importwallet`即可，例如： ~~~ /*** * 錢包數據導入 * @param: [] * @return: void * https://bitcoin.org/en/developer-reference#importwallet *對于影響新添加的密鑰的事務，調用可能需要重新掃描整個鏈，可能需要幾分鐘。 **/ public void importWallet(String fielName) { http.engine("importwallet", fielName); } ~~~ 2.4 冷錢包 冷錢包即不聯網的錢包。對于交易所模式下而言，錢包的作業其實就相當于銀行的存款系統，充值的過程相當于把金額全部匯總到中央地址。因此可以使用一臺不聯網的錢包生成中央地址若干，將私鑰保存到U盤或其他加密硬件中，充值金額將匯集到冷錢包中保存。一旦需要提現，可以根據金額大小。小額提現可以通過熱錢包直接發消息轉賬；大額可以使用需要使用指定U盤將私鑰或錢包文件導入到錢包中，然后聯網轉賬。操作完成后斷網，重新保存硬件即可。 > 這一過程需要注意，冷錢包因為無法聯網,自然也無法知道余額。那么可以設置觀察錢包對中央錢包地址進行余額觀察，以確保充值到賬。在實際業務中，提現過程可能還需要人工進行審核。 2.5 錢包與服務端隔離 一般情況下，錢包與服務端會部署在同一臺服務器上。這種方式有兩個缺陷，第一是錢包需要的存儲空間龐大，但需要的網絡帶寬很低，與業務相關的服務器部署子啊同一服務器上將造成資源的浪費。第二是這種方式有一些安全隱患。所以建議錢包單獨部署到一臺服務器上，如果業務允許，還可以同時備份到多臺冗余服務器上。錢包與服務端的通訊可以使用 “消息隊列”。 > 注意使用**Queue**，而不是**Topics**，同一時間內，只有一個消費者和一個生產者。