Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - abit

Pages: [1] 2 3 4 5 6 7 8 ... 10
1
BitAssets' MCR (median collateral ratio) is calculated from price feeds, it can change when feed changes, although rare (according to current use cases in production aka BitShares mainnet).

MCR affects all margin positions. When MCR increased, more short positions will be put into margin call territory; when MCR decreased, more short positions will be pull out of margin call territory.

So, ideally, when MCR changed, all short positions should be reevaluated.

Since the quantity of short positions can be very large, for better performance, a caching mechanism is used in current system, aka "call price". When a short position is created, we calculate its call price with current MCR; when its collateral and/or debt got updated, we update its call price according to current MCR. When median feed price reached call price, the short position is put into margin call territory; when feed price changed backwards, the short position is pull out of margin call territory.

However, in current system, we don't refresh the "call price" cache when MCR changed, that said, existing short positions' call prices can be inconsistent with latest MCR. In the meanwhile, call prices of new positions or updated positions will be always up-to-date as long as MCR didn't change. This may lead to unintended margin calls when MCR decreased, or unintended inability to call when MCR increased.

By the way, BSIP31 partially solved the cache refreshing issue: before BSIP31, when a short position is partially called or settled, its call price won't be updated; after BSIP31, it will. https://github.com/bitshares/bsips/blob/master/bsip-0031.md

Another related feature is BSIP38, using "target_collateral_ratio" option will effectively avoid unintended margin calls, somewhat of double insurance. However, if a borrower is not using "target_collateral_ratio" option, her position can be called unintendedly after MCR decreased. https://github.com/bitshares/bsips/blob/master/bsip-0038.md

Now come back to the MCR topic.

To solve the cache inconsistency issue, we have options:

1. totally drop the caching mechanism, calculate call prices on the fly (may impact order matching performance)

2. update "call price" cache immediately when MCR changed (may impact performance since possibly need to update lots of data at a time)

3. update "call price" cache at maintenance interval since maintenance interval is meant to be used to process mass calculation

With the 3rd approach,

3.1 if we don't change MCR update behavior, aka update "current effective" MCR directly when feed changed, then the call price cache will be still inconsistent before maintenance interval;

3.2 we can defer MCR update to maintenance interval, that said, when detected a MCR change due to feed change or asset option e.g. feed lifetime change, don't apply the MCR update immediately, but apply it in next maintenance interval. With this approach, the call price data will be always consistent to "current effective" MCR.
  * pros: data consistency
  * cons: probably poorer user experience (UX), since users (usually asset issuers and feed producers) need to wait when wanted to update MCR.


Summary:
I recommend the 3.2 approach: defer MCR update to maintenance interval, update call price cache every time after MCR updated.

Thoughts?

2
中文(Chinese) / 测试网硬分叉版本发布: 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.

3
General Discussion / New BitShares TESTNET release: test-2.0.180510
« on: May 10, 2018, 11:11:33 pm »
This is a repost of 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.

NOTE:

Nodes please upgrade BEFORE the scheduled hard fork time, e.g. upgrade NOW, but not upgrade after the time. If some active witnesses didn't upgrade in time, there will be unintended forking.

Testnet witnesses who have upgraded please leave a message in this thread.

Testnet witnesses who want more votes please leave a message as well.

4
中文(Chinese) / 新版重钱包 2.0.180425
« on: April 25, 2018, 09:37:08 pm »
BTS 2.0.180425 新版本已发布。这是一个BUG修复版本。

下载地址: https://github.com/bitshares/bitshares-core/releases/tag/2.0.180425

这个版本修复了一个账户历史插件的问题,该问题会导致某些情况下节点会记录错误的操作历史ID。主要影响第三方合作者进行系统对接。

这个问题不影响共识和安全。

## 谁需要更新,需要怎么做

交易所、网关、商户等第三方合作者,如果运行 witness_node 节点时使用了 `track-account` 参数,并且依赖于操作历史 ID (即 `1.11.x`)来唯一识别转账等交易记录,那么很可能已经受到这个BUG影响。

解决方法:
1. 升级到新版本;
2. 使用 `--replay-blockchain` 参数重启节点;
3. 仔细检查以往处理过的操作历史记录 ,和升级后的节点返回的 ID 进行对比,如果需要,处理好其中的差异;
4. 可能需要重新审查业务处理逻辑。

