Main > 中文 (Chinese)

BTS下一个版本修改点征集

<< < (8/9) > >>

ebit:
你这个相当于给账户加个防火墙,如果哪天自己忘了这个事,要求别人的付款就可能丢失。
你说的这种功能,也可以通过自动生成新多签账户来实现。转账双方先朝多签账户打款,条件成立了再到收款方。和智能合约的红包或支票差不多。
也就是给比特股加一个虚拟机。
dacplay做的那种就行。


--- Quote from: btsw on July 04, 2018, 06:09:45 pm ---增加转账说明备注.这样子 该条账目的用处,明确地记录在案, 双方谁有都能清楚知道资金的具体情况,无法赖账.
当然  转账时 可自行选择 是否增加转账备注说明
增加转账备注说明需要增加费用. 

补充一条, 增加转账备注说明,  可再扩充 成,  增加转账备注说明后转账,  转账资金会进入 系统特定管理池中, 由接收方确认是否要接收这笔资金. (接收资金同时代表着同意认可备注说明的事项)   这样子就可以发展成类似 合同确认的选项.    (虽然接收方可以收完资金,不认账.)

--- End quote ---

ebit:
押金是个思路,但你的实现方法不行。因为死亡资产也可能有很多持有人。如果删除,不给持有人补偿,那就是系统作恶。系统提供公平环境就行,不能有洁癖。



--- Quote from: binggo on July 04, 2018, 12:02:53 pm ---BTS个人或网关发行资产系统收取循环激活押金.

我认为可以对个人及网关发行的资产收取每年固定的管理激活费用或押金, 发行时支付1年的费用, 到第二年存入第二笔费用的时候, 系统将第一笔费用返还,以此反复,作为资产固定激活的方式来防止系统内的死亡资产过多,没有续费的资产停盘处理, 连续几年比如5年都没有续费激活的资产进行删除。

自行删除的退还押金。

系统删除的黑掉押金。

原链: https://bitsharestalk.org/index.php?topic=26767.0

--- End quote ---

btsw:
增加转账说明备注.这样子 该条账目的用处,明确地记录在案, 双方谁有都能清楚知道资金的具体情况,无法赖账.
当然  转账时 可自行选择 是否增加转账备注说明
增加转账备注说明需要增加费用. 

补充一条, 增加转账备注说明,  可再扩充 成,  增加转账备注说明后转账,  转账资金会进入 系统特定管理池中, 由接收方确认是否要接收这笔资金. (接收资金同时代表着同意认可备注说明的事项)   这样子就可以发展成类似 合同确认的选项.    (虽然接收方可以收完资金,不认账.)

binggo:
1. 爆仓单收手续费(收取的手续费用于各种锚定资产的黑天鹅预防基金, 最大程度上消除黑天鹅及连环黑天鹅); 思路汇集来自论坛各成员

    收取爆仓者爆仓单的交易手续费,最少收取5%或更高,可以设置为一个可调参数K, 当然, 是收取锚定资产还是BTS需要讨论一下.

    BITCNY区最大抵押高点产生6亿多BITCNY, 现在1.5亿多,收取5%, 外加各种反复爆仓, 至少收取有近3000万的BITCNY或者对等价值的bts.  7月份升级后,消除黑天鹅用这些资金完全够.

    当有爆仓单处于120%或115%时(当然也不一定是这个参数,也可以是130%或其它), 黑天鹅基金自动吃掉或背负其部分债仓使其脱离爆仓状态,  此方法还能提供相当的锚定资产供应量, 一定程度上优于公开市场操作计划, 甚至替换掉公开市场操作计划,然后公开市场操作计划中的锚定资产区收取的手续费可以支付工人工资。

    而且每个锚定资产都有相应的爆仓手续费可收, 可用于其对应的黑天鹅预防基金, 不需要其它公共资金或个人资金来参与, 锚定资产黑天鹅出现的概率会大大降低, 甚至可以消除.

    当然需要设计成自动化吃单或背负债仓操作。

    这样的话连环爆仓也能回补系统,而不是单单的伤害系统,降低或者消除掉黑天鹅风险对抵押者也是最大的保护。

    如果到时候黑天鹅基金规模扩大的话,也可以拿出其中2%支付工人提案工资。

