BitShares Forum

Main => 中文 (Chinese) => Topic started by: abit on February 26, 2018, 01:34:05 pm

Title: 【升级投票】 BSIP35 挂单撮合细节改进(整除问题)
Post by: abit on February 26, 2018, 01:34:05 pm
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 应该是付得起的。付完,平仓,不会留下什么问题。

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


第四,强清单怎么处理?

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

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

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

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


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

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

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


第六,黑天鹅后的强清

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

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


【差不多写完了,想到再补充】
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: Bangzi on February 26, 2018, 03:36:58 pm
我觉得四个方案里A,B和C会让使用者觉得内盘很麻烦,只有D方案需要内盘自己内部调整。

A方案 - 买10.1的BTS你给我10个BTS, 一定骂人
B方案 - 买卖单价钱一样了,为什么不成交?另一个以德?或者发生什么事?
C方案 - 无言

D方案 - 内盘可以通过升级强制所有内盘资产使用一样的denominator。UI需要更改是无法避免的。

总之内盘的任何更改应该是USER FRIENDLY 和 USER FIRST.



Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: gmgogo on February 26, 2018, 07:03:11 pm
这几天多花了不少冤枉钱,一直以为我买的时候设高价,会把便宜的按照他的售价给我呢,因为我设高价买,只是为了想把符合条件的一些一并买进。结果。。。。

我觉得这种问题不应该考虑照顾谁!

我总觉得应该按照时间上先挂单的价格成交为准,因为先挂的是已经属于明码标价(即使有时候一瞬间,后下单的压根看不见),不管是买单还是卖单,都是接受这个成交价格的,有的人看到了明码标价的单子,才出价购买,买回来却多花了钱,肯定不合理。

原来有挂单2.001元一个,那么即使我出价2.1元一个购买,也应该成交2.001元单价的,如果买的多,然后把卖单中2.002元,2.003元的按照价格从低到高低于2.1元的,逐渐卖给我,如果最后数量还是不够,则把我没有买够的单子以2.1元一个的价格,当作买单挂在下面等待别人卖。不能因为出价2.1元,就来个中间价格什么的,出价高是因为要买的数量多,为了操作方便而已,否则还得一个价格下一次单呢?

基于这个原则,到了精确度一定数量后,该四舍五入就四舍五入,只要大家都一样,我觉得不是问题。至于有的虚拟币几万块钱一个,我觉得也都必须接受这种现实,只要提前挂单明码标价了,就按照那个价格成交。

上面是我个人理解,由于不太懂区块链的编程技术,也不知道数据传输等是否对这些有影响,影响多大。如果技术上没有问题,我觉得就应该这么来交易。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: abit on February 26, 2018, 08:21:15 pm
这几天多花了不少冤枉钱,一直以为我买的时候设高价,会把便宜的按照他的售价给我呢,因为我设高价买,只是为了想把符合条件的一些一并买进。结果。。。。

我觉得这种问题不应该考虑照顾谁!

我总觉得应该按照时间上先挂单的价格成交为准,因为先挂的是已经属于明码标价(即使有时候一瞬间,后下单的压根看不见),不管是买单还是卖单,都是接受这个成交价格的,有的人看到了明码标价的单子,才出价购买,买回来却多花了钱,肯定不合理。

原来有挂单2.001元一个,那么即使我出价2.1元一个购买,也应该成交2.001元单价的,如果买的多,然后把卖单中2.002元,2.003元的按照价格从低到高低于2.1元的,逐渐卖给我,如果最后数量还是不够,则把我没有买够的单子以2.1元一个的价格,当作买单挂在下面等待别人卖。不能因为出价2.1元,就来个中间价格什么的,出价高是因为要买的数量多,为了操作方便而已,否则还得一个价格下一次单呢?

基于这个原则,到了精确度一定数量后,该四舍五入就四舍五入,只要大家都一样,我觉得不是问题。至于有的虚拟币几万块钱一个,我觉得也都必须接受这种现实,只要提前挂单明码标价了,就按照那个价格成交。

