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.


Messages - bitcrab

Pages: 1 ... 69 70 71 72 73 74 75 [76] 77 78 79 80 81 82 83 ... 129
1126
不要总想着惩罚爆仓者,爆仓不是作恶。
如果说,在没有设置目标抵押率功能的岁月里,大的爆仓单会形成巨大的价格向下的驱动力,如今目标抵押率被广泛使用的场景下,爆仓形成的卖压已经没那么可怕。
用盘剥爆仓者来积累系统资金的想法是邪恶的。

1127
今天的新的喂价想法,我实在无法理解和支持。

“一般来说只要喂价小于DEX价格*MSSR,那么爆仓单的价格就会小于DEX价格,可以保证被吃掉。
当前MSSR = 1.1, 也就是说喂价高于内盘价格10%的范围内都是很安全的,再加一点安全边际,取9%,”
本来我觉得调整喂价就不如修改MSSR,比如把MSSR直接改为5%,或者把MSSR设置为一个可以动态改变的参数等,但是或许修改MSSR需要硬分叉等,所以大家都迫切希望快速的修改喂价。结果现在却要用这个未曾修改的MSSR来反推一个喂价,实在无法理解,就像您说的要去9%,不如直接把MSSR修改为1%得了。

“if 4.5%<premium, feed price = Pdex*(1+2*premium)”
关于这里,更加让人失望,前几天您举例的喂价公式,还有个limit=10%作为限制,所以我觉得至少可控,现在的公式已经跳出这个限制了。要是premium = 10%,反馈银子都20%了。

而且前几天宣传调整喂价时候,支持者口口声声说可以把溢价调整为0,现在刚刚实行了一天,就出来新想法,感觉支持调整喂价的想法是不是太草率了?

新想法拿出来讨论而已,算法肯定需要不断迭代,有什么好吃惊的?

修改MSSR的效果非常有限,起不到负反馈的作用。

增加个20%有什么稀奇的吗?前几天的limit=10%是在市场价的基础上加的,如果溢价10%,那在limit=10%的限制之内喂价就已经比内盘价高20%了。


1128
新想到的喂价算法:

既然调整喂价算法的初衷是在bitCNY遭遇紧缩时做宽松,那么就应该仔细想一下在可接受的安全范围内可以做到怎样的宽松。

“安全”的一个标准,还是比较保守的标准,是爆仓单可以及时被吃掉。不至于积累风险。

一般来说只要喂价小于DEX价格*MSSR,那么爆仓单的价格就会小于DEX价格,可以保证被吃掉。

当前MSSR = 1.1, 也就是说喂价高于内盘价格10%的范围内都是很安全的,再加一点安全边际,取9%,

当前时刻的喂价比DEX价格高大约4%,在足够的安全范围内还有5%可扩张的空间。

一般来说,当溢价大于2%时,就已经是比较严重的紧缩,就可以考虑取“比DEX价格高9%”这样一个喂法。

当溢价小于2%时,可以取相对保守一点的喂法,比如市场价+溢价调整这样的。

当溢价大于4.5%时,按市场价+溢价调整的喂法就会比DEX价格高9%以上,这时取市场价+溢价调整喂法。

当溢价从2%以上降到以下时,喂价的降低要平滑,不能突然降低。

细化:
令Pdex = 内盘BTS的bitCNY价格,premium = 溢价。

if premium <1%, feed price = Pdex*(1+2*premium)

if 1%<premium<2%, feed price = Pdex*(95%+7*premium)

if 2%<premium<4.5%, feed price =Pdex*(1+9%)

if 4.5%<premium, feed price = Pdex*(1+2*premium)

1129
MSSR是惩罚,为了锚定安全设置的手段,不是目的,但目前爆仓惩罚的对象是爆仓单,更是重重惩罚了全体利益的币价,这是导致MSSR不能简单提高的根源;律例严明与自由宽松并不矛盾,如果大部分抵押者愿意选择承受爆仓惩罚而非规避,那爆仓设计难以谈得上成功。

爆仓规则的核心目的是释放风险,至于抵押者如何选择与其是否成功没有直接关系。


1130
Stakeholder Proposals / Re: [Witness Proposal] gdex-witnness
« on: August 28, 2018, 06:09:01 am »
gdex-witness now adopt a new algorithm to feed bitCNY price, the new algorithm is based on BSIP42.

