MyEOSKit
by EOS ASIA
投票
网络监控
Explorer
帐号工具

Accts, txs, blocks

LIVE BLOCK STATUS
CURRENT BLOCK PRODUCER
eosfishrocks
SERVER VERSION
8777d8db
LATEST BLOCK
9,486,529
IRREVERSIBLE BLOCK
9,486,198
NODES
1
starteosiobp
Block Producer
...
9,225,922
9,225,922
994 EOS
View acct →
2
eoscanadacom
Block Producer
1317ms
9,226,029
9,226,029
960 EOS
View acct →
3
eosnewyorkio
Block Producer
388ms
9,225,863
9,225,863
942 EOS
View acct →
4
eoshuobipool
Block Producer
...
9,226,058
9,226,058
916 EOS
View acct →
5
zbeosbp11111
Block Producer
275ms
9,225,945
9,225,945
901 EOS
View acct →
6
libertyblock
Block Producer
513ms
9,225,910
9,225,910
894 EOS
View acct →
7
eos42freedom
Block Producer
642ms
9,225,969
9,225,969
861 EOS
View acct →
8
bitfinexeos1
Block Producer
567ms
9,225,957
9,225,957
855 EOS
View acct →
9
eosswedenorg
Block Producer
695ms
9,225,887
9,225,887
840 EOS
View acct →
10
eosbixinboot
Block Producer
604ms
9,226,017
9,226,017
824 EOS
View acct →
11
eosauthority
Block Producer
633ms
9,225,993
9,225,993
817 EOS
View acct →
12
eosfishrocks
Block Producer
644ms
9,226,053
9,226,053
816 EOS
View acct →
13
eosisgravity
Block Producer
880ms
9,225,841
9,225,841
813 EOS
View acct →
14
eosriobrazil
Block Producer
731ms
9,225,875
9,225,875
782 EOS
View acct →
15
eosdacserver
Block Producer
628ms
9,226,041
9,226,041
766 EOS
View acct →
16
eosbeijingbp
Block Producer
190ms
9,226,005
9,226,005
757 EOS
View acct →
17
teamgreymass
Block Producer
478ms
9,225,933
9,225,933
753 EOS
View acct →
18
argentinaeos
Block Producer
481ms
9,225,722
9,225,722
753 EOS
View acct →
19
helloeoscnbp
Block Producer
202ms
9,225,898
9,225,898
751 EOS
View acct →
20
eoslaomaocom
Block Producer
372ms
9,225,851
9,225,851
740 EOS
View acct →
21
eosamsterdam
Block Producer
719ms
9,225,981
9,225,981
736 EOS
View acct →
22
eosasia11111
Non-Producing Node
190ms
9,073,847
9,073,361
380 EOS
View acct →
23
eoscannonchn
Non-Producing Node
416ms
4,743,839
3,932,785
375 EOS
View acct →
24
jedaaaaaaaaa
Non-Producing Node
127ms
8,566,621
8,566,123
374 EOS
View acct →
25
cryptolions1
Non-Producing Node
816ms
6,223,022
6,222,532
370 EOS
View acct →
26
eoscleanerbp
Non-Producing Node
203ms
8,538,714
8,538,215
365 EOS
View acct →
27
eostribeprod
Non-Producing Node
1068ms
8,219,706
8,219,210
355 EOS
View acct →
28
eoscafeblock
Non-Producing Node
322ms
8,034,340
8,033,836
349 EOS
View acct →
29
eosliquideos
Non-Producing Node
802ms
7,492,295
7,492,295
341 EOS
View acct →
30
eosgenblockp
Non-Producing Node
881ms
5,336,950
4,855,087
337 EOS
View acct →
31
eosflytomars
Non-Producing Node
231ms
2,831,368
2,830,864
333 EOS
View acct →
32
eosnationftw
Non-Producing Node
542ms
5,337,478
5,336,986
328 EOS
View acct →
33
eosiomeetone
Non-Producing Node
205ms
3,932,329
3,931,827
321 EOS
View acct →
34
blocksmithio
Non-Producing Node
905ms
321 EOS
View acct →
35
cypherglasss
Non-Producing Node
710ms
8,034,280
8,033,776
299 EOS
View acct →
36
aus1genereos
Non-Producing Node
462ms
293 EOS
View acct →
37
superoneiobp
Non-Producing Node
1644ms
291 EOS
View acct →
38
eosdotwikibp
Non-Producing Node
...
288 EOS
View acct →
39
eosyskoreabp
Non-Producing Node
78ms
2,239,773
2,217,621
272 EOS
View acct →
40
eosafricaone
Non-Producing Node
895ms
262 EOS
View acct →
41
tokenika4eos
Non-Producing Node
718ms
253 EOS
View acct →
42
eosdublinwow
Non-Producing Node
689ms
246 EOS
View acct →
43
moreisfuture
Non-Producing Node
2606ms
246 EOS
View acct →
44
eosstorebest
Non-Producing Node
131ms
6,222,676
6,222,181
242 EOS
View acct →
45
atticlabeosb
Non-Producing Node
602ms
234 EOS
View acct →
46
eosantpoolbp
Non-Producing Node
1483ms
6,222,304
6,221,810
233 EOS
View acct →
47
eostitanprod
Non-Producing Node
476ms
232 EOS
View acct →
48
eosnairobike
Non-Producing Node
990ms
217 EOS
View acct →
49
sheos21sheos
Non-Producing Node
563ms
208 EOS
View acct →
50
oraclegogogo
Non-Producing Node
54132ms
197 EOS
View acct →
Previous
Page
1
of 9

Next
Loading...


Links & Resources
EOS Glossary →
Fullnode API endpoints →

Market Info
Current price $6.99
Market cap $6.33B

Service provided by EOS Asia
Join EOS Asia on Telegram →

寻找下一个百倍平台币（币安BNB、Fcoin，FT），比特大陆A轮2000万投资交易所，全球第四大矿池平台币CET，用我的推荐链接注册，每人送100CET。https://www.coinex.com/account/signup?refer_code=mgtse

GDEX 5月18日20:00首发IDHUB价格已确定
2018年5月17日 admin 官方公告
5月18日20点整，GDEX重磅首发IDHUB！目前GDEX官网、鼓鼓钱包CNY市场已挂出交易对，用户可提前挂买单！

（提示：是CNY市场，卖单价也是以CNY为单位）

此次Token首发额度共6,852,000枚，由GDEX负责承兑。

开放时间：

2018年5月18日 20:00（北京时间）

确定价格：

1GDEX.IDHUB=1.995 bitCNY

提示：

1、价格根据5月17日12:00 CoinMarketCap 上的 ETH美元价格计算，即为：1GDEX.IDHUB=（712.03*6.4）/2284 bitCNY =1.995 bitCNY

2、GDEX承兑的资产均有“GDEX”前缀，如IDHUB，显示资产名称为GDEX.IDHUB，请大家仔细辨认交易！

支付币种：
bitCNY

购买地址：

网页端：https://www.gdex.io（GDEX官网） />
手机端：http://t.cn/RQSDpLs（鼓鼓钱包） />
项目介绍
IDHUB是建立在开放原则之上，基于区块链技术的去中心化数字身份应用平台，具备良好的技术兼容性与功能拓展性。作为进入数字社会的入口，IDHUB通过区块链技术，对个人身份的有效性、真实性、唯一性进行合理验证，并力求将身份控制权由第三方信息服务机构重新收回到个人手中，为用户塑造完整、可信的“自主身份”，并构建以用户为主导的数字身份管理和应用平台以及安全、自主、可信的身份管理机制，最终实现以数字身份链接一切（社会服务、数字资产、数字生活等）的愿景。

Token 情况：
Token全称：IDHUB
简 称：IDHUB
Token总量：500,000,000 IDHUB（5亿）
限 量 首 发：6,852,000 GDEX.IDHUB（ 6,852,000 IDHUB）（仅包括GDEX售卖数量，其他平台数量不计入统计）

项目官网：
http://www.idhub.network/ />
白皮书地址：
http://www.idhub.network/data/IDHub_whitepaper_v0.4.2_cn.pdf />
关注GDEX公众号，参加GDEX.IDHUB转盘抽奖活动吧！

GDEX

5月17日




上一篇文章

分类目录
官方公告
币种资料
新手指南
费率标准

国内新增API节点汇总New APIs for Chinese users
« on: April 02, 2018, 02:30:47 am »
见证人响应巨蟹号召，建立了API节点，供更多的中国用户使用。后面会更新到官方钱包上。

各自按 “见证人账号+ location + API 节点地址”的格式累加式回复：

in.abit 美国：wss://api.bts.mobi/ws

witness.yao 新加坡：wss://kimziv.com/ws

xn-delegate 新加坡：wss://api.btsgo.net/ws

crazybit 中国wss://crazybit.online

winex.witness 新加坡 wss://ws.winex.pro

delegate.freedom 中国 wss://freedom.bts123.cc:15138

witness.hiblockchain 北京 wss://api.bts.ai

witness.still 香港 wss://bitshares.cyberit.io

abc123 香港 wss://bit.btsabc.org/ws

xman 东京 wss://ws.hellobts.com

delegate-zhaomu 美国（将迁香港） wss://blockzms.xyz/ws

magicwallet.witness 杭州 wss://bts.open.icowallet.net/ws

liuye 中国.山东联通 wss://bts.to0l.cn:4443/ws

delegate-zhaomu 美国（将迁香港） wss://blockzms.xyz/ws


« Last Edit: April 13, 2018, 03:13:12 pm by ripplexiaoshan »

BTS 交易所对接指南（单节点版）

此文目的是协助第三方交易所上线 BTS 交易。

此文所述方案为单节点方案。相对于此前另一篇文档描述的双节点方案来说，单节点方案可以节省内存、硬盘和同步时间。

1. 基本概念

1.1 共识

BTS 使用 DPOS 共识机制，由持有 BTS 的人投票产生区块锻造人，标准区块间隔时间是 3 秒。

1.2 账户