上面是我个人理解,由于不太懂区块链的编程技术,也不知道数据传输等是否对这些有影响,影响多大。如果技术上没有问题,我觉得就应该这么来交易。
你说的这个是 maker taker 原则,也就是说按先下单的价格来成交。现在基本上是按这个原则来的,但是处理爆仓单时有些区别。另一帖里提到的 BSIP 32 和 BSIP 33 就是为了解决这个 maker taker 原则问题,统一原则。
https://bitsharestalk.org/index.php?topic=25926.0
https://github.com/bitshares/bsips/blob/master/bsip-0032.md
https://github.com/bitshares/bsips/blob/master/bsip-0033.md


这贴说的是确定了价格之后的成交精度问题。不知道你是真的因为这个多花了冤枉钱,还是只是觉得。“该四舍五入就四舍五入”这个,说起来简单,做出来还是有差别的。现在系统实现不是最优,注意到的,会利用它来赚钱,至少尽量不亏;没注意的,就可能会亏钱。

我主贴更新了,你可以再看一下。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: abit on February 26, 2018, 10:20:40 pm
我觉得四个方案里A,B和C会让使用者觉得内盘很麻烦,只有D方案需要内盘自己内部调整。

A方案 - 买10.1的BTS你给我10个BTS, 一定骂人
B方案 - 买卖单价钱一样了,为什么不成交?另一个以德?或者发生什么事?
C方案 - 无言

D方案 - 内盘可以通过升级强制所有内盘资产使用一样的denominator。UI需要更改是无法避免的。

总之内盘的任何更改应该是USER FRIENDLY 和 USER FIRST.
主贴更新了,你再看一下。

你说的D方案,就是现在主贴里的思路四,到现在为止还只是个思路,具体方案根本没有,更别说做出来了。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: ShineQi on February 27, 2018, 12:39:53 am
我觉得这是个严肃的问题,采用方案D是必须的,也应该是可行的。传统的股票交易所也有类似的问题,他们只以法币作为唯一的计价单位,并提出了最小变动价位的概念。外汇交易平台上,也有类似的标准手的概念,和每手最低盈亏的单位,一般是10美金。因此采用方案D,限制下单必须整除,并不会对让用户感觉体验比传统的交易所低,不会带来多大影响。采用其他方案一旦被有心人发现并钻了漏洞,会造成投资人(比特股客户)的财产损失,这对比特股来说就损失大了。
以bts和cny为例,假定两者的最小单位都是1,下单一手最小数量也是1,那么下单,无论卖出bts还是cny, 其最小变动价格都应该是1。注意这时对bts的价格,系统内存在保底,即1手bts至少价值1最小单位cny。 数字资产波动较大,可能会有价格归零风险,取最极端例子,系统中的全部bts以总价为最小单位的cny挂单卖出。所以系统保底价格应该确保小于资产的手续费池/资产数量。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: lochaling on February 27, 2018, 03:09:39 am
感觉楼主把问题搞复杂了,总的原则是,应该尽量撮合成交,同时早挂单的一方得利(鼓励挂单),这样问题就解决了,同时还有利于建立深度。


假设 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
答:当然应该成交,且应该按照2.1的价格成交,成交后A有14.70bitcny和3个以价格2.001元在卖的bts,B有7个bts。


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

  因为价格比A单高,所以理论上应该成交。但是C付多少CNY呢?
答:C付出2.002*3=6.006取整等于6.00元,同时还要2bts在卖,最终A得到14.70+6.00,


4. 然后, D下单按 1.6036元每个,卖 2 个 BTS。此时,虽然C剩余的挂单是2.002元每个买2个bts,但按照先挂单者得利的原则,成交价应该依然是1.6036,
这时候D得到1.6036×2=3.2072元取整后等于3.20元.