1.get a market price in fiat CNY which is the max from referenced exchange.
market price = max(Pdex, Pcex1,Pcex2...)
2.calculate the bitCNY premium in percent from BTS price difference between DEX and CEX, and the deposit fee in magicwallet.
3.set a limit to restrict the max percent for adjusting the feed price, initially let limit=10%
feed price = market price*[1+min(premium, limit)]

we understand that although BSIP42 worker proposal is active, we need more time for community to review and decide. we now begin to adopt the new algorithm is to do some experiment, to do some controllable change to show the result to the public and help the voters to decide whether to support this kind of change. if finally the BSIP42 is rejected, we'll return to the old feed algorithm immediately.

any comments on the new algorithm are welcome.

1131
Stakeholder Proposals / Re: [Poll] BSIP42: adjust price feed dynamically
« on: August 28, 2018, 06:05:09 am »
Appreciate the answer. My point is on the formalities though, not the content of the BSIP.

we give 2 weeks for community to review the BSIP and vote, in 7th Sep if the worker proposal is active and the votes is greater than that of the oppose worker proposal, then the BSIP is accepted.

1132
Stakeholder Proposals / Re: [Poll] BSIP42: adjust price feed dynamically
« on: August 28, 2018, 05:29:23 am »
As it stands right now, the worker proposal has no definition when it will become active, nor is it complete. No one should vote for it. But it seems with 400 million and more votes, it will be done. I strongly disagree that proper formalities were skipped, simply because our whales want to push it through.

I do like your suggestion to have it in a constantly evaluated stage. The BSIP is considered accepted, if the proposal is active AND carries more votes than the against proposal (one vote more is enough).

My suggestion:

a) Finish the proposal by including the discussion and shareholder summary. Also include an exact definition when it is considered active. This should be done by @abit or @bitcrab as the driving force behind it
b) Once the BSIP is completed, give at least 1 week grace period so shareholders can vote for or against it (the date when it can earliest become active should be included in the BSIP as well)

My personal opinion:
As the proposal stands right now I can not vote for it for formal reason, completely independent of the content. I would be rather forced to vote for "status quo" until the formalities are reinstated. Currently, everyone is swayed by the mere overwhelming power that bitcrab carries, yet I want to see that even he upholds formal procedure. This is crucial for me, as it only empowers the power abuse discussion involving our whales.

BSIP42 can be regarded as a request to community to permit witnesses to try some new way of feeding.

the core idea in the BSIP42 is "negative feed back feed price" based on the premium/discount of smartcoin, however, no detailed specification are provided, because I think it may be not a good way for abit or me to provide a detailed algorithm and ask the witnesses to adopt, discussion are on going and we keep on suggesting, but I think finally witnesses will develop different algorithms to feed price based on their own understanding. this diversity is also essential for decentralization.

I will try to add more discussion to the BSIP later.


1133
General Discussion / Re: Consider derailing feed price
« on: August 28, 2018, 02:54:13 am »
        The goal is to kill this premium.   When there is no premium, I think settlement offset can be set to zero.

no, you haven't considered the scenario that smartcoin has discount.

example: when BTS's price is 5bitCNY in DEX, however, bitCNY has 2% discount and because of the negative feedback, the feed price is 4.8.   what will happen if you set settlement offset to 0?

1134
不可能提升MSSR,降还来不及呢。

拉盘操纵带不来象连环爆仓那样的灾害,何况通常程序在取最高价的过程中通常都有价格防火墙剔除掉异常高价,而且价格高的时候基本bitCNY溢价已经很低甚至变为负了。

当然,最高法产生市场价格只是一种建议,也未经过BSIP投票形成社区强共识,是否采用看见证人的选择,但我认为在消除做空动力方面还是很有意义。


1135

1. 最高价法中是否包含 内盘价格+手续费率?假设此时内盘价格+手续费率为最高

2. 如果鼓鼓充值手续费率为5%,而内外价差为0%,取最高者?鼓鼓充值手续费为5%,内外盘价格差为趋于零的情况又不是没有。

3. feed price = market price*[1+min(premium, limit)],

按照1.2.的假设条件(这种假设条件情况肯定会发生),喂价=内盘价格 × (1+5%)  ×(1+5%) ?

而且喂价作为指导价,已经与实际的bts价格失真,也就导致抵押出的bitcny与法币的锚定也失真,外盘及内盘市场买单万一不买账,外盘持续砸盘情况,内盘买单不吃爆仓单,是否加大失真度及更大概率的黑天鹅或者锚定的失效?


