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 ... 11
1
中文(Chinese) / 回顾2014-2016,看看现在
« on: September 08, 2019, 11:26:10 am »
看看现在的情况,和2016年BM出走前后的情况,何其相似。

2014年7月,BTS 0.x 上线,价格涨到3毛。按 BTS 0.x 版权协议,所有 fork 需要空投给 BTS 社区。
BM用3i公司BTC全仓买入BTS。之后价格一直跌,BM被套,开发资金吃紧。
期间,为了开发资金,改革受托人收益机制,提高每块收益。很多人因此申请多个受托人,混水摸鱼。
后来发生增发合并 VOTE、DNS、PTS 的事件。
3i公司尚有部分余资支付开发,撑到2014年底,撑不住了。

2014年-2015年,出于愿景,社区若干项目基于 BTS 0.x 架构启动。国内的比如Play,暴走的DACx,咕噜的承兑平台等等。国外的有Muse,月石,手机钱包项目等等。
也有不少宣传活动。
社区热议抵押机制缺陷、改进思路。

2015年,BM放弃 BTS 0.x,自己垫资开发石墨烯,走自己的路,但社区大部分人不知道。

2015年10月,BTS 2.0 上线。价格跌到2分。石墨烯版权归3i重组公司 CryptoNomex 完全所有, BTS 有权无偿使用 。其他项目使用需要向 CN 购买版权。
2.0上线导致DACx、月石等社区项目被埋,因为不兼容。
社区热议开发方向。Stealth,Maker/Taker,Bond,百分比手续费,免费交易等等。
BM资金仍然吃紧。
石墨烯引进了 worker 机制, BM尝试通过 worker 向社区继续筹资做开发,同时尝试其他筹资方式。
BM 申请了做维护改BUG的 worker ,领了一两个月工资。后来并没有申请新的开发 worker。

2015年底-2016年初,社区陆续出现新的项目。
原 0.x 浏览器开发者 svk 加入BM团队,负责 ui 开发,申请了 worker。
新 CryptoFresh 浏览器开发者 roadscape 申请了 worker ,承诺拿到足够资金后开源。
社区提出百分比手续费功能开发, abit 承接开发,申请了 worker 。
blocktrades 申请了 worker 参与核心代码维护。
CN员工 theoreticalbts 自己申请了worker,参与核心代码维护。
BM没有申请worker,但是招了新人,参与底层开发,做了几个新的api,没有领工资。
BitCash项目自己筹资启动,包含简易版手机钱包。

隐私转账(Stealth)功能,因为第三方提供资金,只申请了个投票 worker ,最终底层代码引入FBA机制,手续费永久分成给STEALTH币持有者。至今,关于隐私转账的开发分歧一直存在,部分社区成员认为应该继续开发,部分人认为应该由STEALTH币负责开发。

2016年初, alt 认为低价卖BTS不合适,组织大家投 refund 。另一个原因是 BM 没有按大家期望的路线图去做开发。
2016年3-4月, 巨蟹开始支持 refund , 达到高票。几个社区 worker 不再有注资。
浏览器开发停滞,一直没有开源。百分比手续费功能搁置。ui开发逐渐中止。

这些好像都被BM预见到了。
2016年1月开始,BM组建Steemit公司,带着新人开发Steem,并没有参与BTS开发。
期间,BM陆续卖出BTS。
石墨烯版权变成 MIT。
2016年3月,Steem上线,BM带领一部分支持者参与了早期挖矿,有  svk blocktrades cass  等。
2016年4月初,BM用小号到BTS论坛宣传Steem,拉人。
之前在 BTS 社区有 worker 的人,关注重心全都转向了 Steem 。
Steem用了石墨烯技术,并没有给BTS空投,虽然一部分人在Steem赚到了钱,回馈了BTS。

2016年整年,BTS价格低迷,小幅波动。
2017年,BTS价格爆发,后来回落,经历94爆跌后,再次爆发,年底价格到达顶点。
2018年,震荡下跌,年底到达低点。
2019年,震荡横盘。

社区依然热议抵押机制缺陷,讨论改进思路。
巨蟹再次开始支持refund,大部分 worker 不再有注资。
BM 已经不在,不会发生突然的底层大改。
其他开发者?
价格?