1) BTS里，资金是存在账户里的，不像比特币是存在地址里。对交易所来说，需要公开一个账号供用户充值。
可以使用网页钱包或者轻钱包注册新账号。
注意：对于交易所来说，注册账号请使用钱包模式，而不是账户模式，因为交易所要用到一些高级功能，在账户模式下会存在问题。
（如果是官方网页钱包或轻钱包 171102 或以上版本，第一次注册时默认是账户模式，可点击“高级”进入钱包模式）。
不是所有账号都可以免费注册，一般带横杠的或者数字的账号可以免费注册，比如 my-exchange ，或者 myexchange2017 。
在轻钱包账户页面里，账号下面会显示一个数字，这个数字是该账号在 BTS 系统里的内置ID，下面会用到。
注：官方网页钱包或轻钱包 171102 或以上版本，不再显示该数字。
可以到区块链浏览器 https://cryptofresh.com/ 输入账号名获取账户 ID ，
也可以自建节点同步完成后在钱包里通过命令获取 ID ，获取命令参考“提现目的账号名检查”章节。
为了资金安全，交易所可以用一个账号负责充值，另用一个账号负责提现。

2) 用户充值，就是从其他账号转账到交易所的公开的账号。
账号名就是收款地址。
每笔转账可以带一个备注，交易所通过这个备注来区分是哪个用户的充值。
具体备注与交易所用户关联关系，请交易所自行设定。
备注是加密的，只有拥有发送者或者接收者的备注密钥才可以解密。

3) 用户提现，就是从交易所账号转账到用户账号，目的账号名由用户提供。
由于有用户需要把资金直接从一个交易所转到另一个交易所，而另一个交易所是根据备注入账，所以提现功能最好可以带备注。

4) 使用网页钱包注册的账号是基本账号。可付费升级为终身会员账号，升级后，后续交易手续费节省 80% 。
终身会员可以创建新账号。
当前手续费费率标准可以在钱包内查看，从界面依次点击 浏览-费率表 进入。

5) 每个账号默认有3对密钥，可以在账户-高级设定-权限页面里查看，分别为：活跃权限、账户权限、备注密钥。
其中，活跃权限密钥用于转账等日常操作；账户权限密钥用于修改密钥；备注密钥用来加密和解密转账备注。
默认情况下，活跃权限密钥与备注密钥相同，但可以修改为不同。
以上 3 对密钥都可以修改。其中，账户权限为最高权限，可以修改所有密钥；使用活跃权限密钥不能修改账户权限密钥，但可以修改其他两个密钥。


1.3 资产

1) BTS 系统里有多种资产，其中，核心资产是 BTS 。交易所上线 BTS 系统内其他资产的方法，与上线核心资产（BTS）的方式类似。

2) 每个账户可以同时拥有多种资产。


1.4 块链结构

每个块有个 ID，即 block_id，该 ID 是块内容的 hash 值；
每个块包含前一块的 ID，存放在 "previous" 字段，因此形成一个链；
每个块里包含多个交易，存放在 "transactions" 字段，按顺序存放；
使用 API 获取块信息时，会同时返回 "transaction_ids" 字段，即交易 ID 清单，是交易（不包含签名）序列化后的 hash 值
每个交易可包含多个操作，存放在 "operations" 字段，按顺序存放；
每个操作也有一个 ID ，是一个全局数字编号，是程序运行中内部产生的，不是 hash 值


2. 基础软硬件需求

独立服务器或者VPS
8G 内存（更多更好）
50G 硬盘

安装 64 位 Ubuntu 16.04 LTS （推荐） ，或者 Ubuntu 14.04 LTS ，或者 Windows Server 。


3. 程序准备

要对接 BTS 系统，需要运行这几个程序：普通节点 witness_node 、命令行钱包 cli_wallet 。

3.1 架构说明

witness_node 通过 P2P 方式连接到 BTS 网络，从网络接收最新区块，向网络广播本地签署的交易包；
witness_node 通过 websocket + http rpc 的方式提供 API 供其他程序调用（以下称为节点 API）。

cli_wallet 通过 websocket 方式连接到 witness_node 。
cli_wallet 管理钱包文件，钱包文件里包含经过加密的用户私钥，一个钱包文件可以包含多个私钥。
可以同时运行多个 cli_wallet 进程，同时连到 witness_node ，用来同时管理多个钱包文件。
cli_wallet 提供交易签名功能，签名后通过 witness_node 向外广播。
cli_wallet 通过 http rpc 的方式提供 API 供其他程序调用（以下称为钱包 API）。

推荐交易所使用一个 cli_wallet 来监测用户充值，使用另一个 cli_wallet 来处理用户提现请求。


3.2 Windows

Github 上提供编译好的 Windows 可执行文件下载，下载页面在 https://github.com/bitshares/bitshares-core/releases/latest ，
文件为 BitShares-Core-2.0.xxxxxx-x64-cli-tools.zip ，解开即可，里面包含 3 个 exe 文件和两个 dll 文件。

3.3 Linux

如果使用 Linux 系统，需要自行编译几个上述程序。推荐使用 Ubuntu 16.04 LTS ，编译步骤如下：

sudo apt-get update
sudo apt-get install autoconf cmake git libboost-all-dev libssl-dev doxygen g++ libcurl4-openssl-dev

git clone https://github.com/bitshares/bitshares-core.git />cd bitshares-core
git checkout <LATEST_RELEASE_TAG>
git submodule update --init --recursive
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make witness_node cli_wallet

注：上述步骤中，请将 <LATEST_RELEASE_TAG> 替换成最新发布版本号，编写本文时，最新版本号是 2.0.171105a

编译完成后，得到两个可执行程序分别是：
* build/programs/witness_node/witness_node
* build/programs/cli_wallet/cli_wallet

上述程序可以拷贝到其他目录或者其他服务器执行。以下默认认为程序在当前目录。

注：拷贝到其他服务器执行时，如果服务器操作系统或其他软硬件环境有差异，则可能不能使用。

如果使用 Ubuntu 14.04 LTS ，则需要先编译安装 Boost 库，然后再执行上述步骤。
请注意，目前只支持 1.57.0 到 1.60.0 的 Boost 库。
编译安装 Boost 库的步骤为：

sudo apt-get install cmake make libbz2-dev libdb++-dev libdb-dev libssl-dev openssl libreadline-dev autoconf libtool git autotools-dev build-essential g++ libbz2-dev libicu-dev python-dev doxygen

wget -c 'http://sourceforge.net/projects/boost/files/boost/1.57.0/boost_1_57_0.tar.bz2/download' -O boost_1_57_0.tar.bz2
tar xjf boost_1_57_0.tar.bz2
cd boost_1_57_0
./bootstrap.sh
sudo ./b2 install

使用其他 Linux 发行版也可以编译，不在本文说明范围。


4. 环境准备

要保证系统正常运行，需要保证服务器系统时间正确。时间不正确会导致块链无法同步、资金发送失败等各种问题。

Ubuntu 系统推荐安装 NTP 服务端，方法是

sudo timedatectl set-ntp false
sudo apt-get install ntp

根据部署环境不同，可能需要修改默认的 ntp 服务器地址，请参阅相关文档。

如果是 Windows 系统，请设置好系统时间同步。


5. 同步数据

由于需要同时运行多个程序， Ubuntu 下推荐在 screen 或者 tmux 里启动程序。

以下描述主要针对 Ubuntu ，所以命令前都带 ./ 。对于 Windows ，在命令行界面 cd 到程序目录之后，执行时不需要 ./ 。


5.1 witness_node

可使用 ./witness_node --help 来查看命令参数。

5.1.1 初次执行：

./witness_node -d witness_node_data_dir

然后按 Ctrl+C 结束它。

这样会在当前目录生成一个数据目录 witness_node_data_dir ，里面包含 blockchain 目录是数据存储，以及一个 config.ini 配置文件。


对于交易所，推荐对 config.ini 配置文件作一些修改。

1) 可关闭 p2p 日志，以减小硬盘存储压力，方法是找到 filename=logs/p2p/p2p.log 行，在行首添加 # 号
或者将 [logger.p2p] 下面的 level=info 修改为 level=error

2) 可考虑将控制台日志同时保存到文件，方法是将下述章节

[logger.default]
level=info
appenders=stderr

修改为

[log.file_appender.default]
filename=logs/default/default.log

[logger.default]
level=info
appenders=stderr,default

这样之后， witness_node_data_dir/logs/default/ 目录下会同步保留最近24小时的控制台日志。

3) 以下参数会减少运行需要的内存，原理是不保存 BTS 内置交易引擎的历史成交记录索引，因为交易所一般用不到这个数据。

history-per-size = 0

如果是 2.0.171105a 及以后版本，则需要设置这个参数：

plugins = witness account_history

注：
* config.ini 里默认 plugins 前有个“#”符号，需要删除；
* 默认的 plugins 配置是 “witness account_history market_history”，这里实际是去掉“market_history”；
* 如果 config.ini 里没找到该配置项，比如从老版本升级上来时不会更新已有配置文件，
* 可以在 config.ini 最前面添加一行（不要加在文件最后面），
* 也可以另外找个空目录生成一个 config.ini 文件再拷过来修改。

4) 以下参数表示每账号保留多少条历史记录供查询，默认值是 1000 。
对交易所来说，如果充值、提现记录较多，可考虑设置成一个较大的值，比如

max-ops-per-account = 1000

修改为

max-ops-per-account = 1000000

则会保留一百万条数据。更早的数据会从内存中被删除而无法快速查询（但仍然记录在链上）。

5) 以下两个参数会大量减少运行需要的内存，原理是不保存与交易所账户无关的历史数据索引。

track-account = "1.2.12345"
partial-operations = true

请将 12345 替换成你的账户数字 ID 。数字前的 "1.2." 表示类型是账户。
注： config.ini 里默认 track-account 前面有个“#”符号，需要删除。

如果需要监控多个账户，则使用多个 track-account 配置，如：

track-account = "1.2.12345"
track-account = "1.2.12346"
partial-operations = true

注：
目前存在一个 BUG ，配置多个 track-account 会导致上面的日志修改不生效。
绕过这个问题的方法，是不动 config.ini ，而是启动 witness_node 的时候，在命令行后面添加 --track-account 参数，比如：

