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 9 10 11 12
76
不好意思,没时间多写。

问题描述在 https://github.com/cryptonomex/graphene/issues/645 最近几天已经在BTS和MUSE网络中出现多次,影响严重。

BTS 见证人请打我发布的这个补丁:  https://github.com/abitmore/bitshares-2/commit/2cf8fb62c98befb70fedffe739a05bc4ac5a0de8
该补丁不涉及硬分叉,只是丢弃有问题的块(可以理解为软分叉)。

补丁使用方法:
Code: [Select]
...
git checkout v2.0.160328

# 把这几行加到 `git checkout v2.0.160328` 之后, `make` 之前,重新编译
git remote add abit https://github.com/abitmore/bitshares-2.git
git fetch abit
git merge -m "Merge abit/fix-645-block-timestamp" abit/fix-645-block-timestamp

git submodule update --init --recursive
...

MUSE见证人请检查 Telegram 消息。

// 更新:官方 Github 最新 master / Release 已经包含这个补丁,无需单独打补丁了。

77
General Discussion / Serious network issue around 2016-07-29T21:20:00
« on: July 30, 2016, 10:34:39 pm »
Wanted to write more about this issue last night, but didn't get time. Still no much time now.

The issue is described in https://github.com/cryptonomex/graphene/issues/645, which has been triggered in BitShares network and MUSE network several times recently.

BitShares witnesses please apply this patch, if not already done: https://github.com/abitmore/bitshares-2/commit/2cf8fb62c98befb70fedffe739a05bc4ac5a0de8

MUSE witnesses please check Telegram channel for more info.

Code: [Select]
...
git checkout v2.0.160328

# add these lines after `git checkout v2.0.160328` and before `make`
git remote add abit https://github.com/abitmore/bitshares-2.git
git fetch abit
git merge -m "Merge abit/fix-645-block-timestamp" abit/fix-645-block-timestamp

git submodule update --init --recursive
...

78
On BitShares network.
Code: [Select]
2016-07-09T21:00:03 th_a:invoke handle_block         handle_block ] Got block: #7723323 time: 2016-07-09T21:00:03 latency: 346 ms from: spectral  irreversible: 7723304 (-19)                   application.cpp:521
2016-07-09T21:00:11 th_a:invoke handle_block         handle_block ] Got block: #7723323 time: 2016-07-09T21:00:00 latency: 11829 ms from: verbaltech2  irreversible: 7723305 (-18)                      application.cpp:521
2016-07-09T21:00:15 th_a:invoke handle_block         handle_block ] Got block: #7723324 time: 2016-07-09T21:00:15 latency: 63 ms from: verbaltech2  irreversible: 7723305 (-19)                 application.cpp:521
2016-07-09T21:00:15 th_a:invoke handle_block         handle_block ] Got block: #7723324 time: 2016-07-09T21:00:15 latency: 227 ms from: roadscape  irreversible: 7723305 (-19)                  application.cpp:521
2016-07-09T21:00:24 th_a:invoke handle_block         handle_block ] Got block: #7723325 time: 2016-07-09T21:00:24 latency: 199 ms from: delegate.btsnow  irreversible: 7723305 (-20)                    application.cpp:521
2016-07-09T21:00:24 th_a:invoke handle_block         handle_block ] Got block: #7723325 time: 2016-07-09T21:00:24 latency: 713 ms from: delegate-clayop  irreversible: 7723305 (-20)                    application.cpp:521
2016-07-09T21:00:30 th_a:invoke handle_block         handle_block ] Got block: #7723326 time: 2016-07-09T21:00:30 latency: 309 ms from: abc123  irreversible: 7723305 (-21)                     application.cpp:521
2016-07-09T21:00:30 th_a:invoke handle_block         handle_block ] Got block: #7723326 time: 2016-07-09T21:00:30 latency: 397 ms from: datasecuritynode  irreversible: 7723307 (-19)                   application.cpp:521
2016-07-09T21:00:33 th_a:invoke handle_block         handle_block ] Got block: #7723327 time: 2016-07-09T21:00:33 latency: 142 ms from: dele-puppy  irreversible: 7723307 (-20)                 application.cpp:521
2016-07-09T21:00:33 th_a:invoke handle_block         handle_block ] Got block: #7723327 time: 2016-07-09T21:00:33 latency: 252 ms from: bue  irreversible: 7723305 (-22)                        application.cpp:521
2016-07-09T21:00:39 th_a:invoke handle_block         handle_block ] Got block: #7723328 time: 2016-07-09T21:00:39 latency: 387 ms from: fox  irreversible: 7723305 (-23)                        application.cpp:521
2016-07-09T21:00:42 th_a:invoke handle_block         handle_block ] Got block: #7723329 time: 2016-07-09T21:00:42 latency: 149 ms from: spartako  irreversible: 7723308 (-21)                   application.cpp:521
2016-07-09T21:00:45 th_a:invoke handle_block         handle_block ] Got block: #7723330 time: 2016-07-09T21:00:45 latency: 156 ms from: rnglab  irreversible: 7723309 (-21)                     application.cpp:521
2016-07-09T21:00:48 th_a:invoke handle_block         handle_block ] Got block: #7723331 time: 2016-07-09T21:00:48 latency: 152 ms from: mr.agsexplorer  irreversible: 7723309 (-22)                     application.cpp:521
2016-07-09T21:00:51 th_a:invoke handle_block         handle_block ] Got block: #7723332 time: 2016-07-09T21:00:51 latency: 407 ms from: delegate.baozi  irreversible: 7723309 (-23)                     application.cpp:521
2016-07-09T21:00:54 th_a:invoke handle_block         handle_block ] Got block: #7723333 time: 2016-07-09T21:00:54 latency: 93 ms from: datasecuritynode  irreversible: 7723309 (-24)                    application.cpp:521
2016-07-09T21:00:54 th_a:invoke handle_block         handle_block ] Got block: #7723333 time: 2016-07-09T21:00:54 latency: 93 ms from: datasecuritynode  irreversible: 7723309 (-24)                    application.cpp:521
2016-07-09T21:00:57 th_a:invoke handle_block         handle_block ] Got block: #7723334 time: 2016-07-09T21:00:57 latency: 54 ms from: verbaltech2  irreversible: 7723311 (-23)                 application.cpp:521
2016-07-09T21:01:00 th_a:invoke handle_block         handle_block ] Got block: #7723335 time: 2016-07-09T21:01:00 latency: 184 ms from: spectral  irreversible: 7723312 (-23)                   application.cpp:521

