226
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.
227
中文 (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 都是在这条路上。
百城百店是在走“正路”。
跨链稳定币兑换思路，发展到后面是多种稳定币共同存在，“共赢”，而不是取代，因为取代就表示变成单向需求了，没有交易基础了。
为什么用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 都是在这条路上。
百城百店是在走“正路”。
跨链稳定币兑换思路，发展到后面是多种稳定币共同存在，“共赢”，而不是取代，因为取代就表示变成单向需求了，没有交易基础了。
228
中文 (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）
* HTLC
* 交易手续费分成/返还
* 修复智能资产总量可能超出上限的问题
* 修复交易大小限制问题
* 修复MCR问题
升级时间4月23号14点（UTC）
229
中文 (Chinese) / 用票说话，现在BSIP42支持票数低于反对票数，见证人应该喂原价
« on: November 28, 2018, 11:05:02 am »
支持票数 约 2.7亿
反对票数 约 3.2亿
反对票数 约 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过期了，就不调喂价。
不过呢，没有说到票数翻转时怎么处理。
230
中文 (Chinese) / 【讨论】黑天鹅规则改进思路二：设置黑天鹅价为爆仓价下限
« on: November 24, 2018, 03:37:59 pm »
英文贴： 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. 单独剥离坏账，会出现不公平的情况，即高抵押率的仓位按更低价爆。
这个方案则比较公平。
讨论一下？
顺便说下，虽然这个方案需要硬分叉升级，但是，如果现在见证人控制喂价不触发全局清算，可以起到和这个方案类似的效果。
总的来说，目前的黑天鹅处理方式，把所有债仓强行关闭合并成一个大池，不够好。
之前一贴（ 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. 单独剥离坏账，会出现不公平的情况，即高抵押率的仓位按更低价爆。
这个方案则比较公平。
讨论一下？
顺便说下，虽然这个方案需要硬分叉升级，但是，如果现在见证人控制喂价不触发全局清算，可以起到和这个方案类似的效果。
231
General Discussion / Another idea to handle black swan: margin call execution price floor
« on: November 24, 2018, 03:11:18 pm »
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.
* 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.
233
General Discussion / BitShares-Core TESTNET Release test-2.0.181024
« on: October 19, 2018, 10:19:37 am »
Update: latest testnet release is https://github.com/bitshares/bitshares-core/releases/tag/test-2.0.181024
Including a fix to an elasticsearch issue and an API refactor.
-----
https://github.com/bitshares/bitshares-core/releases/tag/test-2.0.181018
https://steemit.com/bitshares/@fox/bitshares-testnet-release-test-2-0-181018
Including a fix to an elasticsearch issue and an API refactor.
-----
https://github.com/bitshares/bitshares-core/releases/tag/test-2.0.181018
https://steemit.com/bitshares/@fox/bitshares-testnet-release-test-2-0-181018
234
中文 (Chinese) / 【讨论】坏账处理（黑天鹅）规则改进思路
« on: October 17, 2018, 01:09:47 am »
英文帖： https://bitsharestalk.org/index.php?topic=27273.0
坏账就是资不抵债的债仓。
出现坏账的条件是： 抵押品数量 / （喂价*MSSR） < 借款数量
（以喂价准确为前提）
当前处理方式是，一个债仓出现资不抵债，就执行全局清算，所有债仓强行关闭。
改进思路如下：
1. 系统中设立一个“坏账处理”账户，像 null-account 一样不受任何人控制
2. 出现坏账时，不触发全局清算，而是将这个坏账债仓转为一个永不过期的卖单挂在市场里，归在“坏账处理”账户名下，卖出金额等于债仓当前抵押品数量，价格等于抵押品数量/债务。当MSSR>1时，等于对债仓持有者有所惩罚。
3. 当这个卖单成交时，坏账处理账户会获得债务资产，这些资产立即销毁。
这样，所有操作都以市场挂单方式进行，很直观，交易者参与起来很方便。比当前的规则软化很多。
讨论看看？
坏账就是资不抵债的债仓。
出现坏账的条件是： 抵押品数量 / （喂价*MSSR） < 借款数量
（以喂价准确为前提）
当前处理方式是，一个债仓出现资不抵债，就执行全局清算，所有债仓强行关闭。
改进思路如下：
1. 系统中设立一个“坏账处理”账户，像 null-account 一样不受任何人控制
2. 出现坏账时，不触发全局清算，而是将这个坏账债仓转为一个永不过期的卖单挂在市场里，归在“坏账处理”账户名下，卖出金额等于债仓当前抵押品数量，价格等于抵押品数量/债务。当MSSR>1时，等于对债仓持有者有所惩罚。
3. 当这个卖单成交时，坏账处理账户会获得债务资产，这些资产立即销毁。
这样，所有操作都以市场挂单方式进行，很直观，交易者参与起来很方便。比当前的规则软化很多。
讨论看看？
235
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.
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.
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.
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.
236
中文 (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 喂价调整方案。
顺便说一下，强清功能可以按基本固定的大量买进，但不拉高市价，本质是违反市场规律的。
一般来说，如果有大户进场买入，应该会导致市价上涨；但是如果大户用强清方式进场，对价格的拉抬作用就弱很多。
不过看来老外没什么讨论欲望，回帖的不多。
1. 黑天鹅
这个不多说了，在喂价讨论贴已经有很多讨论。
理论上说，基于 BSIP42 ，见证人保持喂价高于黑天鹅价，就不会产生黑天鹅。
不需要修改代码，但是需要见证人配合执行。
2. 强清
在 BSIP42 动态喂价基础上，强清已经没意义，甚至有反作用。
bitCNY 溢价时，强清是亏本的，所以只是摆设。但是会有小白点强清按钮，导致亏损，然后骂街。
bitCNY 贬值时， BTS/bitCNY 市场上必然出现大量高价买单，否则没有贬值基础。
此时，见证人会喂一个偏低的BTS价格，相当于变相提高 MCR 也就是抵押率要求。
那么，会导致一些仓位爆仓，特别是贴线抵押的，这些爆仓单砸向市场，会消耗掉盘面上的高价买单，促进 bitCNY 稳定。
这是
与强清相比，爆仓方式存在几个优势：
1. 没有延时，即时执行，响应很快
2. 没有总量限制，贴线抵押的可以反复抵押反复被爆，效率高。不像强清每小时清掉一部分就清不动了
3. 有BSIP38支持，爆仓时会将各个借款人都爆一点，分散风险。而强清则会按最大量去清排在第一的债仓。
4. 按市价撮合，相对公平。不像强清按（喂价+偏移）执行会导致纠纷，因为是偏移由理事会设定，调整慢。反作用主要体现在这一点。
当然，还要看流动性。
这个也不需要修改代码，只需要理事会修改一下 bitCNY 的参数，关掉强清功能即可。
同时也需要见证人配合执行 BSIP42 喂价调整方案。
顺便说一下，强清功能可以按基本固定的大量买进，但不拉高市价，本质是违反市场规律的。
一般来说，如果有大户进场买入，应该会导致市价上涨；但是如果大户用强清方式进场，对价格的拉抬作用就弱很多。
237
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.
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.
238
中文 (Chinese) / 新版重钱包 2.0.180823
« on: August 23, 2018, 11:47:43 pm »
BTS 2.0.180823 新版本已发布。
下载地址： https://github.com/bitshares/bitshares-core/releases/tag/2.0.180823
这个版本优化了很多东西，第一次启动还是会 replay 。
部分优化清单如下：
支持 Ubuntu 18.04 和 OpenSSL 1.1.0 了；
可以看到备选理事会票数了；
replay 时间降为原来的 1/3 ；
账户相关的API都支持传入账户名了（原来只能传ID）；
命令行钱包加了 quit 命令；
Elasticsearch 插件大量优化。
下载地址： https://github.com/bitshares/bitshares-core/releases/tag/2.0.180823
这个版本优化了很多东西，第一次启动还是会 replay 。
部分优化清单如下：
支持 Ubuntu 18.04 和 OpenSSL 1.1.0 了；
可以看到备选理事会票数了；
replay 时间降为原来的 1/3 ；
账户相关的API都支持传入账户名了（原来只能传ID）；
命令行钱包加了 quit 命令；
Elasticsearch 插件大量优化。
239
General Discussion / BitShares-Core Release 2.0.180823
« on: August 23, 2018, 10:06:44 pm »
https://github.com/bitshares/bitshares-core/releases/tag/2.0.180823
This is the first BitShares-Core release that supports Ubuntu 18.04 LTS. Due to the new features and improvements included in this release, all nodes are encouraged to upgrade.
## Security fixes
- CLI wallet: updated choice of range proof params in cli wallet reveals transaction magnitude to very narrow range for Blinded Transfers (issue #480 / PR #1117 #1227)
## API changes
- Removed crypto_api from default list of allowed APIs. (issue #1123 / PR #1125)
- Changed default `max-ops-per-account` value to 100, impacts account history (#1120)
- Added `get_account_limit_orders` database API to query for open orders of one account in one market #463 #849 #1163
- Added `get_asset_count` API to return total number of available assets #688, #1159
- Added `get_transaction_hex_without_sig` API get serialized transaction hex without `signatures` field (issue #1013 / PR #1038)
- Added support for account name as parameter for all API calls #969 #989 #1164 #1168 #1152 #1155
- Added `fail_reason` field to proposal object #730, #1036
- Retroactively deducted witness `missed_blocks` caused by chain halts #1087
## New features and improvements
- Added Openssl 1.1 and Ubuntu 18.04 support (issue #835 / PR #559 #921 #1008 https://github.com/bitshares/bitshares-fc/pull/7)
- Fixed invalid use of incomplete type `BIGNUM {aka struct bignum_st}` #327
- Added `witness_node` startup option `--enable-standby-votes-tracking` to track votes of standby witnesses and committee members, enabled by default #987, #1191, #1211
- Added `cli_wallet` startup option `--suggest-brain-key` to generate keys without connecting to a witness_node #1011, #1039
- Added `quit` command to `cli_wallet` #1104, #1050 https://github.com/bitshares/bitshares-fc/pull/63
- Improved witness_node performance for generating blocks, resyncing and replaying
- Improved account maintenance (vote tally) performance (issue #803/ PR #1085)
- Improved performance of `database::update_expired_feeds()` and global object getters #1093 #1180
- Slightly improved price comparison performance #1094 #1124
- Added index on `short_backing_asset`, better performance for updating asset (Issue #960 / PR #1019)
### Docker File
- Changed default docker p2p port to 1776, fixed p2p port to match Dockerfile #1226, #1078
- Fixes to make Docker containers shutdown gracefully #1077 #1115
- Fixed Docker Cloud Build Failing Due to Compile Time #1221 #1222
- Modified Dockerfile to work with new docker cloud version (0.10.1) #1075
- Updated testnet Branch to Include Latest Dockerfile #1074
### Elasticsearch
- Elasticsearch refactor #1103 #1201
- Add auth to communicate with the ES database with `--elasticsearch-basic-auth` startup option.
- Custom index names with `--elasticsearch-index-prefix` startup option.
- Removed `--elasticsearch-logs` startup option
- Better error handling: if there is an error when sending data to ElasticSearch, plugin will stop processing blocks and keep trying, and it resumes when connection is back at the same place. #681
- add operation_id_num for easier filtering.
- Fill orders data in additional for easy volume.
- Test cases framework. #1047
- Make full use of common functions in the 2 plugins(utilities).
- flush ES database on every block when node is in sync to improve real time user experience. #1137
- Increased performance of the `elasticsearch` plugin where possible: #1260
- Updated documentation https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin
## Bugfixes
- Fixed CLI `get_account_history` pagination issue (duplicate ops when `limit` great than 100) #1176, #1177, #1179
- Fixed `cli_wallet` crashes for macOS 10.13.5 #1127 https://github.com/bitshares/bitshares-fc/pull/60
- Fixed a bug related to undo database that may cause `witness_node` to crash #1247 #1257
- Fixed "log file of current hour gets overwritten by default" #809 https://github.com/bitshares/bitshares-fc/pull/56
- Fixed 2 minor bugs in snapshot plugin #1185
- Fixed object database exception handling when built with Boost 1.66 (#852 #1126 #1161)
- Enable `boost::stacktrace` correctly https://github.com/bitshares/bitshares-fc/pull/66
## Other changes
- Integrated SonarCloud into Travis build (issue #836 / PR #1081 https://github.com/bitshares/bitshares-fc/pull/49)
- Travis speedup by using ccache #1264
- Added `USE_PROFILER` option to Cmake to enable profiling #1119
- Added `OPENSSL_CONF_SOURCE` variable for building in Windows https://github.com/bitshares/bitshares-fc/pull/59
- Added cli_tests to Travis-CI #1156
- Added `asset_api_tests` #1202
- Added new seed node by bangzi #1130 #1138
- Changed default `core_exchange_rate` quote asset in order to create asset more easily #1132
- Updated node.cpp, check attacker/buggy client before updating items ids #1007
- Optimized `find()` call in P2P code #1090, #1091
- Refactored `get_impacted_account_visitor`, removed duplicate code from impacted.cpp #845 #1073
- Refactored `cancel_all_subscriptions` for better performance and consistency #762 #1009 https://github.com/bitshares/bitshares-fc/pull/50
- Changed `push_proposal exception` log level to warn #1146
- Cleaned up Balance evaluator code #1150
- Cleaned up `get_named_account_balances` code #1154 , #1135
- Cleaned up logging in account.cpp #1010
- Cleanup up a visitor struct in static_variant.hpp https://github.com/bitshares/bitshares-fc/pull/58
- Removed obsolete constants (issue #1034 / PR #1072)
- Removed unused "smaz" compression #986 https://github.com/bitshares/bitshares-fc/pull/51
- Removed unused bz2 linkage #1003 https://github.com/bitshares/bitshares-fc/pull/52
- Removed double assert in `object_id_type` constructor #1128
- Removed protocol.hpp #1197, #1200
- Backported EOS PR 3560 replace assert in FC::crypto #992 https://github.com/bitshares/bitshares-fc/pull/54
- Backported EOS PR 3240 HTTP performance improvement, added move-semantic-version `set_body` function #999 https://github.com/bitshares/websocketpp/pull/1 https://github.com/bitshares/bitshares-fc/pull/65
- Updated test case for `time_point_sec::to_iso_string`, detect boost version #597 https://github.com/bitshares/bitshares-fc/pull/67
- Fixed Performance sucks at first block after a long sequence of missed blocks #1086 #1087
- witness `missed_blocks` count no longer increases due to chain halt (retroactive change)
- Fixed cli_tests websocket port binding #1178 #1187
- Fixed RPC logging level inconsistency #929 https://github.com/bitshares/bitshares-fc/pull/62
- Fixed wallet in-code docs, suppressed compiler warnings #1015 #1181 #1129 #1199 #1190
- Updated `asset_object::amount_to_string` implementation for slightly better performance #1012
- Updated system requirements into Documents #1107 #1108
- Updated README.md document #1121, #1166, #1212
## Contributors in this release:
- @pmconrad
- @abitmore
- @oxarbitrage
- @jmjatlanta
- @cogutvalera / @nanomobile
- @cifer-lee
- @ryanRfox
- @nathanhourt
- @christophersanborn
- @xeroc
- @xiangxn
- @RichardWeiYang
- @Zapata
- @cwyyprog
- @Tydus
This is the first BitShares-Core release that supports Ubuntu 18.04 LTS. Due to the new features and improvements included in this release, all nodes are encouraged to upgrade.
## Security fixes
- CLI wallet: updated choice of range proof params in cli wallet reveals transaction magnitude to very narrow range for Blinded Transfers (issue #480 / PR #1117 #1227)
## API changes
- Removed crypto_api from default list of allowed APIs. (issue #1123 / PR #1125)
- Changed default `max-ops-per-account` value to 100, impacts account history (#1120)
- Added `get_account_limit_orders` database API to query for open orders of one account in one market #463 #849 #1163
- Added `get_asset_count` API to return total number of available assets #688, #1159
- Added `get_transaction_hex_without_sig` API get serialized transaction hex without `signatures` field (issue #1013 / PR #1038)
- Added support for account name as parameter for all API calls #969 #989 #1164 #1168 #1152 #1155
- Added `fail_reason` field to proposal object #730, #1036
- Retroactively deducted witness `missed_blocks` caused by chain halts #1087
## New features and improvements
- Added Openssl 1.1 and Ubuntu 18.04 support (issue #835 / PR #559 #921 #1008 https://github.com/bitshares/bitshares-fc/pull/7)
- Fixed invalid use of incomplete type `BIGNUM {aka struct bignum_st}` #327
- Added `witness_node` startup option `--enable-standby-votes-tracking` to track votes of standby witnesses and committee members, enabled by default #987, #1191, #1211
- Added `cli_wallet` startup option `--suggest-brain-key` to generate keys without connecting to a witness_node #1011, #1039
- Added `quit` command to `cli_wallet` #1104, #1050 https://github.com/bitshares/bitshares-fc/pull/63
- Improved witness_node performance for generating blocks, resyncing and replaying
- Improved account maintenance (vote tally) performance (issue #803/ PR #1085)
- Improved performance of `database::update_expired_feeds()` and global object getters #1093 #1180
- Slightly improved price comparison performance #1094 #1124
- Added index on `short_backing_asset`, better performance for updating asset (Issue #960 / PR #1019)
### Docker File
- Changed default docker p2p port to 1776, fixed p2p port to match Dockerfile #1226, #1078
- Fixes to make Docker containers shutdown gracefully #1077 #1115
- Fixed Docker Cloud Build Failing Due to Compile Time #1221 #1222
- Modified Dockerfile to work with new docker cloud version (0.10.1) #1075
- Updated testnet Branch to Include Latest Dockerfile #1074
### Elasticsearch
- Elasticsearch refactor #1103 #1201
- Add auth to communicate with the ES database with `--elasticsearch-basic-auth` startup option.
- Custom index names with `--elasticsearch-index-prefix` startup option.
- Removed `--elasticsearch-logs` startup option
- Better error handling: if there is an error when sending data to ElasticSearch, plugin will stop processing blocks and keep trying, and it resumes when connection is back at the same place. #681
- add operation_id_num for easier filtering.
- Fill orders data in additional for easy volume.
- Test cases framework. #1047
- Make full use of common functions in the 2 plugins(utilities).
- flush ES database on every block when node is in sync to improve real time user experience. #1137
- Increased performance of the `elasticsearch` plugin where possible: #1260
- Updated documentation https://github.com/bitshares/bitshares-core/wiki/ElasticSearch-Plugin
## Bugfixes
- Fixed CLI `get_account_history` pagination issue (duplicate ops when `limit` great than 100) #1176, #1177, #1179
- Fixed `cli_wallet` crashes for macOS 10.13.5 #1127 https://github.com/bitshares/bitshares-fc/pull/60
- Fixed a bug related to undo database that may cause `witness_node` to crash #1247 #1257
- Fixed "log file of current hour gets overwritten by default" #809 https://github.com/bitshares/bitshares-fc/pull/56
- Fixed 2 minor bugs in snapshot plugin #1185
- Fixed object database exception handling when built with Boost 1.66 (#852 #1126 #1161)
- Enable `boost::stacktrace` correctly https://github.com/bitshares/bitshares-fc/pull/66
## Other changes
- Integrated SonarCloud into Travis build (issue #836 / PR #1081 https://github.com/bitshares/bitshares-fc/pull/49)
- Travis speedup by using ccache #1264
- Added `USE_PROFILER` option to Cmake to enable profiling #1119
- Added `OPENSSL_CONF_SOURCE` variable for building in Windows https://github.com/bitshares/bitshares-fc/pull/59
- Added cli_tests to Travis-CI #1156
- Added `asset_api_tests` #1202
- Added new seed node by bangzi #1130 #1138
- Changed default `core_exchange_rate` quote asset in order to create asset more easily #1132
- Updated node.cpp, check attacker/buggy client before updating items ids #1007
- Optimized `find()` call in P2P code #1090, #1091
- Refactored `get_impacted_account_visitor`, removed duplicate code from impacted.cpp #845 #1073
- Refactored `cancel_all_subscriptions` for better performance and consistency #762 #1009 https://github.com/bitshares/bitshares-fc/pull/50
- Changed `push_proposal exception` log level to warn #1146
- Cleaned up Balance evaluator code #1150
- Cleaned up `get_named_account_balances` code #1154 , #1135
- Cleaned up logging in account.cpp #1010
- Cleanup up a visitor struct in static_variant.hpp https://github.com/bitshares/bitshares-fc/pull/58
- Removed obsolete constants (issue #1034 / PR #1072)
- Removed unused "smaz" compression #986 https://github.com/bitshares/bitshares-fc/pull/51
- Removed unused bz2 linkage #1003 https://github.com/bitshares/bitshares-fc/pull/52
- Removed double assert in `object_id_type` constructor #1128
- Removed protocol.hpp #1197, #1200
- Backported EOS PR 3560 replace assert in FC::crypto #992 https://github.com/bitshares/bitshares-fc/pull/54
- Backported EOS PR 3240 HTTP performance improvement, added move-semantic-version `set_body` function #999 https://github.com/bitshares/websocketpp/pull/1 https://github.com/bitshares/bitshares-fc/pull/65
- Updated test case for `time_point_sec::to_iso_string`, detect boost version #597 https://github.com/bitshares/bitshares-fc/pull/67
- Fixed Performance sucks at first block after a long sequence of missed blocks #1086 #1087
- witness `missed_blocks` count no longer increases due to chain halt (retroactive change)
- Fixed cli_tests websocket port binding #1178 #1187
- Fixed RPC logging level inconsistency #929 https://github.com/bitshares/bitshares-fc/pull/62
- Fixed wallet in-code docs, suppressed compiler warnings #1015 #1181 #1129 #1199 #1190
- Updated `asset_object::amount_to_string` implementation for slightly better performance #1012
- Updated system requirements into Documents #1107 #1108
- Updated README.md document #1121, #1166, #1212
## Contributors in this release:
- @pmconrad
- @abitmore
- @oxarbitrage
- @jmjatlanta
- @cogutvalera / @nanomobile
- @cifer-lee
- @ryanRfox
- @nathanhourt
- @christophersanborn
- @xeroc
- @xiangxn
- @RichardWeiYang
- @Zapata
- @cwyyprog
- @Tydus
240
中文 (Chinese) / 【投票】见证人是否动态调整喂价
« on: August 23, 2018, 09:52:18 pm »
在钱包里工作提案区域投票。
1.14.118 支持见证人动态调整喂价 Poll - BSIP42 - Adjust price feed dynamically
1.14.119 反对见证人动态调整喂价 Poll - BSIP42 - NO adjustment to price feed
相关讨论：
https://bitsharestalk.org/index.php?topic=26315.0
详情谁解释一下，谢谢。
1.14.118 支持见证人动态调整喂价 Poll - BSIP42 - Adjust price feed dynamically
1.14.119 反对见证人动态调整喂价 Poll - BSIP42 - NO adjustment to price feed
相关讨论：
https://bitsharestalk.org/index.php?topic=26315.0
详情谁解释一下，谢谢。