2
中文(Chinese) / 布朗博士关于bitAsset的第一篇研究报告
« on: August 02, 2019, 11:11:50 pm »
报告已经出来一篇, worker 还没有通过。

https://bitsharestalk.org/index.php?topic=28823

感兴趣的看看。

3
General Discussion / Allow non-LTM accounts to be referrers?
« on: August 02, 2019, 01:26:45 pm »
https://github.com/bitshares/bsips/issues/186

Quote
Currently only LTMs can be referrers. This caused a problem that in order to earn money, you need to invest some money first, IMHO this drives away potential marketers E.G. small bloggers.

This BSIP proposes a protocol change to allow non-LTM accounts to refer new accounts. The referral income that a non-LTM referrer earned will be split to herself, her registrar and her referrer. If she upgrades to LTM, her future referral income will be kept by herself.

Risks:
This change will potentially turn the referral program into a MLM scheme, which could be illegal in some jurisdictions (I am not a lawyer, please correct me if I'm wrong), although every account has the option to upgrade to LTM to stop sharing new referral income to the registrar and referrer.

5
中文(Chinese) / HTLC原子跨链应用场景
« on: May 15, 2019, 09:47:35 am »
我想到的唯一场景是 bitCNY 和比如 QC 这种接近 1:1 跨链直接兑换,由于价格波动不大,对交易效率的要求不太高,因而才能做大。

为什么用BITCNY换BTC这种主流币直接跨链交易不适合HTLC?因为HTLC跨链交易效率太低,比利用IOU挂单交易低多多多多了。
机会成本也是成本,时间也是成本。
IOU虽然有信任风险,但毕竟现在这个风险还是相对小。
也就是说,交易者在追求效率时,会一定程度容忍风险。
即使是bitcny换QC,目前效率最高的路仍然是IOU,也就是充到ZB去挂单交易,因为QC只有ZB一个使用场景。


这里qc只是例子。
原子跨链兑换的需求基础是,两个资产都有内在价值,兑换者不希望冒第三方风险。
如果BTC换GDEX.BTC,这个需求基础就会打折扣,因为持有 GDEX.BTC 等于要相信 GDEX ,何必用HTLC?
同样的,如果QC是需要信任发行人的,那基础也打折扣。
USDT同理。当然,用户基数大,盘子大,使用面广,接受的人多,风险小,基础就厚一点,就可以考虑用HTLC来进一步降低风险。


目前市面上我能想到的只有DAI。
可能还有EOS上的算法稳定币。
steem dollar如果锚的准一点也可以算。

兑换也是交易,需要双方有兑换需求,才有市场。
也就是说,一方需要 bitcny 但手里只有 QC,一方需要 QC 但手里只有 bitcny,双方兑换后各取所需,才能产生价值。
那么,bitcny和qc各自有什么用?别人凭什么要来换?反过来问,你为什么要换?
这是发展生态需要考虑的问题。
发展空间的问题,做不做得大的问题。

如果bitcny只能用来买BTS,用途有限,那么需求就有限。
QC只有充到ZB变成IOU一条路,那用HTLC意义就小。
DAI如果留在ETH链上就好用,而不是只能充到hitbtc变成IOU,那就有更大意义。

当然,目前环境如此,IOU普遍存在,要发展各个币的链上用途,还有很长路要走。
从这个角度, EOS 走的路是对的,更关注链上生态。
而我们很多时候仍然是在走先发展IOU的路,包括找交易所上 bitcny 都是在这条路上。
百城百店是在走“正路”。

跨链稳定币兑换思路,发展到后面是多种稳定币共同存在,“共赢”,而不是取代,因为取代就表示变成单向需求了,没有交易基础了。

6
中文(Chinese) / 新版重钱包 3.0.0
« on: March 27, 2019, 10:31:58 am »
https://github.com/bitshares/bitshares-core/releases/tag/3.0.0

* HTLC
* 交易手续费分成/返还
* 修复智能资产总量可能超出上限的问题
* 修复交易大小限制问题
* 修复MCR问题

升级时间4月23号14点(UTC)

7
支持票数 约 2.7亿
反对票数 约 3.2亿


https://github.com/bitshares/bsips/blob/master/bsip-0042.md

方案里是这么写的:


Constant voting evaluation
This BSIP has a pro and a con worker and has an ever evaluated state of accepted and rejected.

Accepted: The pro worker is active in terms of receiving payout from the reserve pool AND its votes surpass the con worker.

Rejected: The pro worker is NOT active (is not receiving funds from reserve pool) OR the votes of the con worker surpass the pro worker. If the pro worker expires, this BSIP is also considered rejected.

The earliest that this worker can become active is 7th September 2018.


两个worker表示两个选项,

支持的worker票数高于反对的worker,并且有收入(也就是高于refund那些),就执行负反馈调整喂价;
支持的worker票数低于反对的worker,或者支持的worker没有收入(也就是低于refund那些),或者支持的worker过期了,就不调喂价。


不过呢,没有说到票数翻转时怎么处理。


8
英文贴: https://bitsharestalk.org/index.php?topic=27449.0


总的来说,目前的黑天鹅处理方式,把所有债仓强行关闭合并成一个大池,不够好。

之前一贴( https://bitsharestalk.org/index.php?topic=27274.0 )讨论了把资不抵债的债仓单独剥离的思路。

这贴讨论的思路是:完全不剥离。



灵感来自Steem:
Steem Dollar可以按喂价加一个延迟转换成STEEM,但是,当Steem Dollar当前供应量超过STEEM总市值(由喂价计算出)的10%时,转换不再按喂价,而是固定按市值*10%计算出的价。


对应到BTS里面,那就是:
当要发生黑天鹅时,不触发全局清算,而是系统接管喂价,将爆仓成交价设置成黑天鹅价,不再下降。


这样做的结果:
1. BTS价降到黑天鹅价,出现实质脱锚。这点与全局清算没有区别。

2. 所有债仓仍然维持在原账号,维持整个抵押生态的去中心化。
2.1 债仓持有人可以增加抵押或者降低负债,从而提高抵押率,结果是马上脱离黑天鹅状态,重新锚定;
2.2 其他人可以在抵押足够多的前提下,新借款来吃爆仓单

3. 爆仓单可以直接在市场上被吃,吃单价和全局清算后的强清一样,没有区别;
3.1 如果有卖单价低于爆仓单,卖单会先成交

4. 当最低抵押率的仓位被吃完,或者增加抵押率之后,如果下一个仓位抵押率足够高,系统马上会脱离黑天鹅状态
4.1 如果下一个仓位抵押率不够高,则仍然在黑天鹅状态,即使如此,下个仓的抵押率不会更低,所以系统总体抵押率会提高

5. 当市场回暖,喂价上升,则系统自动会脱离黑天鹅状态,自动复活

6. 可能不好的一点:与全局清算相比,全局清算时,高抵押率的债仓会按黑天鹅价卖出BTS;如果用这贴的方案,如果市场继续下行,高抵押率的债仓可能会更低价卖出BTS,也就是“晚爆不如早爆”。


需要同时考虑的问题:
1. 如果保留强清功能,则强清价也要同时设下限
2. 当强清价高于市价时,为保证不出现过度抵押,“实质MCR”应该不变,也就是说公式里用来计算的MCR可能需要上调。


与单独剥离坏账的思路比较:

1. 单独剥离坏账,剥离后喂价可以继续下调,使锚定继续保持一定空间。
这个方案和全局清算一样,会在黑天鹅价出现脱锚。

2. 单独剥离坏账,会出现不公平的情况,即高抵押率的仓位按更低价爆。
这个方案则比较公平。


讨论一下?


顺便说下,虽然这个方案需要硬分叉升级,但是,如果现在见证人控制喂价不触发全局清算,可以起到和这个方案类似的效果。



9
The Steem approach:
* witnesses publish price feed of STEEM in $ (like BTS/BitUSD);
* under normal conditions, Steem Dollar holders can convert their Steem Dollars to STEEM at median feed price with a delay (like force-settlements in BitShares);
* when median feed ($ per STEEM) is so low that total amount of existing Steem Dollar (current SBD supply) is more than 10% of the whole STEEM market cap (which is median price feed * current STEEM supply), the 10% threshold is used as conversion rate. In other words, the system breaks the peg intentionally at the time.

For bitAssets in BitShares E.G. bitUSD, it's possible to adopt similar approach:
* after a new price feed is published,
  * if the median feed price ($ per BTS) is so low that would trigger a black swan event (which means median_feed / MSSR < black swan price, aka debt/collateral of the debt position with least collateral ratio), don't execute a global settlement, instead, update the margin call execution price to the black swan price;
  * if the median feed price is higher, use the median.

In short,
1. use the black swan price as a floor when matching margin calls,
2. don't trigger global settlement.


Outcomes of this approach:

* when price of collateral asset (BTS) is too low, the peg may be effectively broken, which is same as globally settled;

* the debt positions are still in the borrowers' accounts, which IMHO is the most significant benefit to the ecosystem since decentralization (decentralized borrowing / supply creation) is kept as is, in comparison to the globally-settle approach which will close all positions to form a centralized pool;
  * the borrowers who are in margin call territory can still increase collateral or reduce debt;
  * new bitAsset supply can be created (borrowed) with sufficient collateral to eat the margin calls;

* bitAsset holders can buy into the margin calls at black swan price, which is same as globally settled;
  * if there are orders selling collateral asset (BTS) with lower price, they'll get matched before the margin calls;

* after the position with least collateral ratio got bought out (completely eaten), or the debt position owner increased collateral ratio, the bitAsset may or may not be effectively revived immediately, depends on whether the next debt position has high enough collateral ratio;
  * even if not revived immediately, new black swan price and margin call execution price might move down a bit, so the peg would be more or less tighter;

* if later a new price feed caused the median feed to be higher than current black swan price, the bitAsset is effectively revived immediately.

* the down side for debt position owners: it's possible that the positions with higher collateral ratio would sell collateral at even lower price, in comparison to the globally-settle approach that all positions will get "bailed out" at black swan price.


Other things that need to be taken into consideration:

* if force-settlement is enabled on the bitAsset, the settlement price should also has the same floor;

* ideally, effective MCR should be kept at same level when margin call matching price or settlement price is higher than the real price, so people can't borrow with effectively low collateral ratio. That said, the nominal MCR used in calculation may need to be increased.


Thoughts?


IMHO this approach is better than the bad-debt-holder approach proposed in https://bitsharestalk.org/index.php?topic=27273.0

By the way, although this requires a hard fork to implement, actually similar result can be achieved by witnesses before the hard fork: witnesses are able to feed adjusted price to prevent global settlement from being triggered.

12
英文帖: https://bitsharestalk.org/index.php?topic=27273.0

坏账就是资不抵债的债仓。

出现坏账的条件是: 抵押品数量 / (喂价*MSSR) < 借款数量
(以喂价准确为前提)

当前处理方式是,一个债仓出现资不抵债,就执行全局清算,所有债仓强行关闭。

改进思路如下:

1. 系统中设立一个“坏账处理”账户,像 null-account 一样不受任何人控制

2. 出现坏账时,不触发全局清算,而是将这个坏账债仓转为一个永不过期的卖单挂在市场里,归在“坏账处理”账户名下,卖出金额等于债仓当前抵押品数量,价格等于抵押品数量/债务。当MSSR>1时,等于对债仓持有者有所惩罚。

3. 当这个卖单成交时,坏账处理账户会获得债务资产,这些资产立即销毁。


这样,所有操作都以市场挂单方式进行,很直观,交易者参与起来很方便。比当前的规则软化很多。

讨论看看?

13
General Discussion / New mechanism to handle bad debt (black swan)
« on: October 16, 2018, 11:29:00 pm »
A bad debt means value of a debt position's collateral is less than value of its debt.

Currently, when a bad debt appears in the system, no matter how small the debt is, global settlement will be triggered and ALL debt positions will be forced closed. IMHO this mechanism is flawed.

Here I propose a new mechanism to handle bad debt, the core ideas are:

1. set up a special account "bad-debt-holder" in the system, with an impossible authority like null-account, so nobody can control it
2. when a new bad debt appears, don't trigger global settlement, instead, convert that debt position to a sell order which will never expire, sells its remaining collateral for its remaining debt, under the "bad-debt-holder" account
3. if the order get filled or partially filled, destroy the (debt) asset received.

In comparison to current mechanism, this new mechanism is much "softer" and more flexible. All state will be on the order book and easy to participate for all traders.

Thoughts?


Update (2018-10-21):

1. There is an edge case which slightly affect the implementation: according to BSIP35, when a limit order is too small, it will be cancelled, otherwise will lead to "something-for-nothing" scenario which usually messes up UI. If the limit order is owned by the bad-debt-holder account, we don't like it to be cancelled, instead, we treat it like a debt position (which will overpay when filling the last Satoshi of collateral).

2. In case when the bad-debt-holder owns several bad debt limit orders for a same asset, is it better to combine the orders into one limit order and average out the selling price? I tend to say "yes", because a) it frees memory, and b) it increases the chance that all bad debts get filled, although it may lead to a larger order hanging in the market which may add psychological pressure to traders.