最终A卖掉10bts得到14.70+6.00元,C总共付出6.00+3.20元得到5个bts

Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: abit on February 27, 2018, 08:14:05 am
感觉楼主把问题搞复杂了,总的原则是,应该尽量撮合成交,同时早挂单的一方得利(鼓励挂单),这样问题就解决了,同时还有利于建立深度。

答:当然应该成交,且应该按照2.1的价格成交,成交后A有14.70bitcny和3个以价格2.001元在卖的bts,B有7个bts。


没有哪个交易所吃单时不是按"盘面价"也就是早挂的单的价成交的。除非是集合竞价。
鼓励挂单一般是用手续费减免的办法。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: lochaling on February 27, 2018, 08:43:08 am
感觉楼主把问题搞复杂了,总的原则是,应该尽量撮合成交,同时早挂单的一方得利(鼓励挂单),这样问题就解决了,同时还有利于建立深度。

答:当然应该成交,且应该按照2.1的价格成交,成交后A有14.70bitcny和3个以价格2.001元在卖的bts,B有7个bts。


没有哪个交易所吃单时不是按"盘面价"也就是早挂的单的价成交的。除非是集合竞价。
鼓励挂单一般是用手续费减免的办法。


那反过来也可以呀,只要成交掉就好了,那一点尾数,划给谁都一样。
bts不一定非得同其他交易所一致。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: abit on February 27, 2018, 08:56:59 am
我觉得这是个严肃的问题,采用方案D是必须的,也应该是可行的。传统的股票交易所也有类似的问题,他们只以法币作为唯一的计价单位,并提出了最小变动价位的概念。外汇交易平台上,也有类似的标准手的概念,和每手最低盈亏的单位,一般是10美金。因此采用方案D,限制下单必须整除,并不会对让用户感觉体验比传统的交易所低,不会带来多大影响。采用其他方案一旦被有心人发现并钻了漏洞,会造成投资人(比特股客户)的财产损失,这对比特股来说就损失大了。
以bts和cny为例,假定两者的最小单位都是1,下单一手最小数量也是1,那么下单,无论卖出bts还是cny, 其最小变动价格都应该是1。注意这时对bts的价格,系统内存在保底,即1手bts至少价值1最小单位cny。 数字资产波动较大,可能会有价格归零风险,取最极端例子,系统中的全部bts以总价为最小单位的cny挂单卖出。所以系统保底价格应该确保小于资产的手续费池/资产数量。

想当然很容易,实际情况是不好做(并不是说不能做),因为要照顾到很多种情况。

传统交易所,因为基础资产就那么一个或者几个,要么CNY,要么USD,要么BTC,要么ETH,容易拍脑袋。
要用ETC换BTS,必须先换BTC或者ETH,被割一次,再换BTS,再被割一次。
不是说没人抱怨,只是交易所强势,大家只能默默承受了。

还有就是,传统交易所,发现脑袋拍错了,随时可以再拍,修改规则,甚至可以停机回滚交易,修掉BUG再恢复。BTS没法这么搞,一切都要提前想清楚,尽量避免BUG,规则尽量简单。

内盘现在有几千种资产了,两两之间可以直接交易,这有很好灵活性。

举个例子,OPEN.BTC 兑 GDEX.BTC 的交易对,怎么强制整除?价格永远接近于1,精度也一样,强制必须要么1:1要么1:2根本没法玩。

再比如,最小手谁来定义?整除到哪一位?比如,现在BTC 10w 一个。按个卖还是按0.1个卖?还是按0.00000001个卖?

再比如,行情翻转时怎么处理?BTC:BCH交易对,现在BTC价格高,可以按BTC个数来整除。万一哪天BCH价格超过BTC了呢?还是按BTC整除,要么1要么0?

再比如,抵押时怎么算?爆仓时怎么算?175%的抵押率,110%的惩罚系数,本身就不是整数。

再比如,喂价怎么算?外面各个交易所的精度不一样,有的5位有的8位,有的是USD定价有的是BTC定价。
(不要跟我说取消喂价的问题。现在还根本不是取消的时候。)

总结一下,现有系统框架已经运行的很不错了,只是有些小问题,修补一下就会更好。