./witness_node --track-account "\"1.2.12345\"" --track-account "\"1.2.12346\""

注：
* 参数首尾双引号需要保留，所以使用 \ 进行转义。 Linux 下可以使用双引号外加一层单引号的方式，则不需要转义。
* 如果需要增加、修改、删除追踪账号，修改后，需要重建索引才能生效。
方法是按 Ctrl + C 结束程序，然后加 --replay-blockchain 参数重新启动，如：

./witness_node -d witness_node_data_dir --track-account "\"1.2.12345\"" --track-account "\"1.2.12346\"" --replay-blockchain


5.1.2 重新执行

再次启动 witness_node ，开始同步数据。根据网络条件、服务器硬件条件不同，初次同步可能需要花几个小时到几天时间。

./witness_node -d witness_node_data_dir --rpc-endpoint 127.0.0.1:8090 --track-account "\"1.2.12345\"" --track-account "\"1.2.12346\"" --partial-operations true --max-ops-per-account 1000000 --replay-blockchain

上述命令中，使用 --rpc-endpoint 开启节点 API 服务，这样就可以使用 cli_wallet 和其他程序连接使用

注：以后再需要重新启动 witness_node 时，一般不要加 --replay-blockchain 参数，否则启动会很慢


5.2 运行一个 cli_wallet 用于处理提现

./cli_wallet -w wallet_for_withdrawal.json -s ws://127.0.0.1:8090 -H 127.0.0.1:8091

上述命令使用 -w 参数指定钱包文件， -s 参数连接到 witness_node ， -H 参数开启钱包 API 服务，监听端口 8091

注：
可使用 ./cli_wallet --help 来查看命令参数。
cli_wallet 与 witness_node 间通信的数据不包含私密数据，一般不需加密，也不需要对节点 RPC 端口作刻意保护（加一层保护也未尝不可）。
但 cli_wallet 与充提程序间的通信是明文，可能需要包含密码，如果部署为多机架构，需要注意加密，可采用 SSH 隧道的方式。
并且， cli_wallet 处于解锁状态时，通过 RPC 端口可以转移钱包内账户资金，需要注意防止非授权访问，强烈不建议钱包 RPC 直接开放公网访问。
为 cli_wallet 的 RPC 配置证书或者密码的做法，本人没有研究过，故此不作描述。

执行成功会显示：

new >>>

首先需要为钱包文件设置一个密码

new >>> set_password my_password_1234

执行成功会显示：

locked >>>

然后解锁钱包

locked >>> unlock my_password_1234

解锁成功会显示：

unlocked >>>

使用 info 命令可以查看当前同步情况

unlocked >>> info
info
{
"head_block_num": 17249870,
"head_block_id": "0107364e2bf1c4ed1331ece4ad7824271e563fbb",
"head_block_age": "23 seconds old",
"next_maintenance_time": "31 minutes in the future",
"chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8",
"participation": "96.87500000000000000",
...
}

5.3 运行另一个 cli_wallet 用于处理充值

./cli_wallet -w wallet_for_deposit.json -s ws://127.0.0.1:8090 -H 127.0.0.1:8093

这个 cli_wallet 也开启钱包 API 服务，监听端口 8093

请参考前面的章节设置密码及解锁。


6. 账户设置

考虑到安全性，可以使用两个账号分别处理充值和提现，这里假设 deposit-account 用于充值，withdrawal-account 用于提现。

6.1 修改充值账户的备注密钥

在上述任何一个 cli_wallet 中执行 suggest_brain_key ，会得到一对密钥，示例如下：

unlocked >>> suggest_brain_key
suggest_brain_key
{
"brain_priv_key": ".....",
"wif_priv_key": "5JxyJx2KyDmAx5kpkMthWEpqGjzpwtGtEJigSMz5XE1AtrQaZXu",
"pub_key": "BTS69uKRvM8dAPn8En4SCi2nMTHKXt1rWrohFbwaPwv2rAbT3XFzf"
}

在轻钱包里，账户权限页面，将备注密钥修改为上述结果中的 pub_key

注：
1. 修改过后请注意备份轻钱包，否则轻钱包里可能无法解密修改前的备注。
2. 修改过后，如果仍需要使用轻钱包进行带备注的转账、或者读取新的转入/转出转账备注，
则需要将上述 wif_priv_key 导入到轻钱包，导入步骤参考如下教程中的第二步： http://btsabc.org/article-761-1.html 。
导入后可以做个新的备份。
3. 这个方法也可以用来修改账户的活跃权限密钥和账户权限密钥，有需要时可以使用。


6.2 将充值账户的备注密钥导入到连接到负责充值的 cli_wallet

如果钱包已锁定，需要先用 unlock 命令解锁。

这里需用到上述 suggest_brain_key 结果中的 wif_priv_key ：

unlocked >>> import_key deposit-account 5JxyJx2KyDmAx5kpkMthWEpqGjzpwtGtEJigSMz5XE1AtrQaZXu

导入时 cli_wallet 会自动生成一个或者两个备份文件，可删除。

这时可按 Ctrl + D 退出钱包，对钱包文件 wallet_for_deposit.json 进行备份，然后重新启动 cli_wallet 。

退出时会报个错，不用管它。

如果编译时没有引入 readline 库，则需要用 Ctrl + C 退出

由于没有导入活跃权限密钥，负责处理充值的 cli_wallet 无法动用充值账户的资金，只能查看历史记录。


6.3 从轻钱包中取得提现账户的活跃权限密钥

参考 http://btsabc.org/article-761-1.html />

6.4 将提现账户的活跃权限密钥导入到负责提现的 cli_wallet

unlocked >>> import_key withdrawal-account 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

同样可以对钱包文件作个备份。

注：检查一下提现账户的活跃权限密钥和备注密钥是否一样，如果不一样，则需要将备注密钥也导入，否则无法处理带备注的提现。导入命令仍然是：

unlocked >>> import_key withdrawal-account 5xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


7. 钱包命令

cli_wallet 里，
* 使用 help 命令可以列出命令清单及参数
* 如果编译时有 doxygen ，使用 gethelp 命令可以获取具体命令的参数说明及示例，如

unlocked >>> gethelp get_account


8. 钱包 API

钱包开启了 http rpc 方式的 API 服务时，可以通过 http rpc 方式调用**所有的**钱包命令，效果与在钱包里输入命令相同。

示例：

curl -d '{"jsonrpc": "2.0", "method": "get_block", "params": [1], "id": 1}' http://127.0.0.1:8093/rpc />
即：method 传入命令名，params 数组传入参数清单。

返回：

{"id":1,"result":{"previous":"0000000000000000000000000000000000000000","timestamp":"2015-10-13T14:12:24","witness":"1.6.8","transaction_merkle_root":"0000000000000000000000000000000000000000","extensions":[],"witness_signature":"1f53542bb60f1f7a653bac70d6b1613e73b9adc952031e30e591e601dd60d493ba5c9a832e155ff0c40ea1dd53512e9f93bf65a8191497ea67d701bc2502f93af7","transactions":[],"block_id":"00000001b656820f72f6b28cda811778632d4998","signing_key":"BTS6ZQEFsPmG6jWspNDdZHkehNmPpG7gkSHkphmRZQWaJ2LrcaVSi","transaction_ids":[]}}

如果执行成功，结果会有 result ，否则会有 error 。


注意：
HTTP RPC 请求 URI 为 /rpc 。
在钱包里输入命令，返回结果是经过美化的；使用 http rpc 请求时，返回的是 json 格式的原始数据。关于原始数据，需要注意的有：
* 金额是 {"amount":467116432,"asset_id":"1.3.0"} 格式，其中
* asset_id 可以通过 get_asset 命令查到具体名称， BTS 的 asset_id 是 1.3.0 ，其他资产有其他 id
* amount 是数量去掉小数点之后的值，比如 BTS 是 5 位小数，上面例子中实际是 4671.16432 BTS
* 账户是 1.2.xxxxx 的格式，可以通过 get_account 获取账户信息
* 操作类型（op）是数值格式，比如 0 表示转账操作


9. 处理充值

9.1 获取当前的“无法回退区块”块号

与比特币等采用确认数来从概率上降低交易回退的可能性有所不同， BTS 里可采用“无法回退区块”块号来判断交易是否可能回退。
“无法回退”区块及更早区块里面的交易，可以保证不会发生回退。

在 cli_wallet 里使用命令 get_dynamic_global_properties 来获取无法回退的块号。如：

get_dynamic_global_properties
{
"id": "2.1.0",
"head_block_number": 21955727,
...
"last_irreversible_block_num": 21955709
}

其中， head_block_number 为最新区块号， last_irreversible_block_num 为无法回退区块号。

9.2 查询充值账户历史

使用 get_relative_account_history 命令来查询充值账户历史，检测是否有新的充值。如：

unlocked >>> get_relative_account_history deposit-account 1 100 100

unlocked >>> get_relative_account_history deposit-account 101 100 200

curl -d '{"jsonrpc": "2.0", "method": "get_relative_account_history", "params": ["deposit-account",1,100,100], "id": 1}' http://127.0.0.1:8093/rpc />

四个参数分别为：账户名，最小编号，最大返回数量，最大编号。编号从 1 开始。

注：
某个版本的 cli_wallet 最大返回数量超过 100 时有个bug，导致结果不准，使用时请避免 limit 超过 100 。

返回结果是一个数组，按时间倒序排序，即最新的记录排在最前面。
* 如果没有新充值，则数组长度为 0 。
* 如果有新的记录，其中第N条数据为 result[N]，格式可能为：

{
"memo":"",
"description":"Transfer 1 BTS from a to b -- Unlock wallet to see memo. (Fee: 0.22941 BTS)",
"op":{
"id":"1.11.1234567",
"op":[
0,
{
"fee":{
"amount":22941,
"asset_id":"1.3.0"
},
"from":"1.2.12345",
"to":"1.2.45678",
"amount":{
"amount":100000,
"asset_id":"1.3.0"
},
"memo":{
"from":"BTS7NLcZJzqq3mvKfcqoN52ainajDckyMp5SYRgzicfbHD6u587ib",
"to":"BTS7SakKqZ8HamkTr7FdPn9qYxYmtSh2QzFNn49CiFAkdFAvQVMg6",
"nonce":"5333758904325274680",
"message":"0b809fa8169453422343434366514a153981ea"
},
"extensions":[
]
}
],
"result":[
0,
{
}
],
"block_num":1234567,
"trx_in_block":7,
"op_in_trx":0,
"virtual_op":1234
}
}

