使用OmniCore在Unix系统上构建USDT钱包(二)

image

本篇是关于“如何使用OmniCore在服务端构建USDT钱包”系列的下篇，主要是对上一篇《使用OmniCore构建USDT钱包(一)》的补充和总结。上一篇主要对安装、配置和基本json-api使用，以及交易所钱包模型做了简略的说明，这一篇将对常见错误、安全机制以及其他扩展做一些技术分享。

1.omni_funded_send -212错误

从v0.3.1开始omnicore提供了新的转账api omni_funded_send 来支持USDT的转账操作。与之前的方式不同在于，omni_funded_send支持从第三方支付手续费。但在实际操作，明明拥有充足的btc用于支付手续费，也有充分的usdt用于转账，还是会频繁出现编号-212错误：

$ ./omnicore-cli omni_funded_send "mrAVAPxdQEZxFkunh56skB6sgJa6vrfrpo" "msJ2h47ZrxFJjksVvPy8ik4h2HFfa9W1zV" 31 "100.01" "mpaumxor659PhoJhXp1VCVHVwbFCZSRmuf"
error code: -212
error message:
Error choosing inputs for the send transaction

issues/760#详细讨论了这个问题。

USDT的转账本质上属于比特币的一种特殊交易(OP_RETUTRN)，需要一部分BTC来支付矿工费用。同时，根据omnilayer协议，还需要微量的比特币用于标记omni事务的接受者，这部分btc无法从手续费地址扣除，只能从发送地址扣除。因此，当发送地址缺乏btc（也就是UTXO）时，会出现 “Error choosing inputs for the send transaction”的错误。经过测试，默认情况下用于标记omni事务的BTC为0.0000546。因此解决这个问题的唯一方法是向发送地址中转入>0.000055的BTC。

但需要注意的是，发送地址上的某个UTXO将全部消耗掉，不会有找零。例如A地址向B地址转移USDT，A地址中拥有两个UTXO，分别为0.0001和0.0002，那么转账成功后，0.0001的UTXO将会被消耗掉，只剩下额度为0.0002的UTXO。

但在交易所模式下，这种错误几乎不会发生。因为在中心化钱包的模式下，充值的过程会自动携带了微量的btc，这一部分比特币足够用于标记omni事务，用于下一次转账，但也仅限一次。因此，只要不使用同一个地址发送两次USDT，这种错误几乎不会出现。

值得注意的是，转账错误也可能会消耗掉发送地址下的微量utxo，所以，当发生这种错误时，需要查询出缺少微量utxo的地址并进行btc的转账。但这里会引发另外一个问题，就是批量转移微量btc时，会发生code:-26 message: dust的错误。

2.dust错误

拒绝粉尘攻击其实是比特币钱包的一个安全机制，当钱包或节点检测到非常微小的比特币交易时，会自动把这笔交易从缓冲区里面清除出去，甚至都不让进入缓冲区就直接拒绝掉了。这是一种维护比特区块安全通畅的一种手法。当为了usdt转账的成功，像发送地址转账微量btc时，会触发这种机制。解决方法是修改配置文件中的minrealytxfee参数，令minrealytxfee=0.000000055，可以让钱包允许这笔比特币交易。但这么做🈶️可能会引发另外一个问题，修改这个参数后，可能造成usdt的转账被堵死在自己钱包的缓冲区里面，无法将交易广播出去。一个明显的特征是，你可以在构建usdt交易并且好像发送成功，并在缓冲区看到了这笔交易，但在任何比特币区块浏览器上都无法找到这笔交易。解决这个问题的方式需要将minrealytxfee从配置中删除或恢复默认值。

3.usdt的交易可以取消吗？？