我发这个贴,是为了改善目前的规则,不是为了推倒重做。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: abit on February 27, 2018, 08:59:49 am
感觉楼主把问题搞复杂了,总的原则是,应该尽量撮合成交,同时早挂单的一方得利(鼓励挂单),这样问题就解决了,同时还有利于建立深度。

答:当然应该成交,且应该按照2.1的价格成交,成交后A有14.70bitcny和3个以价格2.001元在卖的bts,B有7个bts。


没有哪个交易所吃单时不是按"盘面价"也就是早挂的单的价成交的。除非是集合竞价。
鼓励挂单一般是用手续费减免的办法。


那反过来也可以呀,只要成交掉就好了,那一点尾数,划给谁都一样。
bts不一定非得同其他交易所一致。

那你不是等于没说?

建议你再仔细看看主帖,看看一点尾数到底有多少,值不值得算清楚。你看看三楼怎么说的。

和其他交易所规则类似,认同感高,新手上手就快,利于发展。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: ShineQi on February 27, 2018, 01:28:10 pm
我觉得这是个严肃的问题,采用方案D是必须的,也应该是可行的。传统的股票交易所也有类似的问题,他们只以法币作为唯一的计价单位,并提出了最小变动价位的概念。外汇交易平台上,也有类似的标准手的概念,和每手最低盈亏的单位,一般是10美金。因此采用方案D,限制下单必须整除,并不会对让用户感觉体验比传统的交易所低,不会带来多大影响。采用其他方案一旦被有心人发现并钻了漏洞,会造成投资人(比特股客户)的财产损失,这对比特股来说就损失大了。
以bts和cny为例,假定两者的最小单位都是1,下单一手最小数量也是1,那么下单,无论卖出bts还是cny, 其最小变动价格都应该是1。注意这时对bts的价格,系统内存在保底,即1手bts至少价值1最小单位cny。 数字资产波动较大,可能会有价格归零风险,取最极端例子,系统中的全部bts以总价为最小单位的cny挂单卖出。所以系统保底价格应该确保小于资产的手续费池/资产数量。

想当然很容易,实际情况是不好做(并不是说不能做),因为要照顾到很多种情况。

传统交易所,因为基础资产就那么一个或者几个,要么CNY,要么USD,要么BTC,要么ETH,容易拍脑袋。
要用ETC换BTS,必须先换BTC或者ETH,被割一次,再换BTS,再被割一次。
不是说没人抱怨,只是交易所强势,大家只能默默承受了。

还有就是,传统交易所,发现脑袋拍错了,随时可以再拍,修改规则,甚至可以停机回滚交易,修掉BUG再恢复。BTS没法这么搞,一切都要提前想清楚,尽量避免BUG,规则尽量简单。

内盘现在有几千种资产了,两两之间可以直接交易,这有很好灵活性。

举个例子,OPEN.BTC 兑 GDEX.BTC 的交易对,怎么强制整除?价格永远接近于1,精度也一样,强制必须要么1:1要么1:2根本没法玩。

再比如,最小手谁来定义?整除到哪一位?比如,现在BTC 10w 一个。按个卖还是按0.1个卖?还是按0.00000001个卖?

再比如,行情翻转时怎么处理?BTC:BCH交易对,现在BTC价格高,可以按BTC个数来整除。万一哪天BCH价格超过BTC了呢?还是按BTC整除,要么1要么0?

再比如,抵押时怎么算?爆仓时怎么算?175%的抵押率,110%的惩罚系数,本身就不是整数。

再比如,喂价怎么算?外面各个交易所的精度不一样,有的5位有的8位,有的是USD定价有的是BTC定价。
(不要跟我说取消喂价的问题。现在还根本不是取消的时候。)

总结一下,现有系统框架已经运行的很不错了,只是有些小问题,修补一下就会更好。