可见，结果中并没有显式包含每条记录的编号，需要程序自行推算、记录。一般将该数组顺序颠倒，然后逐一处理比较合适。

首先要判断该交易所在区块是否已经无法回退。
取 result[N]["op"]["block_num"] 与 last_irreversible_block_num 作比较，如果可以不可回退则继续处理，可以回退则先跳过不处理。
注意：交易没有进块时，仍然可能在 get_relative_account_history 中出现，并且所在块号会一直改变，难以判断状态。
所以请使用 last_irreversible_block_num 来判断。

result[N]["op"]["op"] 是数组格式，取数组里第一个元素 result[N]["op"]["op"][0] ，如果是 0 ，则表示转账；
则可以取第二个元素中 "to" 字段，即 result[N]["op"]["op"][1]["to"] ，判断它是否与 deposit-account 的 ID 相同，来判断是否转入；
如果是，则取第二个字段中 "amount" 字段里 "asset_id" 字段 result[N]["op"]["op"][1]["amount"]["asset_id"] 判断是否正确资产类型，
然后取 "amount" 里面的 "amount" ，即 result[N]["op"]["op"][1]["amount"]["amount"] ，加上小数点位数，得出充值金额；
取最外层的 "memo" 字段，即 result[N]["memo"] ，得出用户在交易所的 ID ，进行入账。
result[N]["op"]["id"] 是这笔转账的唯一 ID ，可以记录备查。

同时，推荐将结果中 block_num, trx_in_block, op_in_trx 几个数据也记录下来，含义分别是 块号、块中第几个交易、交易中第几个操作。

另外，由于他方转账时，可能只记录交易ID （哈希值），或者交易签名，而不记录操作ID或者块号，
为了方便检查问题，建议在充值检测时，记录操作对应的交易 ID 和交易签名，方法如下：

根据上述 block_num ，调用 get_block 命令获取块内容，如

unlocked >>> get_block 16000000

curl -d '{"jsonrpc": "2.0", "method": "get_block", "params": [160000], "id": 1}' http://127.0.0.1:8093/rpc />
设结果中块内容为 result ，根据上述 trx_in_block ，
取 result["transaction_ids"][trx_in_block] ，即为对应的交易 ID；
取 result["transactions"][trx_in_block]["signatures"] ，即为交易签名，是个数组，因为多重签名账户转账可能包含多个签名

注：
1) 钱包必须先解锁才能解密备注。
2) 如果检测到有充值的备注不正确，或者资产类型不正确，注意不要简单退回，因为可能是从其他交易所转来的，退回后对方处理起来也会很麻烦。
3) 一个块里很可能有多笔充值，结果的 block_num 相同，甚至可能 trx_in_block 和 op_in_trx 也相同，但 virtual_op 不同，需注意处理。
可以肯定 blocknum + trx_in_block + op_in_trx + vitrual_op 的组合是唯一的。
这里还要注意个问题， virtual_op 的数据目前有个 BUG，如果不是每次重启参数都一样并且都 replay ，重新查历史数据，会发现这个值会不一致
4) 由于存在“提议”功能，可以延期执行，用 get_block 然后用 trx_in_block 定位时可能取不到对应交易，或者取到的交易与充值操作不对应。
延期执行功能目前很少有人用，但理论上存在，请注意错误处理。


10. 处理提现

10.1 网络状态检查

为了安全起见，只有当 witness_node 网络正常时，才处理提现。

在负责提现的 cli_wallet 中使用 info 命令检查网络状态。

unlocked >>> info
info
{
"head_block_num": 17249870,
"head_block_id": "0107364e2bf1c4ed1331ece4ad7824271e563fbb",
"head_block_age": "23 seconds old",
"next_maintenance_time": "31 minutes in the future",
"chain_id": "4018d7844c78f6a6c41c6a552b898022310fc5dec06da467ee7905a8dad512c8",
"participation": "96.87500000000000000",
...
}

需检查的字段有：
* head_block_age 最好是在 1 分钟以内
* participation 最好在 80 以上，表示 witness_node 所连网络有 80% 的出块节点正常工作

另外，网络正常时， last_irreversible_block_num 与 head_block_num 之间的差值不会太大（一般 30 以内）；
这个可以作为参考。


10.2 提现账户余额检查

使用 list_account_balances 命令检查提现账户余额是否足够（注意资产类型、并且算上手续费）

unlocked >>> list_account_balances withdrawal-account

注：
1) 注意资产类型
2) 注意加上手续费。因为备注是按长度收费，所以带备注时手续费会比不带备注时高一些。


10.3 提现目的账号名检查

使用 get_account_id 命令可以检查客户输入的提现目的账号是否有效

locked >>> get_account_id test-123
get_account_id test-123
"1.2.96698"

locked >>> get_account_id test-124
get_account_id test-124
10 assert_exception: Assert Exception
rec && rec->name == account_name_or_id:
{}
th_a wallet.cpp:597 get_account


10.4 发送提现

使用 transfer2 命令发送提现交易。如：

unlocked >>> transfer2 withdrawal-account to-account 100 BTS "some memo"

参数分别是：源账户名，目的账户名，金额，币种，备注

该命令会签名并广播交易，然后返回一个数组，第一个元素是交易 id ，第二个元素是详细交易内容

注：
1) 如果币种是 BTS ，金额小数位数最多 5 位。如果是其他资产，通过 get_asset 命令可以查看资产的小数位数，"precision"字段。
2) 也可以使用 transfer 命令，但是这样不会直接返回交易 ID ，而是需要调用其他 API 来计算出来，所以不推荐。
3) 备注通常用 UTF-8 编码
4) 建议记录相关数据备查，比如交易 id 、 json 格式的详细交易内容等


10.5 提现结果检查

使用 get_relative_account_history 命令获取 withdrawal-account 的提现历史，参照充值处理章节，如果发现有新的记录，
并且交易所在块号早于 last_irreversible_block_num ，则表示交易已经进块并且不可回退；

注意：交易没有进块时，仍然可能在 get_relative_account_history 中出现，并且所在块号会一直改变，难以判断状态。
所以请使用 last_irreversible_block_num 来判断。

根据该条记录的 block_num 字段，使用 get_block 命令查询详情

unlocked >>> get_block 12345

返回结果中， transaction_ids 字段数据里应该包含前面的交易 id 。

建议记录上述 get_relative_account_history 结果中的 id (1.11.x), block_num, trx_in_block 备查。


10.6 关于失败重发

在有些情况下可能交易发送后，没有及时被打包进入区块。

与比特币不同， BTS 的交易里面有个超时时间字段（expiration），
使用 cli_wallet 签名广播交易时，该字段值默认是本机系统时间加 2 分钟。
本机交易特别多的时候，超时时间会加长。

如果在网络时间到达该超时时间之后，交易仍然没有被打包进块，则该交易会被所有网络节点丢弃，不再有可能被打包。

因此，如果出现交易广播了但没有在账户历史中出现，先检查本机系统时间是否滞后。

* 如果 last_irreversible_block_num 对应的块时间已经过了交易的超时时间，那么重发是安全的。
* 如果交易已经在历史中出现，则检查交易所在块号是否已经固定，而不是一直随着最新块号更新
* 如果交易所在块号一直更新，表示交易还没被打包进块，需继续耐心等待被打包或超时
* 如果块号已固定，随着时间推移，网络正常时， last_irreversible_block_num 很快就会超过该块号
* 如果 head_block_num 一直增长，而 last_irreversible_block_num 不增长，
则很可能 witness_node 进入了一个较短分叉链，或者网络出现问题，导致交易无法完全确认。
这种情况下，请检查 witness_node 是否有新版本需要升级，或联系开发团队
* 如果重发仍然无法被打包，则可能遇到网络异常或者拥堵，这种情况比较少见，请联系开发团队


11. 其他

* cli_wallet 有个参数 --daemon ，使用此参数启动后，会在后台运行

* 需要关闭 witness_node 时，按一次 Ctrl C，然后等待程序自己退出。
* 正常退出后，重新启动时，不需重建索引，启动会比较快
* 正常退出后，可以对数据目录 witness_node_data_dir 打包备份，需要时可直接恢复使用
* 如果异常退出，则重新启动时，很可能需要重建索引，启动比较慢

* 如果 witness_node 出现异常，一般先尝试重启，如果不行则可尝试带 --replay-blockchain 参数重启，即手工触发重建索引
* 如果没有解决，则使用备份恢复
* 如果没有备份，则重新同步，可能耗时较长

* 多重签名： BTS 原生支持账户级多重签名，并且有提案-批准的机制，可以在线发起多签请求，然后确认完成多签交易，具体参考相关教程

* 硬件钱包： 暂无支持

* 冷存储： 可以实现，步骤有些复杂，示例：
* 在离线机器，启动 witness_node 及 cli_wallet ，使用 suggest_brain_key 命令离线生成密钥对；
* 然后用轻钱包将账户密钥修改为上述密钥，则账户进入冷存状态
* 需要动用冷存账户时，
* 可以用暂时变热的方式，即将私钥导入轻钱包使用，用完后再换成新密钥
* 纯冷模式也可实现，但当前 cli_wallet 支持不好，有需要的请单独联系


12. 相关资料

* 图文教程 http://jc.btsabc.org/ /> * 自建节点教程 http://btsabc.org/article-477-1.html /> * 获取账户私钥 http://btsabc.org/article-761-1.html />* 英文对接文档 http://docs.bitshares.org/integration/exchanges/step-by-step.html />* 英文 API 文档 http://docs.bitshares.org/api/index.html

【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« on: April 16, 2018, 07:59:16 am »
这贴是开头，先说一下原则。