这种问题需要分情况分析，如果交易已经广播出去了（哪怕手续费是0都可广播出去），也就是区块链浏览器上可以查询到了（注意这里指的是比特币的区块浏览器），那么这笔交易是无法被取消的。面对迟迟不能确认的交易，唯一能做的就是额外给矿工一笔钱，让他优先把你的交易打包进区块,如果你不愿意与矿工发生这种PY交易，那么只能继续等待。目前大部分矿池都支持这种服务，俗称交(hui)易(luo)加(kuang)速(gong)。
还一种情况是，虽然交易是构建成功了，产生了交易id，但始终没有广播出去。交易一直在你的钱包里面躺着，区块浏览器上一直查不到。那么这种情况是可以撤销的，解决的方案是在配置文件中设置zapwallettxes=1,然后重启启动。重启后缓冲区中的交易会被清空掉，并重新开始扫描，接收自己或其他节点的交易信息。如果你还配置了minrealytxfee，那么记得在重启前把这个参数恢复默认值或干脆删除掉。这里需要解释的是，为什么区块浏览器查不到的交易可以确认没有被广播出去？原因是区块浏览器其实也是一个节点，而且属于那种不挑食的节点，无论你是没有支付手续费的交易，还是粉尘交易，只有验证通过他都会接收。如果区块浏览器的节点都收不到的交易，那么其他节点更不会接收。
当然，如果你的目的并非撤销这一笔未广播的交易，而是重新发送他，那么只需要获取这笔交易的交易id，然后使用getrawtransaction 获取raw数据，再通过sendrawtransaction进行重新广播即可。只要拿到raw数据，通过任何联网的方式都可以发送到其他节点上去。

4. 钱包安全

数字资产不同于一般性的资产，一旦被盗或丢失，几乎无法找回，也无法进行数据回滚。对于中心化的钱包而言，用户本身对资产没有直接控制权，所有的资产安全性全部取决于中心化钱包的安全策略，因此非常有必要对安全性进行设计。以下方式仅供参考。

4.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 为全地址访问。正式环境下，需要配置为制定的访问服务器地址或者本地地址。值得注意的是，这里的安全原理是限定钱包访问对象，一旦密码泄漏或服务器被黑，那么整个钱包相当于裸奔。

4.2 离线生成地址

资产的唯一凭证是私钥，因此私钥的保存非常重要。一般情况下，根据业务需求，服务端需要给每个用户分配一个地址。这里的建议是不应该分配地址的时候“即使”的去调用getnewaddresss，而是通过离线的方式批量生产大量地址，然后连同地址、私钥保存到数据库，同时导出地址列表给服务端进行使用。这样服务端需要分配地址时，只需要从数据库读取即可，而不需要与钱包进行交互。

为了私钥的安全性，保存到数据库时可以进行二次加密。

4.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);
    }

4.4 冷钱包

冷钱包即不联网的钱包。对于交易所模式下而言，钱包的作业其实就相当于银行的存款系统，充值的过程相当于把金额全部汇总到中央地址。因此可以使用一台不联网的钱包生成中央地址若干，将私钥保存到U盘或其他加密硬件中，充值金额将汇集到冷钱包中保存。一旦需要提现，可以根据金额大小。小额提现可以通过热钱包直接发消息转账；大额可以使用需要使用指定U盘将私钥或钱包文件导入到钱包中，然后联网转账。操作完成后断网，重新保存硬件即可。

这一过程需要注意，冷钱包因为无法联网,自然也无法知道余额。那么可以设置观察钱包对中央钱包地址进行余额观察，以确保充值到账。在实际业务中，提现过程可能还需要人工进行审核。

4.5 钱包与服务端隔离

一般情况下，钱包与服务端会部署在同一台服务器上。这种方式有两个缺陷，第一是钱包需要的存储空间庞大，但需要的网络带宽很低，与业务相关的服务器部署子啊同一服务器上将造成资源的浪费。第二是这种方式有一些安全隐患。所以建议钱包单独部署到一台服务器上，如果业务允许，还可以同时备份到多台冗余服务器上。钱包与服务端的通讯可以使用 “消息队列”。

注意使用Queue，而不是Topics，同一时间内，只有一个消费者和一个生产者。