另外,想问的是为什么抛弃更改MSSR的方案及最高价法的方案?是为了宽松抵押条件?宽松抵押条件之后带来是更大更明确的贴线抵押获利行为,或者你认为这不是什么问题,但是这种贴线抵押恰恰是内盘价格崩盘的前期主要推手。
 
还有,为什么要用反馈因子将bitcny与法币进行1:1强行锚定(这样与CNC或者QC是否有本质区别),而不是采用法币入口的费率并调节MSSR来进行市场锚定?

只要市场是通畅的,内外盘价差和充值费率就是趋向一致的,短暂的不一致产生不了什么大影响。

我已说过很多次,前面也有具体推演,熊市时喂价高于市场价就是一种宽松行为,一定程度上确实提高了一点黑天鹅的风险,但是带来的积极作用很大。

贴现抵押不是包赚不赔的,也同样有风险,在引入目标抵押率之后这种行为带来的影响已经很小,而且客观上提供了更多的流动性,不要再拿这个来说事儿。

加了反馈因子依然有抵押,依然有爆仓有黑天鹅,怎么就是强行锚定?市场不认可的话,大可以降低对bitCNY的认可度,让溢价下来,反馈修正自然就下来了。

只改MSSR能起到的作用太小,所以先尝试负反馈。

负反馈的核心作用是让市场对bitCNY的需求传导成为BTS价格上涨的动力。

改革的步子要大一点,不能总象小脚女人一样。






1136
   当充值费一直5%,说明内盘bts/bitcny和外盘bts/qc的价差约5%,这样的调整不会资不抵债。

我们的MCR现在1.75,不会因为放水了5%就资不抵债。因为1.75-0.05=1.7,也就是说喂价上调5%,那么我们的背书还有1.7倍的BTS资产的保证。仔细分析。
理论上喂价最大上调可以是75%,也就是说这是个临界点。但是如果我们上调80%,难道就会崩盘么,我认为也不一定。
我没有说因为放水5%而资不抵债,你说如果手续费一直5%就会一直上调喂价,我说这样会造成资不抵债。那样的话,怕是喂价上调了75%以上了,手续费还是5%。
我想abit和巨蟹不会是这么想的,我希望两位大神出来说一下子这个问题,到底是会一直提升喂价呢?还是到了上限就停止。

关于负反馈喂价法会带来哪些好处以及怎样的风险,以及为什么不选择调MCR而是选择调喂价,前面的回帖里都说得很清楚了,不再赘述。

至于采用什么样的负反馈算法,要依赖于广大见证人的智慧。

我设想在投票通过后gdex.witness将采用的算法。

1.用最高法计算出当前市场价格:
market price = max(Pdex, Pcex1,Pcex2...)
2.根据鼓鼓上的充值手续费,以及内外盘差价得出bitCNY的溢价百分比premium。
3.给调价设一个上限limit,溢价多少比例,就将市场价上调多少比例,但最高比例不超过limit的限制。
feed price = market price*[1+min(premium, limit)]
开始limit设多少合适呢?反正最高不超过10%吧。

当然,用PID算法的角度讲,这种最简单的算法只是考虑了误差的比例(P),没考虑误差的积累(I)和误差的变化速度(D)。 效果如何有待观察,算法也需要不断迭代。

1137
SPRING management team is considering to vote BSIP42 worker. https://github.com/bitshares/bsips/blob/master/bsip-0042.md

BSIP42 is suggested by abit, it introduce the new idea of "negative feedback feed price" to get more accurate pegging of smartcoin, we believe this will help the whole ecosystem, and also SPRING to grow.

if SPRING holders have any thoughts on this plan, please comment here.




1138
中文 (Chinese) / Re: 【投票】见证人是否动态调整喂价
« on: August 25, 2018, 03:22:03 pm »
用动态调整MCR的方法实现负反馈有技术上的障碍需要解决:https://bitsharestalk.org/index.php?topic=26496.msg318791#msg318791