79
中文(Chinese) / Worker制度改进建议
« on: June 18, 2016, 12:13:38 pm »
1. 所有worker工资发放,必须由worker发起人提出申请,经过理事会同意。具体可以采用多重签名方式,不需要修改代码。参考 https://cryptofresh.com/u/bsip10-worker

由于理事会成员是股东投票决定,相对公正,适合最后把关做成果审核,避免有人申请的活没干好就拿钱。

具体可以按里程碑/工作进展情况,分批领取工资。

2. 保障申请成功的worker能领到工资,现在投票、撤票比较随意,对申请人工作积极性影响比较大,进而导致工作效率问题,甚至导致工作无法完成。这个可能要改代码,具体规则待讨论。

80
中文(Chinese) / MetaExchange 停运 MetaFees 回购,请注意
« on: June 02, 2016, 10:18:48 am »
英文帖子在这里 https://bitsharestalk.org/index.php/topic,22580.0.html

内盘 Open.BTC:METAFEES 交易对有回购。

当初众筹价格是0.02BTC一个METAFEES,回购价格0.027。

其他METAEX资产请尽快提现。

81
General Discussion / !!!CAUTION!!! All public seed nodes down??
« on: May 04, 2016, 10:08:42 am »
Someone is attacking BitShares? Or bug?

Code: [Select]
1535394ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 83.221.132.47:1776
1541939ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 188.40.91.213:1776
1541939ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 114.92.236.175:62015
1556942ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 71.197.2.119:1776
1561942ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 45.32.247.234:1776
1567965ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 82.211.31.175:1776
1571306ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 159.203.15.153:1776
1572544ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 188.166.188.206:1776
1573421ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 107.170.245.89:1777
1573421ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 54.85.252.77:39705
1573421ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 104.236.144.84:1777
1573421ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 40.127.190.171:1777
1573421ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 185.25.22.21:1776
1573422ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 23.95.43.126:50696
1573422ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 109.73.172.144:50696
1573422ms th_a       application.cpp:177           reset_p2p_node       ] Adding seed node 128.199.143.47:2015