大家知道，债仓的最低抵押率和爆仓惩罚比例是由喂价人指定。对于 CNY 等理事会资产来说，是由见证人指定。

从机制上来说，见证人负责调整这两个参数。为了系统更好运行，比如为了更好的锚定，见证人【应该】适时调整参数。

目前所有见证人都使用固定抵押率 175% 和爆仓惩罚 110% ，一方面是历史原因，是 BM 拍脑袋想出的初始数据；一方面是实验性质，看看固定参数是否能达到理想效果；甚至说得难听一点，也可能是大部分见证人比较懒、不作为、没有去优化。

现在，经过两年多运行验证，从结果来看， CNY 锚定效果不甚理想，所以有理由推测，认为固定参数可能也是原因之一。也有不少人提出了各种修改参数的方法，虽然还没有最终结论。当然，去中心化本身就是百家共鸣，不一定有最优方案。

【但是】，很少见到见证人出来讨论这个问题，更别说优化方案。从 DPoS 本身来说，【持票人】有义务推动见证人进行参数优化：不作为的见证人应该下调绩效考核分数、甚至下岗。

1. 应该鼓励、甚至要求见证人进行参数调整方面的努力，并积极实施，不能仅限于讨论。

2. 有编码能力的见证人，自己修改喂价脚本，进行实验；没有编码能力的，积极探索，如何使用他人脚本，以及提供思路和修改方案。

3. 可以小步走。一开始调整小一点，慢慢增加。

4. 去中心化，不一定大家都使用同样的调整算法，最好有几套算法，至少是多种实现。因为参数和价格一样，最终取的是所有见证人的中间值（不是平均值）。使用多种脚本会降低同时出错几率。

【待续】
Logged
BTS account: abit
BTS committee member: abit
BTS witness: in.abit
Offline abit
Committee member
Hero Member
*

Posts: 3081
View Profile Steemit Blog
BitShares: abit
GitHub: abitmore

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #1 on: April 16, 2018, 10:19:21 am »
调整抵押率和爆仓参数，无外乎下面几个思路。

1. 自由派：不调参数。主要目的是给市场参与者一个简单规则，由市场决定 bitCNY 价格，参与者自担风险。

参与者包括 bitCNY 制造者和 bitCNY 持有者。风险包括爆仓和持有物贬值，也包括黑天鹅。

结果：就像现在这样。
* BTS 高价时 bitCNY 价格低于法币，供应表现为充足
* BTS 低价但没有黑天鹅时 bitCNY 价格高于法币，供应表现为短缺
* 黑天鹅还没发生过，所以不好说


2. 激进派：主要目的是增加 bitCNY 供应

采取方案为：低抵押率，低爆仓惩罚。

结果：？

个人推测：
* 抵押风险低，所以玩家大量抵押，bitCNY 供应量大， BTS 低价时 bitCNY 溢价不高
* BTS 高价时 bitCNY 贬值会比较明显
* 低惩罚，会导致没人吃爆仓单；同时低抵押率，价格有波动时很可能导致高价就出现黑天鹅


3. 保守派：主要目的是避免黑天鹅事件，其他情况下的一定的价格偏离可以接受。

采取方案为：高抵押率，高爆仓惩罚。

结果：？

个人推测：
* 抵押率要求高，且一旦爆仓即损失惨重，所以抵押意愿较低，会导致 bitCNY 供应量较低、会有较高溢价。
* 对黑天鹅抗性极强


4. 平衡派：各种调参数，主要目的是使 bitCNY 价值尽量稳定。

4.1 BTS 高价时，理论上可抵押出的 bitCNY 数量变多，导致 bitCNY 价值低于法币，所以需要平抑抵押借款冲动，采取方案为：增加最低抵押率要求，增加爆仓惩罚。

4.2 BTS 低价时，理论上可抵押出的 bitCNY 数量变少，导致 bitCNY 价值高于法币，所以需要刺激抵押借款冲动，可采取方案为：降低最低抵押率，减少爆仓惩罚。

* 一定程度上，低抵押率和爆仓惩罚，更容易导致黑天鹅事件，结果是更严重的价值脱锚。

4.3 为了尽量避免出现黑天鹅现象，BTS 低价时，不鼓励抵押，可采取方案为：增加最低抵押率，增加爆仓惩罚。

* 这个方案与 4.2 有矛盾，需要找个平衡点

* 供不应求（主要需求是还款平仓），会导致 bitCNY 价值偏高，一定程度脱锚。

可能存在不可能三角，需要仔细分析一下。


5. 稳健派

* 高抵押率，低爆仓惩罚

个人推测：
- 因为高抵押率， bitCNY 供应量应该不会特别多，可能有所溢价；但低惩罚也会起到鼓励抵押的作用。
- 因为低爆仓惩罚，所以市场上有爆仓单没人吃会是常态，这样也一定程度会降低实际抵押率；
- 爆仓到黑天鹅空间很大，没出现黑天鹅时， bitCNY 价值波动较小
- 没人吃爆仓单，对黑天鹅抗性较低
- 高抵押率要求，导致出现黑天鹅后难以复活


6. 放任派

* 低抵押率，高爆仓惩罚

个人推测： bitCNY 总是在黑天鹅状态，或者在接近黑天鹅的状态。 bitCNY 价格接近于自由浮动。供应量不好说。

因为黑天鹅可以复活，临界点低所以复活成本低，所以，可能一般价格波动时出现黑天鹅也不是很要紧；但长期熊市时复活难度大。
Logged
BTS account: abit
BTS committee member: abit
BTS witness: in.abit
Online binggo
Full Member
***
Posts: 112
View Profile

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #2 on: April 16, 2018, 12:52:09 pm »
抛开整体谈局部有些片面，需要多方面考虑。
有几个参数是需要相对固定化的，不然就会缺乏根基，我认为像最低抵押率，爆仓抵押率，爆仓惩罚，强制清算补偿（如果能改为动态的话就可以去除），清算时间，清算量这些系统根基参数，还是相对固定一些的好，由理事会或见证人提出议案投票决定。。

现有的几个要素：
抵押BTS：从系统借出bitcny 维持最低抵押率
强制平仓：被系统强制卖出bts偿还BITCNY，BICNY被回收至系统 爆仓抵押率 、爆仓惩罚、爆仓机制
强制清算：用bitcny清算抵押者的债仓，BITCNY被回收至系统一部分 强制清算补偿、清算时间、清算量
喂价：见证人从外部交易所采价 喂价机制
黑天鹅处理：全局清算

1. 维持最低抵押率 现在是175%

这个参数现在看来可能并不是一个相对合理的参数，调整至180%或185%是可以来看看效果的，我建议增加这么一项，bts钱包里是可以调整这一项的，应当将维持最低抵押率与爆仓抵押率两者分开，而不是一体。
为什么要提高这个参数，因为现在有相当多的抵押是顶格抵押，喂价有点波动就会爆仓，相当一部分的bitcny就直接被系统回收了，负反馈大于正反馈，提高一下抗波动系数是没有错的。

2. 爆仓机制 现在是爆仓抵押率到175%爆仓，爆仓惩罚10%
175%爆仓抵押率暂时看也不需要调整。

爆仓机制现在已经修改了，按需爆仓是可以的。

爆仓惩罚：10%对市场深度覆盖太大，可以适度调整至5%或更少（但是这需要将维持最低抵押率调整至180%或185%，或者不调整看看具体效果如何），从前段时间 的实际情况来看，最低抵押率到了130%，内盘价格与喂价至少相差18%，所以并不是爆仓单惩罚百分之多少的问题，而是爆仓惩罚的百分比越多，对市场深度的覆盖就越严重，与外部喂价偏离的就越多，形成的负反馈就越严重，导致黑天鹅就越快，而这些爆仓单被吃掉的很大一部分原因是市场反弹吃掉的，市场买单深度是可以的，降低惩罚可以一定程度上降低bitcny入金手续费。5%的利润在反弹的时候也会抢着来吃，情绪不好就是调成20%，30%照样是没人吃。

银行抵押借款是要收利息的，BTS抵押借款可以不收利息，但是爆仓的时候，系统必须要收取一定利息来预防系统性风险。

建议：修改爆仓惩罚机制，将爆仓惩罚调整至5%或更低，同时追加至少5%的惩罚系数，即爆仓后扣除剩余bts的5%归入公开市场操作资金。

3. 黑天鹅的处理方式：
现在黑天鹅的处理方式我认为不是太合理，资不抵债的债仓作为系统临时债仓处理即可，没有必要把整个抵押来做全局清算，因为还有很多是足额抵押的债仓（哪怕是外部交易所最低的价格来计算），这样救市者救市所需要花费的成本与黑天鹅复活的难度都不会太高，但是一旦做全局清算，救市者需要花费巨大的成本来处理全局抵押单，而且此时还不能进行抵押，另外沉睡的锚定资产有相当多的数量是不会来参与处理黑天鹅的，这样黑天鹅复活的难度会指数型上升，只能指望与外盘来救，而内盘却在进行严重的负反馈，并且死水一潭。

我们总不能因为10%的抵押出现资不抵债，就把剩下的90%资可抵债的抵押也拉上做黑天鹅处理。

所以建议：资不抵债的债仓在总抵押中占不到40%（或适当百分比），不进行全局清算，资不抵债的债仓作为系统临时债仓(这些债仓可以交由公开市场操作资金或者市场来处理)，而且抵押可以正常进行，当资不抵债的总债仓超过抵押总债仓的40%（或适当百分比）时进行全局清算，执行现有的黑天鹅处理方式。市场操作资金存留部分用于债仓操作（但公开市场操作资金不宜分散与过多的锚定资产）

而且从市场自由派这段时间的发生的各种爆仓及临近黑天鹅的情况来看，只要适当的时候将一部分就要到110%的债仓吃掉，就可以很大程度上缓解黑天鹅的发生，甚至能杜绝黑天鹅的发生。市场操作资金可以存留一部分用来预防黑天鹅事件，

4. 强制清算补偿 现在是5%，清算时间24H, 清算量0.5%
建议强制清算补偿可以采用线性参数，抵押率越高补偿越高，抵押率越低补偿越低，这样可以保护高抵押率的抵押者，防止恶意清算一清到底，也可以遏制顶格抵押者，就没有必要天天为了要把强清补偿调到多少费口舌与精力。