我发这个贴,是为了改善目前的规则,不是为了推倒重做。
我只是在帖子中假定资产的最小单位是1,实际上可能更小。
默认最小手就设定为资产默认的最小单位,就可以了。BTC的最小单位由BTC自己定义的,我们直接采纳就行了。
以OPEN.BTC和GEDEX.BTC为例:假定最小单位都是一mbtc,二者的总发行量分别是M,N(M>=N).那么卖出OPEN.BTC购买GDEX.BTC的最高出价是卖M OPEN.BTC买1 m GEDEX.BTC,最低出价是卖1 m GEDEX.BTC 买M  OPEN.BTC. 这样就定义了价格变动的两个极限值[1/(M*1000),1000*N],系统不会保底1 OPEN.btc对应1GEDEX.BTC 实际挂单的单价的最小变动值是1m/((1000M-1m)*(M*1000),)总价最小单位是1/(M*1000*1000),即以1 m GEDEX.BTC/M OPEN.BTC的价格声卖出1 m OPEN.BTC.正常情况下是可以价格在1上下波动,波动的最小单位是1/(M*1000)。
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: abit on February 27, 2018, 05:42:36 pm
我只是在帖子中假定资产的最小单位是1,实际上可能更小。
默认最小手就设定为资产默认的最小单位,就可以了。BTC的最小单位由BTC自己定义的,我们直接采纳就行了。
以OPEN.BTC和GEDEX.BTC为例:假定最小单位都是一mbtc,二者的总发行量分别是M,N(M>=N).那么卖出OPEN.BTC购买GDEX.BTC的最高出价是卖M OPEN.BTC买1 m GEDEX.BTC,最低出价是卖1 m GEDEX.BTC 买M  OPEN.BTC. 这样就定义了价格变动的两个极限值[1/(M*1000),1000*N],系统不会保底1 OPEN.btc对应1GEDEX.BTC 实际挂单的单价的最小变动值是1m/((1000M-1m)*(M*1000),)总价最小单位是1/(M*1000*1000),即以1 m GEDEX.BTC/M OPEN.BTC的价格声卖出1 m OPEN.BTC.正常情况下是可以价格在1上下波动,波动的最小单位是1/(M*1000)。


第一个问题, OPEN 和 GDEX 作为两个网关,谁也不服谁,凭什么把一个作为基础,另一个必须取整定价?

第二,你帖子里参数太多,看着晕。换成实际数值可能好理解点?

假设 OPEN.BTC 和 GDEX.BTC 最小单位都是 1m BTC,即0.001 。

当前供应量 OPEN.BTC 是 700 ,GDEX.BTC 是 200 。

假设 A 有 0.03 个,也就是 30个最小单位的 OPEN.BTC  想卖成 GDEX.BTC ,价格 1 以上,他最少会卖到多少?

假设 B 有 0.007 个也就是 7 个最小单位的 GDEX.BTC 想换成 OPEN.BTC,和 A 成交时,双方各拿多少?
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: gmgogo on February 27, 2018, 06:29:37 pm
这几天多花了不少冤枉钱,一直以为我买的时候设高价,会把便宜的按照他的售价给我呢,因为我设高价买,只是为了想把符合条件的一些一并买进。结果。。。。

我觉得这种问题不应该考虑照顾谁!

我总觉得应该按照时间上先挂单的价格成交为准,因为先挂的是已经属于明码标价(即使有时候一瞬间,后下单的压根看不见),不管是买单还是卖单,都是接受这个成交价格的,有的人看到了明码标价的单子,才出价购买,买回来却多花了钱,肯定不合理。

原来有挂单2.001元一个,那么即使我出价2.1元一个购买,也应该成交2.001元单价的,如果买的多,然后把卖单中2.002元,2.003元的按照价格从低到高低于2.1元的,逐渐卖给我,如果最后数量还是不够,则把我没有买够的单子以2.1元一个的价格,当作买单挂在下面等待别人卖。不能因为出价2.1元,就来个中间价格什么的,出价高是因为要买的数量多,为了操作方便而已,否则还得一个价格下一次单呢?