请注意,上面第3点很重要,其目的是为了防止同一笔交易(比如充值)被重复处理,导致损失。因为使用 `--replay-blockchain` 参数重启后,账户操作历史ID可能已经发生变化,比如,某一笔充值在升级前的 ID 是 `1.11.123456789` ,升级后可能变成了 `1.11.123456700` ,如果对接程序不能识别这两个ID其实对应的是同一笔交易,会导致重复入账,带来资金损失。

之前的版本都受到这个bug影响。

## 谁没有受影响

这里列出若干种可能没有受到bug影响的情形。但是,为了您的资金安全,请自行甄别确定是否受到影响。

* 这个bug不影响 `delayed_node` ,所以 `delayed_node` 返回的数据一直是准确的,虽然 `delayed_node` 连接到的 `witness_node` 数据可能不准确。如果对接程序只从 `delayed_node` 获取操作历史 ID,那么应该没有受到bug影响。
  * 注意,如果对接程序也从 `witness_node` 读取数据,则可能受到bug影响

* 不依赖 `1.11.x` 这种ID来识别唯一交易的对接程序,比如按照交易的txID或者签名来识别的,不受这个bug影响。

* 没有使用 `track-account` 参数的节点不受这个BUG影响。
  * 使用默认参数运行的节点不受影响
  * 见证人、API节点、种子节点一般不会使用 `track-account` 参数,所以应该不受影响

* 个人节点可能会配置 `track-account` 参数,所以可能受到影响;但是,一般用户使用节点时,并不关心 `1.11.x` 这种操作历史ID,所以一般来说不用升级。

## 关于BUG的更多信息

如果使用了 `track-account` 参数,当网络发生分叉(常见的原因比如延迟),没升级的节点的账户历史插件会跳过一些操作ID,导致后续的操作ID都不正确。在使用 `--replay-blockchain` 参数重启后,账户历史插件内部的老数据的ID会被自动修正,但是新的数据ID还是可能出错。

升级后的节点不会再跳过ID,保证ID连续,所以不再会有这个问题。

相关 issue 和 pull request 见 https://github.com/bitshares/bitshares-core/issues/585 , https://github.com/bitshares/bitshares-core/pull/873


5
这贴是开头,先说一下原则。

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

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

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

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

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

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

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

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

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

【待续】

6
中文(Chinese) / 新版重钱包 2.0.180328
« on: April 03, 2018, 07:57:42 am »
BTS 2.0.180328 新版本已发布。由于修正了若干重大安全问题,请所有节点尽早升级。

下载地址: https://github.com/bitshares/bitshares-core/releases/tag/2.0.180328

由于有数据变化,升级会自动 replay 。

安全更新:
* FC Json 处理问题修复
* FC 序列化问题修复
* FC variant 处理问题修复
* 修复一个无效迭代器解引用问题
* 修复一个负金额问题

新功能及改进:
* 新增`grouped_orders`插件及API,将盘面挂单按价差比例分组,可以更清晰的显示盘面深度信息
* 新增`es_objects`插件,将一些常用对象存入Elastic Search外部数据库,用于快速检索
* 新增API,获取账号相关withdraw_permission对象,用于定期收款功能
* 新增API,获取交易额最大的交易对清单(待改进)
* CLI新增广播裸交易的命令,用于离线签名
* 将提案人加入到提案对象,方便显示
* 订阅市场后会自动推送强清单变动信息
* version参数显示更多版本信息
* 账户历史查询性能优化
* 插件消毒

BUG修复:
* 修复Linux内核版本高于4.4时websocket连不上的问题
* 修复P2P连接有时没有正常断开的问题
* 修复ElasticSearch插件的HTTP头设置问题
* 部分修复CLI里账户缓存的问题
* 修复replay时会创建无用空目录的问题

其他改动:
* 集成Travis-CI自动编译环境
* FC增加Doxygen支持
* 用editline库替代了readline库(版权问题)
* 增加CLI测试框架
* 其他小改动和代码清理