2. 爆仓惩罚MSQR比例调整的问题(因为其与入金手续费紧密相关);

    爆仓单主动吃或者被动吃分几个阶段:
    第一:市场情绪火热阶段,爆仓单会被主动吃掉;
    第二:市场情绪稳定阶段,爆仓单会被主动吃掉;
    第三:  市场情绪不稳定阶段,被动吃爆仓单,反弹时也会主动吃爆仓单;内盘价格被爆仓价格压制。
    第四:市场情绪崩溃或低落阶段,没人吃爆仓单,反弹时偶尔会吃到爆仓单。内盘价格被爆仓价格压制。

    so,/110%的爆仓惩罚MSQR覆盖并不是处理爆仓单的最好方式,对有效成交也起不到主要作用,更多的是压榨市场深度, 只是对深度不好的交易对有微弱的作用而已,而且还有很大的一个负面作用,迅速摧毁市场深度,任何一个市场也经不起连续10%的砸盘力度,哪怕是7月份升级之后,连续性的价格下滑,也会形成爆仓单无人吃的局面,而且并不能延缓黑天鹅的到来的速度, 大量机器人的套利行为也会将其与深度好的交易对搬平。

     所以,请各位见证人考虑一下至少调整爆仓惩罚MSQR至/105%,来降低内盘被爆仓单压制时的入金手续费,在市场下行时,bitcny供应量并不是入金手续费的决定性因素, 公开市场操作计划提供的量对手续费的影响也是微乎其微.

          降低爆仓惩罚,可以让内盘市场价格更快恢复到正常状态,而不是内盘所有锚定资产交易对的价格长时间被爆仓价格压制。

插图更便于理解, 来自  https://bitsharestalk.org/index.php?topic=26764.0:


加个解释就好理解,图比较简化,箭头所指代表受谁影响。

当然如果不是长期跟踪 爆仓单情况——内外盘价格差——承兑商出入金手续费——出入金手续费差(承兑商竞争关系)——其它入金手段——内外盘搬砖从承兑商手中套利,这几个之间的相互关系,是会陷入BITCNY供应量决定入金手续费的怪圈,因为锚定资产最初的发展阶段,BITCNY的供应量量决定手续费给所有人形成了固定思维。

    拿第三阶段来说事情,正常步骤:
    第一步:内盘价格被爆仓单压制,内外盘价格相差10%左右(强制平仓价格),内盘搬砖人将内盘BTS搬到外盘(比如中比特)砸盘,用QC提现;
    第二步:从鼓鼓承兑商处兑换BITCNY进入内盘,如果此时鼓鼓承兑商的手续费还是2%左右,内盘可多买7%左右的BTS,提到外盘可赚取近7%利润;
    第三步:重复第一步;
    第四步:重复第二步;
    第五步:外盘喂价不断被以上步骤砸低,内盘爆仓单继续增加,强制平仓价格进一步下降,而爆仓单是吃不完的;
    第六步:各种重复。
   
    第三阶段变种:内盘持有BITCNY的用户,两种获利方式,一是从承兑商处赚取出金手续费,如果承兑商出金手续费是1%左右而不是补贴到9%左右,BITCNY持有人是不会傻到从承兑商手里提现的,只会采取第二种方式,二是从内盘买BTS,去外盘砸盘提现,助力砸喂价;然后重复第三阶段的正常步骤。

  如果你是一名正直的承兑商,你会怎么处理?是不是还会继续维持这个入金手续费?!你的BITCNY够不够?如果足够的话,会发生什么情况?会把内盘的爆仓单吃掉?!还是内盘情况继续恶化?!

   如果你是一名奸诈的承兑商,你会如何处理?会不会去搬砖套利?

   so,这个爆仓惩罚是否是一个合理性的参数?!还是等再来几次血的教训,才意识到这个问题?!



3. 强清补偿按照抵押率进行补偿问题(强清可以更大发挥其作用,更有效的调节抵押杠杆);

      巨蟹假设的强清补偿率公式:(ratio-MCR)*0.04
             同时需要设置一个最低及最高补偿限制, 防止补偿溢出.
             如果可以的话, 可以调整一下强清时间为6小时或者12小时, 强清量也调高一点.

     个人看法:(ratio-MCR)×K(K为浮动系数)好像更好一些,有更大的灵活性.
                  系数是0.04时,补偿率为4的抵押率为275
                  系数是0.05时,补偿率为4的抵押率为255
                  系数是0.06时,补偿率为4的抵押率为240

4. 抵押率分开的问题: 分为基础抵押率(比如185%)与爆仓抵押率(比如175%);(预防价格有点波动就爆的问题,我这里针对的就是贴线抵押。)


其中第1项与第2项结合起来,与原来的惩罚系数是一样的,抵押者并没有受到不公平待遇,对中间及后面爆仓的抵押者也相对公平。而且两者必须同时用,

个人看法,如果可以的话,这几项越快形成提案越快完成升级越好,现在不尝试理解,等再来几次血的教训再改,那时候就都凉凉了。
原链: https://bitsharestalk.org/index.php?topic=26776.0

binggo:
BTS个人或网关发行资产系统收取循环激活押金.

我认为可以对个人及网关发行的资产收取每年固定的管理激活费用或押金, 发行时支付1年的费用, 到第二年存入第二笔费用的时候, 系统将第一笔费用返还,以此反复,作为资产固定激活的方式来防止系统内的死亡资产过多,没有续费的资产停盘处理, 连续几年比如5年都没有续费激活的资产进行删除。

自行删除的退还押金。

系统删除的黑掉押金。

原链: https://bitsharestalk.org/index.php?topic=26767.0

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version