Do you not think that global settlement as it's currently implemented should trigger if a majority of a bitasset's supply have defaulted on their loans though? Or should the proposed mechanism operate for the full 100% of supply?

IMHO we should operate the new mechanism for the full supply (don't trigger global settlement at all). However, perhaps we can have an option for asset owners to choose when there is no supply: which mechanism she would adopt when a black swan event occurs.

I think a penalty for such undercollateralized debt position holders will help keep them more attentive to their collateral and dis-incentivize traders from operating with too little backing.

Because bad debt appears when: collateral / (feed_price*MSSR) <= debt
So if MSSR is above 1 then there will be a penalty.

Perhaps we can another parameter here to replace MSSR though.

14
中文(Chinese) / 【讨论】取消黑天鹅和强清功能的可能性
« on: September 16, 2018, 04:19:01 pm »
原贴在这里(英文): https://bitsharestalk.org/index.php?topic=27170.0
不过看来老外没什么讨论欲望,回帖的不多。

1. 黑天鹅

这个不多说了,在喂价讨论贴已经有很多讨论。

理论上说,基于 BSIP42 ,见证人保持喂价高于黑天鹅价,就不会产生黑天鹅。

不需要修改代码,但是需要见证人配合执行。


2. 强清

在 BSIP42 动态喂价基础上,强清已经没意义,甚至有反作用。

bitCNY 溢价时,强清是亏本的,所以只是摆设。但是会有小白点强清按钮,导致亏损,然后骂街。

bitCNY 贬值时, BTS/bitCNY 市场上必然出现大量高价买单,否则没有贬值基础。

此时,见证人会喂一个偏低的BTS价格,相当于变相提高 MCR 也就是抵押率要求。
那么,会导致一些仓位爆仓,特别是贴线抵押的,这些爆仓单砸向市场,会消耗掉盘面上的高价买单,促进 bitCNY 稳定。
这是

与强清相比,爆仓方式存在几个优势:
1. 没有延时,即时执行,响应很快
2. 没有总量限制,贴线抵押的可以反复抵押反复被爆,效率高。不像强清每小时清掉一部分就清不动了
3. 有BSIP38支持,爆仓时会将各个借款人都爆一点,分散风险。而强清则会按最大量去清排在第一的债仓。
4. 按市价撮合,相对公平。不像强清按(喂价+偏移)执行会导致纠纷,因为是偏移由理事会设定,调整慢。反作用主要体现在这一点。

当然,还要看流动性。

这个也不需要修改代码,只需要理事会修改一下 bitCNY 的参数,关掉强清功能即可。
同时也需要见证人配合执行 BSIP42 喂价调整方案。

顺便说一下,强清功能可以按基本固定的大量买进,但不拉高市价,本质是违反市场规律的。
一般来说,如果有大户进场买入,应该会导致市价上涨;但是如果大户用强清方式进场,对价格的拉抬作用就弱很多。

15
Stakeholder Proposals / [Poll] BSIP42: adjust price feed dynamically
« on: August 23, 2018, 11:59:12 pm »
BSIP doc: https://github.com/bitshares/bsips/blob/master/bsip-0042.md


Poll workers:

1.14.118 Poll - BSIP42 - Adjust price feed dynamically

1.14.119 Poll - BSIP42 - NO adjustment to price feed


That said, if you support the change, please vote for 1.14.118, if you don't support, please vote for 1.14.119.

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