贡献者名单:
* [@pmconrad](https://github.com/pmconrad)
* [@abitmore](https://github.com/abitmore)
* [@oxarbitrage](https://github.com/oxarbitrage)
* [@jmjatlanta ](https://github.com/jmjatlanta )
* [@xeroc](https://github.com/xeroc)
* [@ryanRfox](https://github.com/ryanRfox)
* [@aautushka ](https://github.com/aautushka )
* [@ihla](https://github.com/ihla)
* [@marcialvieira](https://github.com/marcialvieira)
* [@zhuliting](https://github.com/zhuliting)
* [@cifer-lee](https://github.com/cifer-lee)
* [@tmfc](https://github.com/tmfc)

7
Stakeholder Proposals / Pay USD workers with fees collected in USD
« on: March 21, 2018, 09:14:14 am »
Since we're charging fees in USD, we can pay USD workers with the fees collected, to reduce unnecessary buy/sell operations.

8
已发起 worker 方式的投票,请在钱包内参与。如果通过的话,这个功能会加入下个协议升级(硬分叉)版本。

英文链接: https://github.com/bitshares/bsips/blob/master/bsip-0038.md

相关讨论:
https://bitsharestalk.org/index.php?topic=25924.0
https://github.com/bitshares/bsips/issues/51

------ 正文 ----------

按现在的爆仓机制,爆仓单成交时,卖出的抵押品数量以买单大小为准。也就是说:
* 如果正好有个大买单,那么债仓可能被关闭,按成交价卖出对应数量的抵押品
* 如果只有小买单,那么就会少卖一点

在BSIP 31 实施后,爆仓单部分成交后抵押率会自动调整,同时爆仓价降低,可能就变成不爆仓。
但是,这并不能防止大买单一次性完全吃掉爆仓单。

总的来说,爆仓时强制卖掉抵押品,会提高剩余仓位的抵押率;卖的越多,剩余仓位的抵押率越高。

对交易者来说,在出现爆仓时,
* 有的交易者希望直接止损或者止盈,也就是卖出全部抵押品(当前机制);
* 有的交易者希望能保留尽可能大的仓位,也就是尽可能少卖抵押品;
* 有的交易者希望稍微多卖一点,但不全部卖完,目的只是为了防止马上又爆。

为了解决这个问题,基于系统中立原则,提出了 BSIP 38 方案。具体为:

Quote
抵押借款时、或者主动调整债仓时,可以指定一个目标抵押率 TCR(target collateral ratio),也可以不指定;
如果不指定目标抵押率,那么爆仓单成交时仍然按照买单大小为准,与当前规则相同;
如果指定了目标抵押率,那么爆仓单成交时,最多只会卖出一部分抵押品,直到剩余仓位的抵押率达到这个抵押率为止。
如果指定的目标抵押率低于 MCR 也就是最低不爆仓的抵押率(通常是 175%),那么以 MCR 为准。

这个参数不影响强清。

具体的计算公式这里就先不列了。

具体用法为:
* 如果想爆仓时尽可能少卖抵押品,那么就把 TCR 尽量设低,但不能低于 MCR ;
* 如果想多卖一点但不全卖,那么就把 TCR 稍微设高一点,比如设成 185% 或者 200% 等等;
* 如果想尽可能多卖,那么就不要设 TCR 。

9
There is a new committee proposal created.

http://cryptofresh.com/p/1.10.8736

This proposal is to adjust the fee schedule to about 627% of current rate.

Please check and vote.

The proposal can be found on "Proposed transactions" tab of https://wallet.bitshares.org/#/account/committee-account .

10
General Discussion / Committee proposals
« on: March 09, 2018, 01:31:11 pm »
The proposals can be found on "Proposed transactions" tab of https://wallet.bitshares.org/#/account/committee-account .

1. Collect fees collected in bitCNY and etc and send to "committee-trade" account, prepare for sale.

https://cryptofresh.com/p/1.10.8621
https://cryptofresh.com/p/1.10.8622
https://cryptofresh.com/p/1.10.8623
https://cryptofresh.com/p/1.10.8624
https://cryptofresh.com/p/1.10.8625
https://cryptofresh.com/p/1.10.8626


2. Change market fees of bitCNY and bitUSD to 0.1%, for example, when a trader would get 1000 CNY by selling another asset e.g. BTS, 1 CNY will be charged.

https://cryptofresh.com/p/1.10.8631
https://cryptofresh.com/p/1.10.8632

Please vote.

11
2018年3月1日更新:已发起 worker 方式的投票,请在钱包内参与。

----原文----

英文链接在这里 https://github.com/bitshares/bsips/blob/bsip35/bsip-0035.md ,希望有人一起严肃讨论下。
讨论链接是 https://github.com/bitshares/bsips/pull/59

这个 BSIP 目的是缓解挂单撮合算法中的整除问题。基于目前设计,只能缓解,并不能完全解决。

什么是整除问题呢?举个例子。

假设 BTS 最小单位是 1, CNY 最小单位是 0.01 。

1. 首先, A 下单按 2.001 元价格卖 10 个 BTS,理想情况下他可以得到 2.005*10 = 20.01 元,符合最小单位要求。

2. 然后, B 下单按 2.1 价格买 7 个 BTS。 这两个单 到底是成交呢,还是不成交呢?如果成交,按什么价成交?

  你可能有答案了: 按2.001成交不满足最小单位需求,那么可以把价格向上取整,按 2.01成交,两个人都不亏。

  成交完,A的单子还剩3个BTS,价格还是2.001

3. 然后, C 下单按 2.002 每个,买 5 个 BTS。理想情况下他会付出10.01CNY得到5个BTS,符合最小单位要求。

  因为价格比A单高,所以理论上应该成交。但是C付多少CNY呢?

  按A的要求,6CNY太少(6/3=2<2.001);
  按C的要求,6.01CNY太多(6.01/3=2.003>2.002),特别是,付完6.01后,他只剩4CNY了,不够按2.002的价继续买2个BTS。

这个例子还比较简单,实际系统里有更复杂的情况,并且有些数额也很大,需要重视。
比如 BTTWY 资产一聪值几十块,整除一下出入就是几十块;水滴资本上万CNY一个,整除一下,几千块就没了。

针对上面的情况,有这么几个处理思路:

思路一:成交,具体价格照顾其中一方利益。
  优点是成交量大,实现不难;
  缺点是没被照顾的一方会不爽。

思路二:只成交能完全匹配的,不能完全匹配就挂着不成交,允许盘面上有买卖单价格重合。
  优点是看起来没人会不爽,因为能成交的都是满足了条件的;
  缺点是实际上会很不爽,因为价格重合的盘面很难看,一般交易者很难知道怎么样去完全满足条件,成交量会低;因为规则复杂,能完全成交的单子必定价格不会好;并且实现复杂。

思路三:取消其中一个单子,这样盘面上不会出现价格重合。
  优点是盘面清楚,并且能成交的必然满足了双方条件。
  缺点是交易者仍然很难知道怎么样去满足成交条件,下单失败率会很高,并且下单后会被取消,体验差,成交量会低;预计容易出现恶意攻击导致别人单子取消掉的情况。

思路四:下单价格必须保证整除
  优点:价格已经能整除,那么就没有整除问题了
  缺点:几千个资产可以两两交易,还可以翻转交易方向,要保证都能整除,还没有具体方案;强制整除必定要舍弃一些灵活性,值不值得还不一定;至于方案出来后的开发工作量,现在还都不用谈。
      说白了,这个思路,现在做不出来。谁想往这个方向推的,拿出详细方案来。


实际上,目前 BTS 系统里采用的是 1+3 的混合方案。

1. 成交时照顾大单。
  以普通限价单为例,下单时,要符合最小单位要求,单子包含的卖出金额和期望买入的数额必然都是整数。如果一个小单是完整的,那么匹配后,必然可以得到一个完整的数额(作为maker),没有整除吃亏的问题,甚至会得到更多(作为taker)。出现整除问题,必然是因为这个单子部分成交过了,也就是说至少和另一个小单匹配过了,也就是说,受到过照顾了。那么,即使最后一次匹配不被照顾,总体不亏。
  同时,照顾大单,那么大单部分成交后剩下的金额不会有亏空,利于后面继续撮合成交。

  上面例子里,A和B匹配时,因为A先挂单,所以价格按A的来,所以成交金额是 2.001*7=14.007;因为最小单位是0.01,而A单子大,所以照顾A,最优方案应该向上取整为14.01,精确成交价为 2.0014。

  A和C匹配时,还是按A的价格成交,成交金额是 2.001*3=6.003,因为C单子大,所以照顾C,也就是说,向下取整得到 6.00 ,A会获得6CNY。虽然看起来这次匹配亏了点,但从整体看,前面7BTS已经卖出14.01,14.01+6=20.01,和他预期的一样,总体是不亏的。

3. 如果一个单子小到匹配后会付出一些,但什么都得不到,也就是说出现 somthing-for-nothing 问题,那么就不成交,而是取消这个单子。
  上面说了,完整单是不会有整除问题,不会什么都得不到。不完整单一定是以前受过照顾了,那么,最后剩的一点卖不出最小单位,说明之前获得的已经足够了,取消也不会亏,剩下的都是赚的。
  这个主要解决的是感受问题,看到成交单里有付出N得到0总是很不爽的,这个做法是为了避免这种不爽。

所以,这样的方案兼顾了灵活性、最大成交量、一定程度上的公平。


那么,这个方案还有什么问题呢?

实际上,方向是不错的,但还有些小问题。

第一,拿前面A和B的匹配来说,现在系统并不是按照最优解来的。

这里先普及一个知识:现在系统里所有的单子都是按卖单来实现的,钱包里挂买单,实际是反向挂一个卖单。
那么,卖单和买单有什么区别呢?区别在于对超额的处理。

拿上面的B的例子,用2.1每个,买7个BTS,
* 如果是买单,那么含义是:最多买7个BTS(第一条件),最多付出2.1*7=14.7CNY(第二条件),如果买够了7个BTS,就停止(第三条件)。
* 如果是卖单,那么含义是:最多付出14.7CNY(第一条件),最少换7个BTS(第二条件),如果能换更多BTS,就换更多(第三条件)。

所以,实际上B是挂了个卖出14.7CNY的单。当和A成交时,按A的价格成交,应该换 14.7/2.001=7.3个BTS,由于A单子大,所以照顾A,把这7.3个BTS向下取整成了7个BTS,B实际付出14.7,精确成交价 2.1 。

呵呵,想不到吧?

BSIP 35 方案的其中一条,就是解决这个问题,按最优解来,也就是最小亏损原则。

那么,怎么得出最优解呢?做法就是在把收到的 7.3 BTS 向下取整成 7 后,反向算出应该付的 CNY 金额 2.001*7=14.007 再向上取整得出 14.01,剩下的0.69因为买不到1个BTS,就退给B,成交完成。这样可以保证A还是被照顾,但B不亏太多。

归纳成规则就是:按先下的单的价格成交,把小单收到的金额向下取整,再把小单应该付出的金额向上取整,多余的退还。


第二,虽然系统有取消极小单的设计,但现在有个BUG,导致某些情况下极小单并不会被取消,而是会送掉。

所以 BSIP 35 里还要修这个BUG。


第三,前面的例子是限价单。那么爆仓单怎么办?爆仓单如果很小,应该怎么取消?

答案是,爆仓单不能取消。

爆仓单,意味着借钱要还。爆仓单极小,意味着付不到 1 个BTS就够还借的所有债了(这里仍然假设BTS最小单位是1)。但是,欠钱就是欠钱,别想赖账,别想别人替你还、而自己什么都不付出。所以至少付 1 BTS。爆仓单还在,没有黑天鹅,说明抵押还在,那么 1 BTS 应该是付得起的。付完,平仓,不会留下什么问题。

也就是说,爆仓单的最后零头,应该是向上取整的来成交的。但其他部分,还是按照照顾大单+最小亏损的原则来。


第四,强清单怎么处理?

一部分答案是:极小的强清单也取消;强清单和债仓匹配时,也按照顾大单+最小亏损的原则来,债仓最后零头也是要向上取整。

需要考虑的一个情况是,强清有每小时的总量限制,因为这个限制,单次执行的强清大单会变成小单、甚至极小单。

处理办法是,仍然按照照顾大单+最小亏损的原则,但是,要识别出是真正的极小单、还是限制导致的临时极小单,
* 真正的极小单,取消
* 临时的极小单,留着等下次匹配

顺便说下,强清的代码逻辑本来就比较复杂,现在更复杂,改起来要费点功夫。


第五,出现黑天鹅,进行全局清算时的处理

参照爆仓,债仓别想赖账,一律按向上取整处理。

(现在系统里是向下取整,理论上会出现不需要还债的情况发生)


第六,黑天鹅后的强清

这种强清单,相对于全局抵押池来说,都是小单,所以属于不被照顾的。

但是要按最小损失原则处理,包含拒绝极小单。(现在系统里没有这个处理)


【差不多写完了,想到再补充】

12
Stakeholder Proposals / New BSIP's about market engine improvements
« on: February 20, 2018, 11:13:18 am »
Changing of behavior requires approval of stake holders.

BSIP's (BitShares Improvement Protocols) are documents those should clearly describe the changes, then to be voted on by stake holders, then to be coded/implemented and tested and then deployed.

Here are changes about the market engine that will need to be voted on in the near future:

* BSIP 30: Always Allow Increasing Collateral Ratio If Debt Not Increased, https://github.com/bitshares/bsips/blob/master/bsip-0030.md

* BSIP 31: Update Short Position's Margin Call Price After Partially Called Or Settled, https://github.com/bitshares/bsips/blob/master/bsip-0031.md

* BSIP 32: Always Match Orders At Maker Price, https://github.com/bitshares/bsips/pull/56

* BSIP 33: Maker Orders With Better Prices Take Precedence, https://github.com/bitshares/bsips/pull/57

* BSIP 34: Always Trigger Margin Call When Call Price Above Or At Price Feed, https://github.com/bitshares/bsips/pull/58

* BSIP 35: A Solution To Something-For-Nothing Issue, https://github.com/bitshares/bsips/pull/59

(BSIP 26, 27 and 29 are considered as approved already so not listed here)

(There are other topics not included in this list, E.G. stop-loss order, since IMHO we need to improve step by step, and IMHO at this moment we're not ready to make those changes.)

In order to make the voting process as smooth as possible, it's best to thoroughly discuss the details before starting to vote.

Please participate.

(Perhaps should post this to proposals board? If yes, please help move it.)

13
中文(Chinese) / 刚刚发现一个从 BTS 代码自动生成的文档
« on: February 04, 2018, 05:24:25 pm »

14
2018年3月1日更新:已发起 worker 方式的投票,请在钱包内参与。

公告见 https://steemit.com/bitshares/@bitshares.fdn/improvements-to-the-bitshares-protocol-up-for-vote

----原文----

预计在 3 月份发布一个硬分叉新版本(预计设定实际生效时间为 4 月),修正以下几个问题。

最近会开始用 worker 的方式投票,通过后才能实施。

1. 已经是爆仓状态但没成交的债仓,调整抵押必须调整到不爆仓(即爆仓单低于喂价),而不能稍微增加抵押率但仍然是爆仓状态。

   修改方案:改为可以调整,但爆仓状态的债仓只能增加抵押率,不能降低抵押率(2.26更新补充规则:同时还不能增加债务)

   这个是 BSIP 30 。

2. 已经有爆仓卖单时,新下的买单价格如果在爆仓单的【爆仓价,最低卖价】区间,会优先匹配爆仓单成交,而不会先匹配价格更低的限价卖单(普通卖单)。

   当然,如果买单价低于爆仓单最低卖价,会匹配卖单成交,这是正常情况。

   修改方案:改为优先匹配价格低的卖单,不管是限价卖单还是爆仓卖单

   这个是 BSIP 33 里提到的一种情况。

3. 已经有爆仓卖单时,新下的买单如果可以和爆仓单匹配,即价格在爆仓单的【爆仓价,最低卖价】区间时,成交价会是买单设定的最高价,而不是爆仓单最低卖价。

   另外,如果已经有买单,新出现爆仓卖单时,成交价是买单设定的价格,这是正常情况。

   修改方案:新下买单的话,按爆仓单最低卖价成交;新出现爆仓卖单时,按买单价成交

   这个是 BSIP 32 。

4. 已经有爆仓卖单时,新下的买单如果比爆仓价(不是指当前最低卖价)高,会不成交

   同样的,如果盘面上同时有爆仓单和高于爆仓单的买单,新下的任何买单都不会和爆仓单匹配成交

   同样的,如果有高于爆仓价的买单,当喂价下降产生新的爆仓单时,会显示爆仓但不成交

   修改方案:买单价如果比爆仓价高,也会成交。成交价按照上面问题 3 里指定的规则。

   这个是 BSIP 34 。

5. 如果盘面上突然出现多笔可以成交的爆仓单,包含几种情况:
 
   * 没有价格比爆仓价高的买单,喂价突然下降到多个债仓的爆仓价以下时
 
   * 有价格比爆仓价高的买单,也有显示爆仓但没有成交的债仓,有大单把比爆仓价高的买单砸掉之后

   * 有价格比爆仓价高的买单,也有显示爆仓但没有成交的债仓,买单主动撤单后(但买单过期导致的自动撤单不会触发这个问题(误报BUG,删除))

   这时,爆仓单可能会“砸穿买墙”,即不和价格最高的买单成交,而是和价格更低的买单成交。

   这种情况只会在爆仓价最低的债仓完全成交后,以及价格最高的买单完全成交后,才会触发。
 
   这个是 alt 上次提到过的问题。

   修改方案:

   * 喂价下降导致有新爆仓单的情况,总是优先匹配价格最高的买单

   这个是 BSIP 33 里提到的的另一种情况。

   * 另外两种情况,在问题 4 修正后自动解决,不需要独立修改

6. 如果在一个买单过期自动撤单后,盘面上突然出现多笔可以成交的爆仓单,不会成交。

   修改方案:问题 4 修正后,这个问题自动解决,不需要独立修改
(误报BUG,删除)

7. 爆仓单部分成交后,实际抵押率提高了,但爆仓价不变。

   修改方案:

     爆仓价按抵押率实时调整。

     也就是说,如果债仓部分成交,剩余部分抵押率会上升,同时爆仓价会下降,就有可能不再爆仓;

     同样的,一个债仓部分成交后,新的爆仓价可能低于其他债仓的爆仓价,这时优先爆其他债仓。

   这个是 BSIP 31 。

小结:

   这些修改后, BTS 内盘的撮合交易规则会更接近于其他交易所。


其他优化内容:

1. 下单时支付的手续费如果不是 BTS ,如果没有部分成交,撤单时,下单手续费会以 BTS 的形式退回

   这种设定的结果,是任何人如果持有某资产,可以按该资产设定的汇率来“卖出”资产,换取资产手续费池里的 BTS 。

   这个也导致完全不想持有 BTS 的人会被强制持有一些 BTS (甚至会在一定程度上增加卖压)。

   当然,如果已经部分成交,那么撤单时不退下单手续费。

   修改为:

   - 撤单时按下单时支付手续费的资产退费。如果是因为过期导致的自动撤单,则额外按照下单时的汇率扣减撤单手续费。

   - 部分成交的单子,撤单时不退下单手续费。如果是因为过期导致的自动撤单,也不额外扣撤单手续费。

   这个是 BSIP 26 。

2. 新增功能:资产发行人(资产注册人)可以直接取出手续费池里的 BTS 。

   这个是 BSIP 27 。

3. 功能修改:资产所有权转让现在只需要 active key ,修改为需要 owner key 。

   这个是 BSIP 29 。

4. 功能修改:允许资产代码以数字结尾。

   目前,资产代码中可以有数字,但必须以字母开头和结尾。这个提案是修改成可以数字结尾。这样就可以创建类似 SZ50 (上证50指数)这样的资产。

  这个是 BSIP 37 。

5. 性能优化:剔除系统中的过期喂价数据。

  目前,见证人发布喂价后,即使过期,也会存在于系统中,不参与计算,但占用内存、消耗网络带宽(获取资产信息时会包含这些过期数据)。因为理论上资产喂价有效期可以修改,所以过期的喂价可能会重新变成有效,虽然实际上很少有资产这么改。这个提案是说,每个整点维护时,删除过期数据,那么,即使修改了喂价有效期,被删的喂价也不会再参与计算。

  这个是 BSIP 36 。

15
中文(Chinese) / 新版重钱包 2.0.180202
« on: February 03, 2018, 07:25:02 am »
https://github.com/bitshares/bitshares-core/releases/tag/2.0.180202

这个版本不包含硬分叉。由于有数据变化,升级会自动 replay 。

主要修改内容:

* 修正两个可能导致API服务器宕机甚至整个网络停摆的漏洞

* 增加一个方便交易所使用的账户历史查询API

* 更新 Docker 配置和文档

* 市场查询API不再使用浮点数,现在会返回更精确的数据。删除命令行钱包中使用浮点数的两个挂单命令(一直不好用)

* 修正一个问题,使得在轻钱包里可以更方便的用Owner key来签名

* 修正一个K线图数据异常问题(强清相关)

* 其他一些小修改和和代码清理


下个版本预计3-4月发布,是硬分叉版本,主要内容是市场撮合引擎和资产方面的逻辑优化。

Pages: [1] 2 3 4 5 6 7 8 ... 10