清算时间可以改为12或6h，（对于处于爆仓状态的清算立即执行）， 清算量增加到1%或2%。

5. 喂价：喂价直接影响强制平仓与强制清算，而强制平仓对内盘价格影响相当大，强制清算次之。
现在最大的问题就出在喂价机制上，见证人的喂价脚本个个不一，刷新时间也不一样，存在过高与过低喂价的情况，甚至有时候相差高达10%，内盘很多时候的恶意行为往往来源于喂价机制的缺陷，但是现在除了督促见证人采用合理的喂价之外好像没有更好的办法。

我有一个建议：采用内盘价格与外盘喂价比较法，哪一个高就采用哪一个作为最终喂价，毕竟内盘BTS的流通量并不少于现在的任何交易所，这样可以避免内外盘定价（btc定价与其它定价物）的问题，避免内盘价格被喂价挟持，一定程度上消除喂价在内盘产生的负面影响，同时也可以避免直接采用内盘作为喂价的缺陷（毕竟内盘爆仓程度里厉害时，会导致内盘价格过低）。
鉴于喂价影响强清, 建议将MCR改为180%。

不合理的参数及机制必须要改，而且要尽快改动，结果再坏也不会比前段时间更坏，而不改只会导致将来的后果更糟，没有一条法律是尽善尽美的，一个金融系统的机制也是一样，发现问题及时反馈进化才是最应该做的，墨守陈规，遵循前制，尚以为是完美，只会慢慢被淘汰，见证人及大多数理事的消极态度也是不应该的，我想很多理事及见证人是早早就知道缺陷的，不知道长达2年多的时间为什么还是这样？！

港元都有被做空打崩的时候，所以锚定资产出现黑天鹅是不可避免的，而且也不会有根本的解决办法，能够减轻黑天鹅程度就是成功，并且锚定资产只要在能接受的合理范围内波动，就不算偏锚，毕竟完全1：1锚定是不会存在的。
« Last Edit: May 16, 2018, 02:00:47 pm by binggo »
Logged
Online binggo
Full Member
***
Posts: 112
View Profile

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #3 on: April 16, 2018, 01:44:05 pm »
主要看一下第1点与第4点：

Quote from: abit on April 16, 2018, 10:19:21 am
1. 自由派：不调参数。主要目的是给市场参与者一个简单规则，由市场决定 bitCNY 价格，参与者自担风险。

参与者包括 bitCNY 制造者和 bitCNY 持有者。风险包括爆仓和持有物贬值，也包括黑天鹅。

结果：就像现在这样。
* BTS 高价时 bitCNY 价格低于法币，供应表现为充足
* BTS 低价但没有黑天鹅时 bitCNY 价格高于法币，供应表现为短缺
* 黑天鹅还没发生过，所以不好说
从去年12月份爆到现在的情况来看，内盘挺过了数不清的连环爆仓与临近黑天鹅事件，其中巨蟹先生在其挽救内盘局势中起了至关重要的作用，从这方面来看，市场自由派是不可行的，因为万一临近黑天鹅的时候没人兜底，一切都会付之东流。

Quote from: abit on April 16, 2018, 10:19:21 am
4. 平衡派：各种调参数，主要目的是使 bitCNY 价值尽量稳定。

4.1 BTS 高价时，理论上可抵押出的 bitCNY 数量变多，导致 bitCNY 价值低于法币，所以需要平抑抵押借款冲动，采取方案为：增加最低抵押率要求，增加爆仓惩罚。

4.2 BTS 低价时，理论上可抵押出的 bitCNY 数量变少，导致 bitCNY 价值高于法币，所以需要刺激抵押借款冲动，可采取方案为：降低最低抵押率，减少爆仓惩罚。

* 一定程度上，低抵押率和爆仓惩罚，更容易导致黑天鹅事件，结果是更严重的价值脱锚。

4.3 为了尽量避免出现黑天鹅现象，BTS 低价时，不鼓励抵押，可采取方案为：增加最低抵押率，增加爆仓惩罚。

* 这个方案与 4.2 有矛盾，需要找个平衡点

* 供不应求（主要需求是还款平仓），会导致 bitCNY 价值偏高，一定程度脱锚。

可能存在不可能三角，需要仔细分析一下。

第四条存在的操作性最大，一定程度的脱锚是可以接受的，毕竟没有完全有1：1锚定的存在，而其操作并不仅局限于调整最低抵押率与爆仓惩罚，强制清算与市场公开操作资金平抑的都是可以进行操作的。

4.1 提高最低抵押率，加大爆仓惩罚。
其中就有个问题，加大爆仓惩罚，是爆仓惩罚加大至15%直接覆盖市场买单，还是爆仓惩罚10%后对剩余的bts进行惩罚性回收？

4.2 不讨论，这不是一个理性的方案。

4.3 提高最低抵押率，加大爆仓惩罚。
恩，这一条好像又回到了4.1，为什么不是 提高最低抵押率，减少爆仓惩罚？

抵押我们是一直鼓励的，尤其是鼓励高抵押率抵押，这些位于金字塔中底部的才是BITCNY产出的主力，也是在大跌时能够在市场起作用的抵押，而那些顶格抵押，低抵押率的抵押很大程度上在爆仓砸内盘的同时，又被回收到系统了。

这样看来，好像是 提高最低抵押率，调整爆仓惩罚是一个可行方案，但是提高最低抵押率到什么程度，爆仓惩罚如何调整及实施是需要讨论的问题。

提高最低抵押率我们可以一点一点的提高来看看效果，但是爆仓抵押率是不是要等于最低抵押率，还是保持175%不变？

降低爆仓惩罚倒是好说，一点一点的减少来看看效果。

加大爆仓惩罚是直接简单粗暴的调整为15%或更高？还是维持现在10%的爆仓惩罚，然后对爆仓后的剩余的bts进行百分比惩罚性回收？在按需爆仓的情况下如何来判断惩罚回收多少bts？
« Last Edit: April 16, 2018, 03:00:46 pm by binggo »
Logged
Offline bitcrab
Committee member
Hero Member
*

Posts: 680
View Profile
BitShares: bitcrab
GitHub: bitcrab

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #4 on: April 16, 2018, 02:20:34 pm »
锚定不成功主要表现为bitCNY的短缺和过剩，其实感觉跟这些参数关系不大，原因在于bitCNY的市场需求和BTS价格没有直接的决定关系，需求无法有效传导给供应。

BSIP38等改动意义很大，可以很有效地降低出现黑天鹅的风险，但对于调节bitCNY供给来说，个人认为还是要靠公开市场操作这样的方式。

这两个参数虽然是BM拍脑袋得出，但个人觉得还算比较合理，不象当初40BTS的转账费用，以及0清算补偿那样明显不合理。

如果改怎么改呢？比如现在的价格下，把1.75改为1.5？虽然增加了供应量，但也增大了黑天鹅的风险吧？不一定是个好主意。
Logged
Email：bitcrab@qq.com
Online binggo
Full Member
***
Posts: 112
View Profile

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #5 on: April 16, 2018, 02:47:32 pm »
Quote from: bitcrab on April 16, 2018, 02:20:34 pm
锚定不成功主要表现为bitCNY的短缺和过剩，其实感觉跟这些参数关系不大，原因在于bitCNY的市场需求和BTS价格没有直接的决定关系，需求无法有效传导给供应。

BSIP38等改动意义很大，可以很有效地降低出现黑天鹅的风险，但对于调节bitCNY供给来说，个人认为还是要靠公开市场操作这样的方式。

这两个参数虽然是BM拍脑袋得出，但个人觉得还算比较合理，不象当初40BTS的转账费用，以及0清算补偿那样明显不合理。

如果改怎么改呢？比如现在的价格下，把1.75改为1.5？虽然增加了供应量，但也增大了黑天鹅的风险吧？不一定是个好主意。

从去年到现在来看，锚定还是可以的，毕竟巨蟹先生你还是把一些风险扛住了，再说波动是常态，像港元，人民币的汇率这些年不也变动很大，只要能为在合理的范围内波动是可以接受的，只是因为被btc挟持之下，任何锚定都会偏。

bitcny的是市场需求其实跟bts的价格没有太大关系，或者关联性不是太强，但是其供应量却是取决于bts的价格。
公开市场操作是可以慢慢增加bitcny的供应量，可能需要的时间要比较长吧。
根据实际情况修正一些参数也是必要的，不能让前期辛辛苦苦做的一些努力白费，毕竟现在的爆仓机制对高抵押率者来说并不是太合理，大家的抵押率如果都能够维持在公开市场操作基金的附近，bts的价格再坐几次过山车，我想内盘情况比现在要好的多吧，入金率至少能够保证波动不是太大。

调低抵押率不可行哦，调高倒是可以，毕竟理性的bitcny产出者不会贴着爆仓线抵押吧？
Logged
Offline ripplexiaoshan
Moderator
Hero Member
*****

Posts: 2140
View Profile
BitShares: xiaoshan

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #6 on: April 19, 2018, 05:20:22 pm »
很好的讨论。

关于参数哪个好我不想评论， 因为我也没有十足的把握自己的观点正确。这些东西确实跟 @abit 说的一样，需要各位见证人参与进来多多讨论才行。

见证人作为独立于理事会的一股强大势力，本来是应该非常有存在感的，因为见证人可以决定系统的很多重要参数的，但现在看来愿意讨论以及研究这些的见证人并不多。

我想主要有两个原因：
一是见证人多是程序员，认为自己只要稳定出块就好了，而且因为BTS系统本质是个金融系统，一般的程序员要深刻理解这些参数对系统运转的影响并不容易，所以干脆偷懒用统一的脚本参数，不求最好，但求不出错。

二是见证人是获利集团，比较依赖大家的投票，目前见证人队伍相对稳定，公开发表太多激烈的讨论和想法，反而会担心让反对者撤票，所以没有动力来为这些事操心，不如闷声发财。

由于上面两点，再加上普通持仓用户投票的惰性，坦白地讲，很多见证人当选之前非常活跃，一旦当选，由于一般也不会被撤票，所以持续为社区做贡献的动力很低。