Code: [Select]
~$ telnet 83.221.132.47 1776
Trying 83.221.132.47...
^C
~$ telnet 188.40.91.213 1776
Trying 188.40.91.213...
telnet: Unable to connect to remote host: Connection refused
~$ telnet 71.197.2.119 1776
Trying 71.197.2.119...
telnet: Unable to connect to remote host: Connection refused
~$ telnet 45.32.247.234 1776
Trying 45.32.247.234...
telnet: Unable to connect to remote host: Connection refused
~$ telnet 82.211.31.175 1776
Trying 82.211.31.175...
telnet: Unable to connect to remote host: Connection refused
~$ telnet 159.203.15.153 1776
Trying 159.203.15.153...
telnet: Unable to connect to remote host: Connection refused
~$ telnet 188.166.188.206 1776
Trying 188.166.188.206...
telnet: Unable to connect to remote host: Connection refused
~$ telnet 107.170.245.89 1777
Trying 107.170.245.89...
Connected to 107.170.245.89.
Escape character is '^]'.
^]
telnet> quit
Connection closed.
~$ telnet 54.85.252.77 39705
Trying 54.85.252.77...
^C
~$ telnet 104.236.144.84 1777
Trying 104.236.144.84...
^C
~$ telnet 40.127.190.171 1777
Trying 40.127.190.171...
^C
~$ telnet 185.25.22.21 1776
Trying 185.25.22.21...
^C
~$ telnet 23.95.43.126 50696
Trying 23.95.43.126...
^C
~$ telnet 109.73.172.144 50696
Trying 109.73.172.144...
^C
~$ telnet 128.199.143.47 2015
Trying 128.199.143.47...
telnet: Unable to connect to remote host: Connection refused

After found it's not responding, I just restarted my seed node. A working seed node should respond like this:

Code: [Select]
~$ telnet 114.92.236.175 62015
Trying 114.92.236.175...
Connected to 114.92.236.175.
Escape character is '^]'.
]▒▒a▒X
      ▒o▒▒▒g▒▒s▒a▒Z▒f▒^]

82
中文(Chinese) / 这个内盘跨资产搬砖机器人很牛逼
« on: May 01, 2016, 12:06:09 pm »
http://cryptofresh.com/u/ar8173r

比如 http://cryptofresh.com/tx/56f4d10d26bcbb977770ad97d61e61673ec3f596 一单净赚1.3METAFEES

一天N单

谁做的,站出来?  [member=30068]botfund[/member] 是你吗?


83
General Discussion / Anyone noticed this bot?
« on: April 30, 2016, 09:35:56 pm »
http://cryptofresh.com/u/ar8173r

Looks like some kind of front-running bot, at least an arbitrary bot. Very clever.

Say there are 3 assets: A,B,C, so 3 trading pairs A:B, B:C, C:A. When someone pumps in A:B and left an order there, the bot checks if there is arbitrary opportunity if fill the order in A:B and pump in B:C and C:A at same time.

For example, in this block http://cryptofresh.com/tx/56f4d10d26bcbb977770ad97d61e61673ec3f596, it earned 1.3 METAFEES.

84
中文(Chinese) / 二元预测市场举例
« on: April 07, 2016, 11:12:54 am »
注:本文原文描述有误,尾部有更新。

举个例子。
现在新建一个预测市场,假设名字为SH1607313K,预测7月31日上证指数收盘是否在3000以上,抵押品为btsabc负责承兑的IOU.CNY。
裁决规则设计:7月31号上证市场收盘后进行裁决;届时如果上证指数低于3000,裁决结果为SH1607313K价值等于0;如果高于3000,裁决结果为SH1607313K价值等于1 IOU.CNY。

裁决前,参与人可以1:1抵押IOU.CNY借入SH1607313K在市场上挂单出售,或者用IOU.CNY在市场上挂单买入SH1607313K。

裁决后,
* 如果结果是1,那么参与人手里拥有SH1607313K资产自动1:1兑成IOU.CNY,抵押的IOU.CNY全部用于兑现资产
* 如果结果是0,那么参与人手里拥有的SH1607313K资产自动销毁,抵押的IOU.CNY全部释放

实际就是赌大小。市场价格就是赔率。
* 如果认为100%会超过3000,也就是预期资产最终价值=1,那么只要低于1买入就会赚。
* 如果认为100%会低于3000,也就是预期资产最终价值=0,那么只要高于0卖出就会赚。
* 如果当前市场价格(最新成交价)是0.6,说明60%的参与者(资金)认为最终会超过3000点。
* 基本来说,参与者预期股市会涨就买,预期股市会跌就卖
* 如果某时间点,你认为最终超过3000的概率是80%,也就是认为资产当前价值是0.8;如果当前市场价与你的预测不同,那么就有获利机会,可以选择参与。


其实这里有几个技术问题
1. 资产创建人可以手工裁决。我还不知道能不能自动裁决。
2. BTS里面的裁决,不是强制执行的。
如果持有人赌赢了,裁决后,可以1:1兑现。如果持有人赌输了,手头持有0的资产,一般不会去主动兑现,就导致抵押借出资产出售的人无法平仓,这时就需要发行者来强制收回,然后发送给赢的人进行平仓,来解除抵押。
为了鼓励赌输的人也主动平仓,规则设计时,可以不用0-1价,而是采用 “基础价+(0~1)” 的方式,即资产有底价。如果不主动平仓,等强制回收,就有额外损失。相应的,抵押借出时,需要多抵押一点。不过这样也不太方便。是否采用这个模式,取决于资产创建者。个人推荐这么做。
3. 裁决后资产名作废,不能再用了。