1139
中文 (Chinese) / Re: 【投票】见证人是否动态调整喂价
« on: August 25, 2018, 09:26:16 am »
喂价应该真实反应市场价格,一般人多是法币本位进行买卖,喂价对应的也是法币本位,而不应是bitCNY本位(虽说是锚定1:1,但实际有可能不是1:1)。不能因为bitCNY的溢价问题而“修改”喂价,但如果计算喂价来源于bitCNY的那部分,那么应将"汇率"(承兑商bitCNY出入金手续费差扣除承兑商利澜)考虑进去。这同样也应注意波动的USDT“汇率”(不是USD)问题进行修正。同理包括其它不稳定计价的交易对来计算喂价的情况。或者说要做的是怎么让这个溢价尽可能的小让锚定尽可能的接近1:1这个问题。
另:关于提高喂价促进bitCNY供应量的问题。bitCNY的供应量主要是生产者的生产意愿是否有利可图,而不是喂价(虽说喂价高bitCNY的可以生产的量就多,但如果没有生产的利益驱动,多高也没人去生产况且还有暴仓等其它风险)
从投资角度上讲想你要买的BTS价格上涨,要做的是促进对BTS的需求而不是bitCNY的需求。对bitCNY的需求并不能促进BTS价格的上涨(这个需求只会促进bitCNY价格的上涨)。对BTS的需求设计几句话也讲不清这里就暂时不讲了。

没有什么一定应该怎样的。

长期以来,BTS是多空博弈的乐园,经常上演各种牛逼或惨烈的情节,一些牛逼的市场玩家也时常能挣很多钱。

但如果仅仅满足于成为一个好玩的平台,BTS就永远长不大,智能货币也永远成为不了主流的稳定币,仅仅作为一个去中心化交易所,BTS也绽放不出来多少光芒。

BM曾说他寄托在BTS上的梦想是解放金融奴隶,我则希望BTS能成为世界央行。

摆在眼前的问题:一遇到熊市bitCNY就严重通缩,作为货币几乎难以为继。

都根本没法责怪bigONE和AEX下架bitCNY市场,因为严重通缩带来的体验实在是太差了。

连我自己都不得不在给别人付款时改变约定,改付人民币。



分析原因,可以认为是整套机制太僵化,在bitCNY严重通缩,溢价严重,BTS超跌的时候依然要求严格的抵押。

结果就是熊市时对bitCNY的挤出效应继续构成BTS价格下跌的压力。

解决bitCNY严重通缩,溢价严重问题的途径就是放松抵押条件,释放出更多的bitCNY。

如果牛市时遭遇bitCNY供应过量,打折严重,那么相应的做法就是让抵押条件更严格,减少bitCNY供应。

这就是负反馈的逻辑基础。BTS一直苦于对智能货币的需求不能有效转化为BTS的价格驱动力,负反馈是寻求这种转化的一种尝试。

其实实现这种负反馈至少有两种途径,一种是根据溢价调节MCR,一种是根据溢价调节喂价。

调节MCR其实更直观,从MCR的当前值就可以清晰了解到现在“BTS央行”的“货币政策”是紧缩还是宽松。

如果允许MCR<1会怎样?

按当前的逻辑,抵押率小于1就意味着资不抵债,意味着黑天鹅。

但bitCNY的价值真的完全来自于后面作为抵押物的BTS吗?

就好比,当初布雷顿森林体系确定美元是金本位的,美元的价值来自于美联储的黄金储备,美元与黄金挂钩,各国货币与美元挂钩。但到了1972年,美联储发现金本位无法维持下去,于是尼克松宣布美元与黄金脱钩。

之后美元开启了对黄金的长期通胀,但依赖于美国强大的经济,美元依然是当今世界最受信任的货币。

我并不是在建议去除bitCNY机制中BTS的抵押,也并不建议允许MCR可以小于1,我只是想说,在bitCNY严重通缩,溢价严重的时候是完全可以而且应该放松抵押条件的。

可惜,动态调节MCR有一些技术上的障碍,与之相比,喂价本来就是动态调节的,现在只需要在计算上加入负反馈的算法,技术上没有障碍,而缺点是不太直观,而且相当于要改变BTS社区长期以来“喂价就该反映真实市场价格“的共识,不是特别容易接受。

但改变是必需的。




1140
中文 (Chinese) / Re: 【投票】见证人是否动态调整喂价
« on: August 25, 2018, 05:34:29 am »
标题有点不合适,因为见证人本来就在“动态”地调整喂价,叫“见证人是否采用负反馈原则动态调整喂价”更准确。

见证人用什么算法不是自己决定的么?不用改代码吧,为什么要发起投票呢?

发起投票是寻求社区共识的过程。

很显然,改成负反馈算法是需要社区强共识的,因为这等于是改变了以往的“喂价需要反应真实市场价格”的共识。

如果见证人在社区达成强共识之前就这样做,是有可能被认为是违反已有共识,失去投票者支持的。

Pages: 1 ... 69 70 71 72 73 74 75 [76] 77 78 79 80 81 82 83 ... 129