针对这两点，我认为是有解决办法的。人性的弱点不能依靠呼吁和号召，只能依靠制度。

解决办法其实不新鲜，我之前也在不同的场合建议过，主要有两点：

1、虽然不方便撤票，但是可以增加见证人数量，补充新鲜血液，让更多有志之士参与进来。这一点最近已经有所提现，从19个增加到了25个。系统总支出不变，但是留住了更多的人。

2、最终极的解决办法，就是调动见证人的积极性，禁止一劳永逸。 把投票加一个衰减因子，让见证人持续拉票，或者让社区投票者被迫不定期审视见证人的工作以及贡献。 这样我想能发挥见证人这个群体更大的潜力。

Logged
BTS committee member:jademont
Offline akmax2017
Newbie
*
Posts: 11
View Profile
BitShares: akmax2017

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #7 on: April 20, 2018, 03:26:38 am »
Quote from: bitcrab on April 16, 2018, 02:20:34 pm
锚定不成功主要表现为bitCNY的短缺和过剩，其实感觉跟这些参数关系不大，原因在于bitCNY的市场需求和BTS价格没有直接的决定关系，需求无法有效传导给供应。

BSIP38等改动意义很大，可以很有效地降低出现黑天鹅的风险，但对于调节bitCNY供给来说，个人认为还是要靠公开市场操作这样的方式。

这两个参数虽然是BM拍脑袋得出，但个人觉得还算比较合理，不象当初40BTS的转账费用，以及0清算补偿那样明显不合理。

如果改怎么改呢？比如现在的价格下，把1.75改为1.5？虽然增加了供应量，但也增大了黑天鹅的风险吧？不一定是个好主意。

有没有办法让BTS的价格 跟 bitcny需求挂钩， bitcny严重短缺的时候逼着BTS涨价，
Logged
Online binggo
Full Member
***
Posts: 112
View Profile

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #8 on: April 20, 2018, 08:05:09 am »
Quote from: akmax2017 on April 20, 2018, 03:26:38 am
Quote from: bitcrab on April 16, 2018, 02:20:34 pm
锚定不成功主要表现为bitCNY的短缺和过剩，其实感觉跟这些参数关系不大，原因在于bitCNY的市场需求和BTS价格没有直接的决定关系，需求无法有效传导给供应。

BSIP38等改动意义很大，可以很有效地降低出现黑天鹅的风险，但对于调节bitCNY供给来说，个人认为还是要靠公开市场操作这样的方式。

这两个参数虽然是BM拍脑袋得出，但个人觉得还算比较合理，不象当初40BTS的转账费用，以及0清算补偿那样明显不合理。

如果改怎么改呢？比如现在的价格下，把1.75改为1.5？虽然增加了供应量，但也增大了黑天鹅的风险吧？不一定是个好主意。

有没有办法让BTS的价格 跟 bitcny需求挂钩， bitcny严重短缺的时候逼着BTS涨价，

那可能需要在BTS内盘设计一个以bts及bitcny为保证金的期货系统，最大杠杆率按照反复抵押的最大值 2.3倍，给抵押者一个对冲套保的机制，不是在大跌时，被动挨宰，我感觉可行...
可以多空双开。
« Last Edit: April 20, 2018, 11:31:36 pm by binggo »
Logged
Online binggo
Full Member
***
Posts: 112
View Profile

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #9 on: April 22, 2018, 08:52:05 am »
Quote from: bitcrab on April 16, 2018, 02:20:34 pm
锚定不成功主要表现为bitCNY的短缺和过剩，其实感觉跟这些参数关系不大，原因在于bitCNY的市场需求和BTS价格没有直接的决定关系，需求无法有效传导给供应。

BSIP38等改动意义很大，可以很有效地降低出现黑天鹅的风险，但对于调节bitCNY供给来说，个人认为还是要靠公开市场操作这样的方式。

这两个参数虽然是BM拍脑袋得出，但个人觉得还算比较合理，不象当初40BTS的转账费用，以及0清算补偿那样明显不合理。

如果改怎么改呢？比如现在的价格下，把1.75改为1.5？虽然增加了供应量，但也增大了黑天鹅的风险吧？不一定是个好主意。

人们总是风险厌恶者，失去100元与得到100元的心理效用是不一样的。 我们需要BTS抵押出来的BITCNY，却不需要BTS，因为BITCNY的风险少，而bts的风险大，易受价格波动影响，所以在BTS价格下跌时，人们的心理不是存有bts，而是存有bitncy。

现在的公开市场操作计划与Maker发行的系统债券MKR有相似之处，其操作方式优于MKR，劣势在于eth的价格远高于bts，导致DAI的初始供应量远多于bitcny，而实际场景ETH的面高于bts，导致bts没有稀缺性。

BITCNY需要有初始的累积量，公开市场操作资金是一部分，工人的工资也可以作为释放手段。
« Last Edit: May 16, 2018, 02:03:27 pm by binggo »
Logged
Online lochaling
Full Member
***
Posts: 65
View Profile

Re: 【喂价讨论】动态调整最低抵押率要求和爆仓惩罚
« Reply #10 on: May 11, 2018, 03:45:36 am »
暴跌了，来点正能量吧。

理事会当前想提高bitcny的产量，以应对供不应求的情况，如何做到呢？


1、将抵押线和爆仓线分离，使得bts价格30%以内（50%以内更好）的波动不会触及爆仓。
比如，现在的爆仓线是1.75，那么抵押的时候应该不低于1.75/0.7=2.5。这样抵押后，喂价跌幅超过30%才会触及爆仓线。
也就是价值2.5元的bts最多可以抵押出1bitcny，跌30%后价值变为1.75元，此时开始执行爆仓。

慢即是快，价格稳定了，不易爆仓了，虽然单笔抵押出的bitcny变少了，但抵押的人会增长更多，bitcny反而会增长得快。



2、巨蟹的判断是对的，未来bitcny的重要应用来源是公共账号。
但公共账号的10亿储备资金还是少了些，还不到足以应对任何危机的程度，应该趁着bts价格不高的时候尽量多多回购。

3、依据巨蟹的抵押公式，bts价格上涨是公共账号可以提高bitcny，价格下跌时无法提供bitcny。
光靠储备资金资金抵押回购也还不够的，巨蟹的抵押公式在bts价格上升时，能够提供bitcny，但一旦价格反转，每天20万bts可能仅够维持抵押率，无法产出新的bitcny。

（价格从4.8元跌到3元，要维持巨蟹的抵押公式，须要增加36%的bts。
如果原来的抵押仓有1000万bts，意味着须要增加360万bts才能满足，每天20万，须要18天。
而越到后期，抵押仓越大，比如抵押仓有1亿bts，则需要增加3600万bts才能满足巨蟹的抵押公式，每天释放的bts更显得杯水车薪，市值管理就起不到作用了）

4、价格下跌时须要靠手续费进行市值管理。
因此交易的费用就至为关键，单靠0.1%的手续费又太少，因此对爆仓单的手续费可以提高到5%，bts价格反转时（也是爆仓主要发生的时段），公共账户已经抵押不出资金，市值管理靠靠手续费回购为主。

测试网硬分叉版本发布: test-2.0.180510
« on: May 10, 2018, 11:13:21 pm »
中文还没来得及写。