4. 如何确定最低抵押价。
也就是如何保证没人可以用1块钱抵押出资产,然后马上卖100块套利。
理想算法应该是按市价经过某种计算后得出最低抵押价。如果市场波动,导致抵押不足,就产生自动爆仓。
如果抵押品价值高于资产规则设计的最高价值,就永远不会爆仓。

现在的算法,可能是按喂价确定最低抵押价和爆仓价(不知道我说的对不对,最近没时间看代码)。
这样的话,喂价就比较重要了。比较懒的做法,就是喂价设为规则上限,这样保证没人爆仓,但是相对来说,做空的人参与门槛会高一点(相同仓位的收益/风险不变,但是资金限制导致仓位限制)。

5. 强制清算问题。
(同样,不知道我说的对不对,最近没时间看代码)。
如果按智能资产的做法,强制清算也是喂价相关。如果喂价设为规则上限,那么在裁决前要禁用强制清算,否则可以即时套利,市场没人做空了。
如果允许强制清算,那么喂价就有讲究了,这个留给市场开发者去研究。
(本来BM的爆仓算法是不需要喂价,后来被大家强烈要求下改回喂价了)


资产创建者的收益模式:手续费。
每笔成交,资产创建人可以收取一定百分比的手续费,这个手续费是以资产形式付给创建者的。基于这个模式,资产必须有底价,否则如果裁决结果为0,创建者收到的手续费也等于0。

还有个注意事项:手续费池。
为避免损失,手续费池可以在创建资产后清空;或者规则设计时,保证手续费池被偷了也不会亏,比如设置资产底价为1BTS。


本人不是专家,难免有疏漏,写错的地方欢迎指正。
希望抛砖引玉。

更新(2017-11-05):
1. 理论上,应该可以指定一组喂价人,根据喂价进行裁决,这样可以无需发行人裁决。(我需要再看看代码才知道这个功能是否已经实现)
2. 裁决时,所有抵押仓会被强制关闭,也就是说是强制执行。
  * 如果裁决结果是0,则仓位关闭时抵押物全部返还。所以不存在无法平仓的问题。
  * 如果裁决结果是1,则仓位关闭时抵押物全部被收走,等待资产持有人进行清算/兑现。
4. 抵押价是规则上限;不应存在爆仓情况。(但现在有BUG导致会爆仓)
5. 只有裁决后才能清算。清算即兑现。

85
中文(Chinese) / 喂价相关命令
« on: April 02, 2016, 03:00:49 pm »
最近有朋友在研究预测市场,苦于不知道如何发布喂价,所以我把以前记录的一些命令贴在这里,希望有帮助。时间仓促,来不及仔细整理,内容可能过期,或者有误,请见谅。

不知道预测市场是否已经有中文版教程。如果没有,希望有心人能研究一下,写个教程。
最好是做个简单好用的UI。

公开测试链 http://testnet.bitshares.eu/ 代码在 https://github.com/BitSharesEurope/graphene-testnet/ ,可以随意测试。

1. 自定义智能资产
* 创建资产
create_asset nathan MYMPA 5 {"issuer_permissions": 511,"flags": 128,"core_exchange_rate":{"base":{"amount":1,"asset_id":"1.3.0"},"quote":{"amount":1,"asset_id":"1.3.1"}}} {"new_feed_producers":[],"feed_lifetime_sec":120} true

* 设置喂价人
update_asset_feed_producers MYMPA [in.abit,dele-puppy] true

* 喂价
publish_asset_feed in.abit MYMPA {"settlement_price":{"base":{"amount":50000,"asset_id":"1.3.662"},"quote":{"amount":1000000000,"asset_id":"1.3.0"}},"core_exchange_rate":{"base":{"amount":100000,"asset_id":"1.3.0"},"quote":{"amount":10000,"asset_id":"1.3.662"}}} true

2. 预测市场
* 创建资产
create_asset nathan ASSETNAME 5 {"issuer_permissions": 511,"flags": 128,"core_exchange_rate":{"base":{"amount":1,"asset_id":"1.3.0"},"quote":{"amount":1,"asset_id":"1.3.1"}}} {"new_feed_producers":[],"is_prediction_market":true} true