基于这个原则,到了精确度一定数量后,该四舍五入就四舍五入,只要大家都一样,我觉得不是问题。至于有的虚拟币几万块钱一个,我觉得也都必须接受这种现实,只要提前挂单明码标价了,就按照那个价格成交。

上面是我个人理解,由于不太懂区块链的编程技术,也不知道数据传输等是否对这些有影响,影响多大。如果技术上没有问题,我觉得就应该这么来交易。
你说的这个是 maker taker 原则,也就是说按先下单的价格来成交。现在基本上是按这个原则来的,但是处理爆仓单时有些区别。另一帖里提到的 BSIP 32 和 BSIP 33 就是为了解决这个 maker taker 原则问题,统一原则。
https://bitsharestalk.org/index.php?topic=25926.0
https://github.com/bitshares/bsips/blob/master/bsip-0032.md
https://github.com/bitshares/bsips/blob/master/bsip-0033.md


这贴说的是确定了价格之后的成交精度问题。不知道你是真的因为这个多花了冤枉钱,还是只是觉得。“该四舍五入就四舍五入”这个,说起来简单,做出来还是有差别的。现在系统实现不是最优,注意到的,会利用它来赚钱,至少尽量不亏;没注意的,就可能会亏钱。

我主贴更新了,你可以再看一下。
非常抱歉,我是看到原来的主题贴以后想当然的以为多花了冤枉钱。今天专门测试了一下,没有多花,的确是按照最先挂单的价格成交的。
原来我对主题贴的理解就出现了偏差,从而回复了一些不对应的内容,非常惭愧!
Title: Re: 谁来讨论下 BSIP35 挂单撮合细节(整除问题)
Post by: ShineQi on March 01, 2018, 07:23:26 am
我只是在帖子中假定资产的最小单位是1,实际上可能更小。
默认最小手就设定为资产默认的最小单位,就可以了。BTC的最小单位由BTC自己定义的,我们直接采纳就行了。
以OPEN.BTC和GEDEX.BTC为例:假定最小单位都是一mbtc,二者的总发行量分别是M,N(M>=N).那么卖出OPEN.BTC购买GDEX.BTC的最高出价是卖M OPEN.BTC买1 m GEDEX.BTC,最低出价是卖1 m GEDEX.BTC 买M  OPEN.BTC. 这样就定义了价格变动的两个极限值[1/(M*1000),1000*N],系统不会保底1 OPEN.btc对应1GEDEX.BTC 实际挂单的单价的最小变动值是1m/((1000M-1m)*(M*1000),)总价最小单位是1/(M*1000*1000),即以1 m GEDEX.BTC/M OPEN.BTC的价格声卖出1 m OPEN.BTC.正常情况下是可以价格在1上下波动,波动的最小单位是1/(M*1000)。


第一个问题, OPEN 和 GDEX 作为两个网关,谁也不服谁,凭什么把一个作为基础,另一个必须取整定价?

第二,你帖子里参数太多,看着晕。换成实际数值可能好理解点?

假设 OPEN.BTC 和 GDEX.BTC 最小单位都是 1m BTC,即0.001 。

当前供应量 OPEN.BTC 是 700 ,GDEX.BTC 是 200 。

假设 A 有 0.03 个,也就是 30个最小单位的 OPEN.BTC  想卖成 GDEX.BTC ,价格 1 以上,他最少会卖到多少?

假设 B 有 0.007 个也就是 7 个最小单位的 GDEX.BTC 想换成 OPEN.BTC,和 A 成交时,双方各拿多少?

我在尝试解答你的问题时,发现按此思路下去,还是不能解决问题,如果增加系统实际结算的粒度,使其远远高于资产的最小单位,强行限制整除,在挂单的所有可能取值的范围内也还是会有太多的情况需要限制。
Title: Re: 【升级投票】 BSIP35 挂单撮合细节改进(整除问题)
Post by: abit on March 01, 2018, 04:53:35 pm
开始投票了。支持修改的,在钱包里投对应的 worker 。

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