英文见： https://steemit.com/bitshares/@abit/bitshares-testnet-release-test-2-0-180510 />
New HARD FORK release for [BitShares](https://bitshares.org/) [Open Public TestNet](https://testnet.bitshares.eu) is out, version [test-2.0.180510](https://github.com/bitshares/bitshares-core/releases/tag/test-2.0.180510). />
Hard fork time is scheduled at `Sat, 19 May 2018 13:58:00 UTC`.

Testnet nodes please upgrade, ALL PEOPLE please help test.

Mainnet release will be published after test is done, estimated date is around Tue, 12 June.

## Consensus changes:

* [BSIP26: Refund Order Creation Fee in Originally Paid Asset when order is cancelled](https://github.com/bitshares/bsips/blob/master/bsip-0026.md) />* [BSIP27: Asset Issuer Reclaim Fee Pool Funds](https://github.com/bitshares/bsips/blob/master/bsip-0027.md) />* [BSIP29: Require owner authority to change asset issuer](https://github.com/bitshares/bsips/blob/master/bsip-0029.md) />* [BSIP30: Always Allow Increasing Collateral Ratio If Debt Not Increased](https://github.com/bitshares/bsips/blob/master/bsip-0030.md) />* [BSIP31: Update Short Position's Margin Call Price After Partially Called Or Settled](https://github.com/bitshares/bsips/blob/master/bsip-0031.md) />* [BSIP32: Always Match Orders At Maker Price](https://github.com/bitshares/bsips/blob/master/bsip-0032.md) />* [BSIP33: Maker Orders With Better Prices Take Precedence](https://github.com/bitshares/bsips/blob/master/bsip-0033.md) />* [BSIP34: Always Trigger Margin Call When Call Price Above Or At Price Feed](https://github.com/bitshares/bsips/blob/master/bsip-0034.md) />* [BSIP35: Mitigate Rounding Issue On Order Matching](https://github.com/bitshares/bsips/blob/master/bsip-0035.md) />* [BSIP36: Remove expired price feeds on maintenance interval](https://github.com/bitshares/bsips/blob/master/bsip-0036.md) />* [BSIP37: Allow new asset name to end with a number](https://github.com/bitshares/bsips/blob/master/bsip-0037.md) />* [BSIP38: Add target collateral ratio option to short positions](https://github.com/bitshares/bsips/blob/master/bsip-0038.md) />* [Bugfix #184: Potential something-for-nothing fill bug](https://github.com/bitshares/bitshares-core/issues/184) />* [Bugfix #214: Proposal cannot contain proposal_update_operation](https://github.com/bitshares/bitshares-core/issues/214) />* [Bugfix #453: Multiple limit order and call order matching issue](https://github.com/bitshares/bitshares-core/issues/453) />* [Bugfix #588: Virtual operations should be excluded from transactions](https://github.com/bitshares/bitshares-core/issues/588) />* [Bugfix #868: Clear price feed data after updated a bitAsset's backing asset ID](https://github.com/bitshares/bitshares-core/issues/868) />* [Bugfix #890: Update median feeds after feed_lifetime_sec changed](https://github.com/bitshares/bitshares-core/issues/890) />
Non-consensus changes and other info to be updated.
Logged
BTS account: abit
BTS committee member: abit
BTS witness: in.abit
Offline abit
Committee member
Hero Member
*

Posts: 3081
View Profile Steemit Blog
BitShares: abit
GitHub: abitmore

Re: 测试网硬分叉版本发布: test-2.0.180510
« Reply #1 on: May 11, 2018, 01:53:37 am »
关于功能测试。

具体功能参见以前的几个帖子。
https://bitsharestalk.org/index.php?topic=25926.msg315666#msg315666 />https://bitsharestalk.org/index.php?topic=26011.msg316139#msg316139 />https://bitsharestalk.org/index.php?topic=26158.msg317036#msg317036 />
【BSIP26】下单手续费用非BTS，撤单返还原始手续费币种而不是返还BTS
测试方法（注意用其他资产付手续费）：
* 分叉前，下单+撤单：分为主动撤单，过期自动撤单，金额太小被动撤单几种；还要测部分成交后的撤单；
* 分叉前下单，分叉后撤单；
* 分叉后，下单撤单。

【BSIP27】资产发行人可以直接取出资产手续费池中的BTS
GUI 实现这个功能之前，可以用 cli_wallet 也就是命令行钱包测试。有个新命令，格式是：
claim_asset_fee_pool [资产名] [金额] [是否广播]
比如
claim_asset_fee_pool XIANHUA 1000 true
表示从 XIANHUA 的手续费池中取 1000 BTS 。

测试方法：
* 分叉前，这个命令应该会报错
* 分叉后，资产发行人可以用这个命令，需要测试：发行人正常取钱成功、非发行人取钱失败、取负数失败、超额取钱失败等等。

【BSIP29】修改资产发行人需要 Owner key
GUI 实现这个功能之前，可以用 cli_wallet 也就是命令行钱包测试。有个新命令，格式是：
update_asset_issuer [资产名] [新发行人] [是否广播]
比如
update_asset_issuer XIANHUA niufen true
表示把 XIANHUA 资产转给 niufen 。

测试方法：
* 分叉前，这个命令应该报错
* 分叉前，可以用 update_asset 命令，或者通过 GUI 修改资产发行人，需要 active key
* 分叉后，update_asset 命令不能用来修改发行人，命令里指定新发行人会报错
* 分叉后，update_asset_issuer 命令应该可以使用，需要测试：用 owner key 正常转让成功、active key转让失败、转让他人资产失败等等。

【BSIP30】在爆仓状态可以上调抵押率，但抵押率不足最低要求时不能增加借款
测试方法：
* 分叉前，爆仓状态，比如抵押率 150% 时，调仓时必须保证调整后抵押率在 175% 以上
* 分叉后，只要上调抵押率、同时保证借款不增加，就可以成功，比如，可以调整到 151% 。需要测试：正常调整成功、增加借款失败、降低抵押率失败等等。

【BSIP31】爆仓单部分成交后爆仓价自动更新
测试方法（注意：自建资产可以指定喂价人，不一定要见证人喂价）：
* 分叉前，喂高价，借款，喂低价造爆仓，吃爆仓单、强清造成实际抵押率排序与按爆仓价排序不同，甚至排名第2的已经资不抵债但不触发黑天鹅
* 分叉瞬间，爆仓价自动更新，排序与抵押率一致，触发成交甚至黑天鹅
* 分叉后，继续吃爆仓单、以及强清，爆仓价自动更新，与实际抵押率排序相同

【BSIP32】挂单撮合以 Maker 价成交
测试方法：
* 分叉前，主动吃爆仓单成交价是买单价
* 分叉后，主动吃爆仓单成交价是喂价/1.1

【BSIP33】挂单撮合时价格优先
测试方法：
* 分叉前，如果有爆仓单，并且有低于爆仓单的卖单，挂买单价格高于喂价/1.1时，会和爆仓单成交
* 分叉后，上述买单会先和低价卖单成交

【BSIP34】爆仓单不成交问题
* 分叉前，挂高价买单，然后喂价造爆仓导致挂出来不成交
* 分叉瞬间，由于规则变化，不成交的单会成交
* 分叉后，挂高价买单，会直接成交

【BSIP35】整除问题
整除问题包含5种情况：匹配两个限价单、限价单与爆仓单、强清单与爆仓单、全局清算/黑天鹅、黑天鹅之后的强清。
每种情况里还包含 0 金额和非0金额两类。
测试方法举例（限价单）（例子中数值单位为1聪，或者说资产都是0位小数）：

* 分叉前，账户A挂卖单卖 100 BTS 换 2000 卢布，账户B挂买单以 30 卢布换 1 BTS，成交结果是B花 30 卢布买 1 BTS
* 分叉后，重复上述测试案例，成交结果是B花 20 卢布买 1 BTS

* 分叉前，两个账户A和B先后都挂卖单卖 1 BTS 换 20 卢布，另一个账户 C 挂买单以 30 卢布换 1 BTS，成交结果是 A 得 20 卢布 付 1 BTS、B 白得 10 卢布、C 得 1 BTS 付 30 卢布
* 分叉后，重复上述测试案例，成交结果是A和C完成1BTS换20卢布的交易，B的单子不成交

上面的测试，因为一方是 1 ，可以单向整除，所以还不完全。可以测试类似 101 BTS 卖 2017 卢布这种情况。

其他4种情况类似。


【BSIP36】删除过期喂价
这个只影响见证人和理事会喂价的资产，需要见证人或者理事会成员来测。
测试方法：
* 分叉前，投上去一批见证人，喂价，然后换一批人，再喂价，原来那批人喂价过期后还是残留在系统里，可以查到
* 分叉瞬间，过期喂价会被清除（不影响当前喂价，所以不触发爆仓撮合成交）
* 分叉后，重复上述测试，过期喂价会在定期维护时被清除（测试网是每5分钟维护一次，正式网是整点维护）

这个功能不影响自定义喂价人的资产，也可以验证测试一下，是否影响。


【BSIP37】资产名称可以以数字结尾
测试方法：
* 分叉前，创建资产，名称可以包含英文和数字，但必须英文开头和结尾
* 分叉后，创建资产，名称可以包含英文和数字，只要求英文开头，可以用数字结尾


【BSIP38】设定爆仓后卖多少的功能
GUI 实现这个功能之前，可以用 cli_wallet 也就是命令行钱包测试。有个新命令，格式是：
borrow_asset_ext [账号] [借款金额] [借款币种] [抵押金额] [扩展字段] [是否广播]
比如
borrow_asset_ext niufen 1000 XIANHUA 100 {"target_collateral_ratio":1750} true
表示抵押 100 抵押物，借出 1000 XIANHUA ，如果爆仓，只卖出部分抵押物，到抵押率 175% 为止（可少量超过）
borrow_asset_ext niufen 1000 XIANHUA 100 null true
表示爆仓时，不限制卖多少抵押物
borrow_asset_ext niufen -500 XIANHUA 100 {"target_collateral_ratio":2000} true
表示增加 100 抵押，归还 500 XIANHUA，如果爆仓，只卖出部分抵押物，到抵押率 200% 为止（可少量超过）

注意：
* 每次调仓，必须重新指定扩展字段，新的会覆盖旧的。如果调仓时用 null ，表示不再限制爆仓时卖多少。
* 如果用老的 borrow_asset 命令，或者用没升级的 GUI 钱包调仓，则不会指定扩展字段，也就是不限制卖多少（和现在一样）。

测试方法：
* 分叉前，用大买单吃爆仓单，可以一次吃完
* 分叉前，上述命令的 [扩展字段] 参数如果不用为 null 会报错
* 分叉后，可以用非 null 。数值必须 0 - 65535 ，表示 0% - 6553.5% 。但是，如果最低抵押率是 175%，那么低于1750时会以1750为准。
* 分叉后，用大单吃爆仓单，如果爆仓单设置了扩展字段，会吃不完，这时，检查剩余仓位的抵押率和爆仓价


【Bugfix #184】这个就是 BSIP35 里的金额为 0 的情况

【Bugfix #214】用提案来批准提案
测试方法：
* 分叉前，不能把“批准提案”这个操作放到提案里。GUI里可以试，批准提案时，弹出签名确认框，选择提案再确认，会报个错。
* 分叉后，可以。

【Bugfix #453】多个大爆仓单同时砸盘时可能会和低价买单成交
测试方法：
* 分叉前，造若干个大小不一、抵押率一样的债仓，以及若干个大小不一、价格不一的买单，然后喂低价让所有债仓爆仓，会发现高价买单没成交完，低价买单有成交。
* 分叉后，重复测试，价格高的买单成交、低价的不成交

【Bugfix #588】可以签虚拟交易上链的问题
测试方法：
* 分叉前，可以把“取消清算单”操作（本应该是虚拟操作）放在一个提案中上链，虽然不会有实际效果。
* 分叉后，不行。

【Bugfix #868】修改智能资产的背书资产后，清除现有喂价
背景：发行量为 0 时，智能资产的背书资产是可以修改的。
测试方法：
* 分叉前，先喂价，然后修改背书，老的喂价数据不清除
* 分叉瞬间，错误的喂价会被清除，喂价会更新，同时重新检查爆仓单并撮合成交
* 分叉后，修改背书时，老的喂价数据会清除

【Bugfix #890】修改智能资产的喂价有效时间时，更新喂价并检查爆仓单
测试方法：
* 分叉前，先喂价，然后修改资产的喂价有效时间，不会更新当前喂价。比如改短了，该过期，但是还可以借款；或者改长，本来过期的变成不过期，该爆仓不爆。
* 分叉瞬间，喂价会更新，同时重新检查爆仓单并撮合成交
* 分叉后，修改资产的喂价有效时间时，会更新当前喂价
« Last Edit: May 19, 2018, 11:03:46 am by abit »