* 结算(不知道专业术语是什么,意思就是结束这个预测市场)
global_settle_asset ASSETNAME {"base":{"amount":1,"asset_id":"1.3.663"},"quote":{"amount":1,"asset_id":"1.3.0"}} true

其中base是预测市场资产,quote是货币资产(例子里是BTS),asset_id是对应的资产id,base amount / quote amount 设 1/1就是赢,0/1就是输,1/2就是平局;base amount值应该不能比quote大。

注意事项
1.资产代码后面的数字,是小数位数。比如BTS的小数位数是5,CNY是4。预测市场的小数位数要与下注货币小数位数相同。注意先想清楚,这个一旦创建就不能修改的。

2.权限是用来限制资产发行人的。请注意,这个非常重要:开启权限才能修改旗标;权限一旦关闭很难再次开启(不信去问巨蟹)。现在界面里,默认是黑色,表示开启。

3.另外请注意,那个“手续费汇率”也非常重要。因为创建资产花的BTS手续费,有一半会进手续费池,等于别人可以按你设置的汇率,用你的资产来买池里的BTS。有个哥们跑了个机器人,专偷设错汇率的资产的手续费池。

86
Technical Support / Will there be a hangout today?
« on: April 01, 2016, 01:31:53 pm »
I mean, with BM in mumble? 14:00 UTC?
Strange. No announcement. [member=602]fuzzy[/member] ?

87
Yunbi is now publicly voting with their customers' voting power, voting for all refund/burn works but no other workers.

See https://cryptofresh.com/ballots

Yunbi's cold/warm wallet's voting proxy is set to laomao.


Personal suggestion: if you support development , please withdraw your funds from yunbi.

88
General Discussion / Can someone help test this new API server?
« on: March 26, 2016, 09:34:40 pm »
Can you help test "wss://valen-tin.fr:8090/ws" which is provided by [member=42020]linouxis9[/member], located in France?

Feedback needed.

If all OK we should add it to default server list.

89
General Discussion / Hard fork requests for review
« on: March 26, 2016, 10:21:05 am »
Here is a list of hard fork requests need to be reviewed:
* https://github.com/cryptonomex/graphene/issues/640 correct wrong voting proxy settings
* https://github.com/cryptonomex/graphene/issues/641 re-enable some permission settings of TCNY

90
According to http://docs.bitshares.org/bitshares/user/assets-faq.html#fee-pool, to avoid unexpected loss, UIA issuers need to keep an eye on the fee pool as well as the market, adjust CER(core exchange rate) when needed.
Quote
What is the fee pool all about?
The fee pool allows participants in the network to deal with assets and pay for the transaction fees without the need to hold BTS. Any transaction fee can be paid by paying any asset that has a core exchange rate (i.e. a price) at which the asset can be exchange implicitly into BTS to cover the network fee. If the asset’s fee pool is funded, the fees can be payed in the native UIA instead of BTS.

Note
The core exchange rate at which a fee can be exchanged into BTS may differ from the actual market valuation of the asset. A user, thus, may pay a premium or spare funds by paying in BTS.

Warning
Make sure your core exchange rate is higher than the lowest ask, otherwise, people will buy your token from the market and drain your fee pool via implicit arbitrage.


It is the task of the issuer to keep the fee pool funded and the core exchange rate updated unless he wants the owner of his asset to be required to hold BTS for the fee.

The fee pool acts like the asset issuer placed a bid order (buy asset, sell BTS) in the system with CER as the price/rate. When a participant wants to pay a fee in the asset but not in BTS, actually she sells some asset to the issuer. If there is an ask order in the market which is selling some assets for less BTS, an opportunist can buy asset from market, then sell to the issuer to get an instant profit.

Currently, issues can run bots to adjust CER automatically.

So here comes an idea: why don't we have a built-in feature that adjusts CER automatically?

My proposal:
* issuer can set a parameter on the asset: P%, when the market moves, the system automatically adjust CER to "a_fair_base_price" * (1 + P%)
* make this feature opt-in, which means UIA issuers can enable it or disable it at will

Potential options for "a_fair_base_price" includes:
[easier to implement]
* current highest bid
* current lowest ask
* latest order filling price
* a calculation based on above values
[harder to implement]
* [weighted]average/lowest/highest filling_price/bid_price/ask_price in last X hours
* a calculation based on above values

In a liquid market, the automatic adjusting may work just fine (see price feeding for smart coins).
In an illiquid market, there may be people try to manipulate the price, so maybe automatic adjusting won't work.
 
Extended thoughts: probably we can adjust settlement_price of smart coins in similar way, so eliminate the need of price feeds?

More thoughts?

Pages: 1 2 3 4 5 [6] 7 8 9 10 11 12