BitShares Forum
Main => General Discussion => Topic started by: toast on August 14, 2014, 07:46:16 pm
-
https://www.youtube.com/watch?v=Pb-K2tXWK4w
1) You can now increase the call price of a cover order
(5% fee still applies)
2) Switched to 1 hour moving price average rather than feeds
3) You now need 51 delegates to publish a feed (up from 3)
4) The client now warns you if you are making a bid or ask that is 5% worse than best price
GUI's hosted by our UI dev Valentine:
http://valzav.com/BitSharesXT.dmg
https://www.dropbox.com/s/0adsrsaw28v9zbd/BitSharesXT-0.0.15.exe
md5's:
Windows: a1fd771b49d22ff4ebc15c9a80a6ac28
OSX (.dmg): 0d66cbbfb05f37c8d457b00daa37dab1
-
Hm my Ubuntu education is coming to an end? Or is it? I think I am hooked...
-
Hm my Ubuntu education is coming to an end? Or is it? I think I am hooked...
This implies your relatively new to building source on Ubuntu. If not, forgive me if this sounds condescending.
An easy way to quickly build is to just copy/paste the instructions in the BUILD_UBUNTU.md. The trick is to open a shell then do sudo vi first so that you can enter your password and the cut and paste will go smoothly when it hits the sudo commands. Otherwise it'll stop and ask you because it's likely the sudo permission has timed out.
-
Hm my Ubuntu education is coming to an end? Or is it? I think I am hooked...
This implies your relatively new to building source on Ubuntu. If not, forgive me if this sounds condescending.
An easy way to quickly build is to just copy/paste the instructions in the BUILD_UBUNTU.md. The trick is to open a shell then do sudo vi first so that you can enter your password and the cut and paste will go smoothly when it hits the sudo commands. Otherwise it'll stop and ask you because it's likely the sudo permission has timed out.
Very new, last Sunday 8/10/14 new to be exact...
Yes but I was trying to build the GUI also and got errors... Without understanding that I have successfully build the cli...stupid newbie...
Additionally the instructions back then read:
git clone https://github.com/BitShares/bitshares_toolkit
git checkout develop
And the newbie had to first figure out that the second command have to be executed inside the bitshates_toolkit folder...
-
Ruh roh
Update: I clicked "No" and it continued to import one I supplied my pass phrase.
(http://i.imgur.com/EX2dwNd.png?1)
-
1) You can now increase the call price of a cover order
Could someone explain like i am 5 what this means?
-
Is it just me or is it really hard to read? Am I just getting old? The numbers are OK but the heads are faint. Grey on white is tough... :'(
(http://i.imgur.com/mHMzBdM.png)
-
Hm my Ubuntu education is coming to an end? Or is it? I think I am hooked...
This implies your relatively new to building source on Ubuntu. If not, forgive me if this sounds condescending.
An easy way to quickly build is to just copy/paste the instructions in the BUILD_UBUNTU.md. The trick is to open a shell then do sudo vi first so that you can enter your password and the cut and paste will go smoothly when it hits the sudo commands. Otherwise it'll stop and ask you because it's likely the sudo permission has timed out.
Very new, last Sunday 8/10/14 new to be exact...
Yes but I was trying to build the GUI also and got errors... Without understanding that I have successfully build the cli...stupid newbie...
Additionally the instructions back then read:
git clone https://github.com/BitShares/bitshares_toolkit (https://github.com/BitShares/bitshares_toolkit)
git checkout develop
And the newbie had to first figure out that the second command have to be executed inside the bitshates_toolkit folder...
All good now or still getting errors?
-
Also got this on the confirm order:
(http://i.imgur.com/afPXgW1.png)
-
Hm my Ubuntu education is coming to an end? Or is it? I think I am hooked...
This implies your relatively new to building source on Ubuntu. If not, forgive me if this sounds condescending.
An easy way to quickly build is to just copy/paste the instructions in the BUILD_UBUNTU.md. The trick is to open a shell then do sudo vi first so that you can enter your password and the cut and paste will go smoothly when it hits the sudo commands. Otherwise it'll stop and ask you because it's likely the sudo permission has timed out.
Very new, last Sunday 8/10/14 new to be exact...
Yes but I was trying to build the GUI also and got errors... Without understanding that I have successfully build the cli...stupid newbie...
Additionally the instructions back then read:
git clone https://github.com/BitShares/bitshares_toolkit (https://github.com/BitShares/bitshares_toolkit)
git checkout develop
And the newbie had to first figure out that the second command have to be executed inside the bitshates_toolkit folder...
All good now or still getting errors?
I do not know. Jumped to win for now.
Please funds. Thanks.
XTS4tuUUr1QcokNwBX4eseDfXWTvLYuyfDSoTVQHWSJr6Z3zTCaBF
XTS88Rz8BfHXijK8xFVGeKrG22WGvLFUsaoZP48GqCLn51sbvqZKe
-
Sent
-
On the Buy XTS tab (after successful buy of USD) I tried to sell them and it said "Market does not exist" or something similar in red. The transaction was pending and then canceled. I bought on XTS:USD then hit the flip around button for USD:XTS. It shows bid/asks but won't let you put one in.
-
Sent
Got them thanks.
First impression - very cool GUI. Great job guys.
-
Sent
Got them thanks.
First impression - very cool GUI. Great job guys.
Agreed. Didn't mean to come off as negative :). I am loving the market screens.
-
Sent
Got them thanks.
First impression - very cool GUI. Great job guys.
Agreed. Didn't mean to come off as negative :). I am loving the market screens.
1.I meant those same screens exactly and how they work.
.......................
2.Probably known 'issue' but right-mouse button is not working on win 7.
-
Can s.o. post some screenshots?
-
Enjoy :)
(http://i.imgur.com/7SmqOf7.png)
-
Can s.o. post some screenshots?
(https://db.tt/PRRWOh25)
-
Sweeet .. time to learn how to compile the gui .. using the terminal version all the way until now ;)
-
1. It is more the feel you get when you use it. Otherwise it looks like the active BTS X client.
.............................
2. .>> wallet_get_name
"default"
If I switch to Linux now, it will recognize that it is the same wallet ('default') by the password, correct?
-
1. It is more the feel you get when you use it. Otherwise it looks like the active BTS X client.
.............................
2. .>> wallet_get_name
"default"
If I switch to Linux now, it will recognize that it is the same wallet ('default') by the password, correct?
No, it is not completely deterministic. Best to copy your wallet directory from one OS to the other. Or the .json backup.
-
Hm my Ubuntu education is coming to an end? Or is it? I think I am hooked...
This implies your relatively new to building source on Ubuntu. If not, forgive me if this sounds condescending.
An easy way to quickly build is to just copy/paste the instructions in the BUILD_UBUNTU.md. The trick is to open a shell then do sudo vi first so that you can enter your password and the cut and paste will go smoothly when it hits the sudo commands. Otherwise it'll stop and ask you because it's likely the sudo permission has timed out.
Very new, last Sunday 8/10/14 new to be exact...
Yes but I was trying to build the GUI also and got errors... Without understanding that I have successfully build the cli...stupid newbie...
Additionally the instructions back then read:
git clone https://github.com/BitShares/bitshares_toolkit (https://github.com/BitShares/bitshares_toolkit)
git checkout develop
And the newbie had to first figure out that the second command have to be executed inside the bitshates_toolkit folder...
All good now or still getting errors?
Actually Yes I do. Should I try it as root?
npm ERR! Error: EACCES, mkdir '/home/tony/tmp/npm-5215-fEF78700'
npm ERR! { [Error: EACCES, mkdir '/home/tony/tmp/npm-5215-fEF78700']
npm ERR! errno: 3,
npm ERR! code: 'EACCES',
npm ERR! path: '/home/tony/tmp/npm-5215-fEF78700' }
npm ERR!
npm ERR! Please try running this command again as root/Administrator.
npm ERR! System Linux 3.13.0-32-generic
npm ERR! command "/usr/bin/nodejs" "/usr/bin/npm" "install"
npm ERR! cwd /home/tony/bitshares_toolkit/programs/web_wallet
npm ERR! node -v v0.10.25
npm ERR! npm -v 1.3.10
npm ERR! path /home/tony/tmp/npm-5215-fEF78700
npm ERR! code EACCES
npm ERR! errno 3
npm ERR! stack Error: EACCES, mkdir '/home/tony/tmp/npm-5215-fEF78700'
npm http 304 https://registry.npmjs.org/jasmine-given
npm http 304 https://registry.npmjs.org/lineman-angular
npm http 200 https://registry.npmjs.org/protractor
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR! /home/tony/bitshares_toolkit/programs/web_wallet/npm-debug.log
npm ERR! not ok code 0
tony@tony-Inspiron-N5110:~/bitshares_toolkit/programs/web_wallet$
[EDIT]
as root
npm http 304 https://registry.npmjs.org/inherits
npm http 304 https://registry.npmjs.org/inherits
> lineman-less@0.0.1 postinstall /home/tony/bitshares_toolkit/programs/web_wallet/node_modules/lineman-less
> node script/postinstall.js
sh: 1: node: not found
npm WARN This failure might be due to the use of legacy binary "node"
npm WARN For further explanations, please read
/usr/share/doc/nodejs/README.Debian
npm ERR! weird error 127
npm http 304 https://registry.npmjs.org/socket.io-client/0.9.16
BTW still trying the develop branch!
I will stay with Ubuntu for another 10-15 minutes if you need some info and will be back to win...
[edit]
ubuntu 14.04 LTS
Memory: 7.7 GiB
Disk: 249.9 GB
OS type:64-bit
Intel® Core™ i5-2410M CPU @ 2.30GHz × 4
-
Sweeet .. time to learn how to compile the gui .. using the terminal version all the way until now ;)
GUI is still very buggy... terminal is more reliable.
-
@tonyk try
ln -s /usr/bin/nodejs /usr/bin/node
(or maybe it's "ln -s /usr/bin/node /usr/bin/nodejs" - I forgot the order but only one of the two will work)
-
Sweeet .. time to learn how to compile the gui .. using the terminal version all the way until now ;)
GUI is still very buggy... terminal is more reliable.
Do you want us testing the GUI or is this more about the market logic?
-
@tonyk try
ln -s /usr/bin/nodejs /usr/bin/node
(or maybe it's "ln -s /usr/bin/node /usr/bin/nodejs" - I forgot the order but only one of the two will work)
I am back to win, so it will be while before I try it, but in general you have to give me instruction regarding Linux like you talk to an idiot.
So the question is when do I try the line(s) suggested? Before:
npm install
[udate]
OK the following worked:
su root
ln -s /usr/bin/nodejs /usr/bin/node
su [i]user[/i]
cd ..
cd .. //generally back to ~/bitshares_toolkit$
make buildweb
make BitSharesXT
:)
-
Sweeet .. time to learn how to compile the gui .. using the terminal version all the way until now ;)
GUI is still very buggy... terminal is more reliable.
Do you want us testing the GUI or is this more about the market logic?
Market logic is most important... GUI issues are second.
Rounding errors are to be expected.
-
Can I import my PTS PrivKEy or do I need someone to share funds?
acct key= XTS8N6A4atKw82AUGyGQu2ZhdXNxLe7xJrPYYbrKFjxYNuaYsYKWp
Thanks
Nevermind, killed the instance. Is anyone even participating in this?
-
cant cancel orders...
>> wallet_market_cancel_order XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8
31004 insufficient_funds: insufficient funds
{"amount":-7000000000,"current_ask->balance":6803032800}
bitshares market_operations.cpp:91 evaluate
{"*this":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}}
bitshares market_operations.cpp:118 evaluate
{"op":{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}}}
bitshares operation_factory.hpp:52 evaluate
{"trx":{"expiration":"20140815T010741","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}},{"type":"deposit_op_type","data":{"amount":6999990000,"condition":{"asset_id":0,"delegate_slate_id":0,"type":"withdraw_signature_type","data":{"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8","memo":null}}}}],"signatures":["1f5cd9d3b7b2a02aa5f712b4f662a0731b2e2d076b6d0e3fcc663099bbdbf4aa838621880b62507c1f074e87b56a35c536239f6e34bae02ec143eaf65af89d798b"]}}
bitshares transaction_evaluation_state.cpp:201 evaluate
{"trx":{"expiration":"20140815T010741","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}},{"type":"deposit_op_type","data":{"amount":6999990000,"condition":{"asset_id":0,"delegate_slate_id":0,"type":"withdraw_signature_type","data":{"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8","memo":null}}}}],"signatures":["1f5cd9d3b7b2a02aa5f712b4f662a0731b2e2d076b6d0e3fcc663099bbdbf4aa838621880b62507c1f074e87b56a35c536239f6e34bae02ec143eaf65af89d798b"]}}
bitshares chain_database.cpp:1195 evaluate_transaction
{"trx":{"expiration":"20140815T010741","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}},{"type":"deposit_op_type","data":{"amount":6999990000,"condition":{"asset_id":0,"delegate_slate_id":0,"type":"withdraw_signature_type","data":{"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8","memo":null}}}}],"signatures":["1f5cd9d3b7b2a02aa5f712b4f662a0731b2e2d076b6d0e3fcc663099bbdbf4aa838621880b62507c1f074e87b56a35c536239f6e34bae02ec143eaf65af89d798b"]}}
bitshares chain_database.cpp:1609 store_pending_transaction
{}
bitshares wallet.cpp:2370 sign_and_cache_transaction
{"owner_address":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}
bitshares wallet.cpp:3983 cancel_market_order
{}
bitshares common_api_client.cpp:1411 wallet_market_cancel_order
{"command":"wallet_market_cancel_order"}
bitshares cli.cpp:471 execute_command
-
cant cancel orders...
>> wallet_market_cancel_order XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8
31004 insufficient_funds: insufficient funds
{"amount":-7000000000,"current_ask->balance":6803032800}
bitshares market_operations.cpp:91 evaluate
{"*this":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}}
bitshares market_operations.cpp:118 evaluate
{"op":{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}}}
bitshares operation_factory.hpp:52 evaluate
{"trx":{"expiration":"20140815T010741","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}},{"type":"deposit_op_type","data":{"amount":6999990000,"condition":{"asset_id":0,"delegate_slate_id":0,"type":"withdraw_signature_type","data":{"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8","memo":null}}}}],"signatures":["1f5cd9d3b7b2a02aa5f712b4f662a0731b2e2d076b6d0e3fcc663099bbdbf4aa838621880b62507c1f074e87b56a35c536239f6e34bae02ec143eaf65af89d798b"]}}
bitshares transaction_evaluation_state.cpp:201 evaluate
{"trx":{"expiration":"20140815T010741","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}},{"type":"deposit_op_type","data":{"amount":6999990000,"condition":{"asset_id":0,"delegate_slate_id":0,"type":"withdraw_signature_type","data":{"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8","memo":null}}}}],"signatures":["1f5cd9d3b7b2a02aa5f712b4f662a0731b2e2d076b6d0e3fcc663099bbdbf4aa838621880b62507c1f074e87b56a35c536239f6e34bae02ec143eaf65af89d798b"]}}
bitshares chain_database.cpp:1195 evaluate_transaction
{"trx":{"expiration":"20140815T010741","delegate_slate_id":null,"operations":[{"type":"ask_op_type","data":{"amount":-7000000000,"ask_index":{"order_price":{"ratio":"0.000714285714285714","quote_asset_id":22,"base_asset_id":0},"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}}},{"type":"deposit_op_type","data":{"amount":6999990000,"condition":{"asset_id":0,"delegate_slate_id":0,"type":"withdraw_signature_type","data":{"owner":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8","memo":null}}}}],"signatures":["1f5cd9d3b7b2a02aa5f712b4f662a0731b2e2d076b6d0e3fcc663099bbdbf4aa838621880b62507c1f074e87b56a35c536239f6e34bae02ec143eaf65af89d798b"]}}
bitshares chain_database.cpp:1609 store_pending_transaction
{}
bitshares wallet.cpp:2370 sign_and_cache_transaction
{"owner_address":"XTS9LHDWRdYyuGGSapR2esCbfzjyw56Cp3i8"}
bitshares wallet.cpp:3983 cancel_market_order
{}
bitshares common_api_client.cpp:1411 wallet_market_cancel_order
{"command":"wallet_market_cancel_order"}
bitshares cli.cpp:471 execute_command
Issue with wallet scanning; fixed: https://github.com/BitShares/bitshares_toolkit/commit/d1b112d8042a60f70627682cb76d47e23d3b2c2c
-
https://www.youtube.com/watch?v=Pb-K2tXWK4w
1) You can now increase the call price of a cover order
(5% fee still applies)
2) Switched to 1 hour moving price average rather than feeds
3) You now need 51 delegates to publish a feed (up from 3)
4) The client now warns you if you are making a bid or ask that is 5% worse than best price
GUI's hosted by our UI dev Valentine:
http://valzav.com/BitSharesXT.dmg
https://www.dropbox.com/s/0adsrsaw28v9zbd/BitSharesXT-0.0.15.exe
IN china mainland can not download from dropbox !
-
give me some xts for test,thx!
XTS6Jdhdorg9ZvqPbXsk8yk3NvqeLU951834n3Tbf1gbhxt6pFzxz
-
give me some xts for test!
XTS8gqHLjRQvupVtkbG6efFfnR4ww4Zoru2fWpXGZzKFyGvUb3Lp3
-
Toast,please release a MD5 code of the Windows version,so we can feel free to download it from any available source.
Windows: a1fd771b49d22ff4ebc15c9a80a6ac28
OSX (.dmg): 0d66cbbfb05f37c8d457b00daa37dab1
-
XTS6pMpdZrQFeWhhSaMmcKPjuL7itJuXikLV6uicqmn8cv5UMT19q
3q for test
i can't connect to the testnetwork is there any node list？
-
After I finished some orders in Market. The account balance can't automatically display the real number.
It seems that the walet freezed. I have to close the client and reboot it to get the balance .
I am using Win wallet with GUI.
-
IN china mainland can not download from dropbox !
You have to climb over the GFW ;)
-
Not connected in China
-
get to the nearest exit... HK?
-
always Not connected，
Help！
-
IN china mainland can not download from dropbox !
You have to climb over the GFW ;)
wish bts dns can solve it
-
give me some xts for test,thx!
XTS6Jdhdorg9ZvqPbXsk8yk3NvqeLU951834n3Tbf1gbhxt6pFzxz
XTS6pMpdZrQFeWhhSaMmcKPjuL7itJuXikLV6uicqmn8cv5UMT19q
3q for test
give me some xts for test!
XTS8gqHLjRQvupVtkbG6efFfnR4ww4Zoru2fWpXGZzKFyGvUb3Lp3
Sent.
-
give me some xts for test,thx!
XTS6Jdhdorg9ZvqPbXsk8yk3NvqeLU951834n3Tbf1gbhxt6pFzxz
Sent.
thX
-
the ask depth is 17million, I can attack to grab lots of bitusd if I have 19million XTS
the bid depth is about 3million, I can attack to grab lots of xts if I have about 5 million XTS , and nobody try to save the marketing with much XTS in 1 hour.
I want to try plan A, attack with 19million, if you can fund me, my account is baozi
-
the ask depth is 17million, I can attack to grab lots of bitusd if I have 19million XTS
the bid depth is about 3million, I can attack to grab lots of xts if I have about 5 million XTS , and nobody try to save the marketing with much XTS in 1 hour.
I want to try plan A, attack with 19million, if you can fund me, my account is baozi
洗洗更健康
-
Or I post the attack method. I have write in Chinese, I try to write with English...
method 1:
the plan is control the average price to a very lower price, like 1/100 normal. margin call will sell much XTS with very cheap price to you.
1. short 2,000,000 xts with price 1/10000 normal, keep the market depth.
2. buy all normal price bitusd, the highest price of left bid order is under 1/100 normal. then ask 1 xts with price 1/100 normal, don't match .
keep this state 1 minute, the average price will down about 1/60.
3. can cancel the first short price, without market depth, market engine will not work. this can help keep more time.
4. If some one try to help with high price bid order, eat it, after some time, price is enough down, the margin call will help you to eat the bid order.
5. when average price is low enough. make market depth, start the margin call. your bid order with very low price can eat much more XTS from the margin call.
今晚还有事情，不想测试了，把方法写出来，有空的去试试吧。
方法一：这个攻击的思路是操控均价到很低，让short暴仓，利用暴仓后会凭空生成bts买单的规则，大量吃进廉价bts。注意暴仓后的cover价限制在均价的2/3以上了，所以必须要把均价拉低才能成功。
1.按最低价下 200万XTS short，托底，保持市场深度要求。
2. 买入 bitusd ，砸穿所有正常价位的 bid/short 买单，让剩余 bid/short最高价在 1/100 以下。挂一个不能成交的1/100价位以下的 ask。每多保持1分钟，均价就能跌1/60。
3. 可以考虑撤销最开始的托底单，深度不够，交易停止，这样能帮助均价保持下跌。
4. 如果有人要阻止攻击，增加了深度，且挂了高价bid，那就按1/100挂 ask 单砸。注意坚持一会就会有大量暴仓的 xts 出来帮助你一起砸。此时系统刚启动，没有那么多bitusd跟你打。
但对方如果直接挂了1千万的 short，就要看你的实力了。。。。
5. 等均价跌到1/100, 按此价挂 bid/short 单，吃掉所有暴仓的便宜 xts。
这种攻击有点难度，要有足够的xts压价。最好在人少的时候偷偷干。以上1/100换成1/10000同样有效。
方法二：short 价位限制在低于均价的4/3了，同样需要控制均价，把价位拉高。然后按很高的价格 short bitusd，自己再吃进。能获取大量bitusd。
这个攻击相对上面的简单很多了，砸穿后马上挂一个一万倍的单子，平均下来也能把价位拉高 10000/360 倍。挂一个1亿倍的呢？
可惜现在 ask 有 1300 万 xts 深度，大概需要 1500万XTS的攻击成本。
-
method 2:
the plan is to control the average price to very higher price. this is more easy.
1. make a ask price with very high, like 1,000,000 * noral. the amount is 2,000,000 XTS.
2. eat all ask order with a normal short order , price is average price * 4/3.
3. make a bid price like 1,000,000 * normal, and a ask price like 1,000,100 * normal. the average price will become normal price * 1,000,000/360 .
4. you can keep wait for more higher price. or you can just short at this high price, and sell all your XTS with this higher price. grab much bitusd.
-
I'm glad you're on our side.
-
the ask depth is 17million, I can attack to grab lots of bitusd if I have 19million XTS
the bid depth is about 3million, I can attack to grab lots of xts if I have about 5 million XTS , and nobody try to save the marketing with much XTS in 1 hour.
I want to try plan A, attack with 19million, if you can fund me, my account is baozi
sended you 1million xts
-
Need to compile again .. did the stupid "rm -rf " on a wildcard including my btsx folders :)
gonna send you some of my few too when I finished compiling
-
What are you at now, Alt?
-
Would like to connect to the seed nodes .. no luck :(
Attempting to connect to peer 107.170.30.182:1776
Attempting to connect to peer 107.170.30.182:1777
Attempting to connect to peer 107.170.30.182:1778
-
I'm glad you're on our side.
+5%
me2
-
I have try, but why there is depth error?
default (unlocked) >>> blockchain_market_order_book USD XTS
BIDS (* Short Order) | ASKS
TOTAL QUANTITY PRICE | PRICE QUANTITY TOTAL COLLATE
RAL
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
5,169.1045 USD MARKET PRICE | 10.000000000000 USD 100,000.00000 XTS 1,000,000.0000 USD
300,000.0000 USD 30,000.00000 XTS 10.000000000000 USD*| 100.000000000000 USD 199,999.00000 XTS 19,999,900.0000 USD
4,122.9218 USD 412,292.18476 XTS 0.010000000000 USD*| 1000.000000000000 USD 1,000,000.00000 XTS 1,000,000,000.0000 USD
0.3968 USD 53.96960 XTS 0.007352941176 USD*| 100000000.000000000000 USD 4,000,000.00000 XTS400,000,000,000,000.0000 USD
0.9999 USD 136.00000 XTS 0.007352941176 USD*| 100000000.000000000000 USD 1,000,000.00000 XTS100,000,000,000,000.0000 USD
0.9999 USD 137.00000 XTS 0.007299270073 USD*| 10000000000000.000000000000 USD 1.00000 XTS10,000,000,000,000.0000 USD
2,100.0000 USD 300,000.00000 XTS 0.007000000000 USD |
9,991.3057 USD 1,499,695.00000 XTS 0.006662225183 USD*|
799.9999 USD 120,719.98491 XTS 0.006626905235 USD |
99.9999 USD 15,500.00000 XTS 0.006451612903 USD*|
66.6666 USD 10,666.65600 XTS 0.006250000000 USD |
0.6240 USD 100,000.00000 XTS 0.000006240000 USD |
0.1999 USD 1,999,000.00000 XTS 0.000000100000 USD |
0.8000 USD 800,000,000.00000 XTS 0.000000001000 USD |
0.0900 USD 90,000,000.00000 XTS 0.000000001000 USD |
0.0010 USD 100,000,000.00000 XTS 0.000000000010 USD |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
Average Price in Recent Trades: NO FEEDS Bid Depth: 1,957,814.15436 XTS Ask Depth: 20,582,540.38032 XTS Min Depth: 2,000,000.00000 XTS
Last Error: insufficient depth (37005)
Details:
37005 insufficient_depth: insufficient depth
{"reason":"After executing orders there was insufficient depth remaining","market_stat":{"quote_id":22,"base_id":0,"bid_depth":192781415436,"ask_depth":2061254038032,"avg_price_24h":{"ratio":"1.72982868043448879","quote_asset_id":22,"base_asset_id":0},"last_error":null},"(((1000*1000*int64_t(1000)*1000*int64_t(1000)) / 5)/1000)":200000000000}
th_a market_engine.cpp:433 execute
default (unlocked) >>> wallet_market_
wallet_market_cancel_order wallet_market_order_list wallet_market_submit_bid
wallet_market_cover wallet_market_submit_ask wallet_market_submit_short
-
I have try, but why there is depth error?
default (unlocked) >>> blockchain_market_order_book USD XTS
BIDS (* Short Order) | ASKS
TOTAL QUANTITY PRICE | PRICE QUANTITY TOTAL COLLATE
RAL
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
5,169.1045 USD MARKET PRICE | 10.000000000000 USD 100,000.00000 XTS 1,000,000.0000 USD
300,000.0000 USD 30,000.00000 XTS 10.000000000000 USD*| 100.000000000000 USD 199,999.00000 XTS 19,999,900.0000 USD
4,122.9218 USD 412,292.18476 XTS 0.010000000000 USD*| 1000.000000000000 USD 1,000,000.00000 XTS 1,000,000,000.0000 USD
0.3968 USD 53.96960 XTS 0.007352941176 USD*| 100000000.000000000000 USD 4,000,000.00000 XTS400,000,000,000,000.0000 USD
0.9999 USD 136.00000 XTS 0.007352941176 USD*| 100000000.000000000000 USD 1,000,000.00000 XTS100,000,000,000,000.0000 USD
0.9999 USD 137.00000 XTS 0.007299270073 USD*| 10000000000000.000000000000 USD 1.00000 XTS10,000,000,000,000.0000 USD
2,100.0000 USD 300,000.00000 XTS 0.007000000000 USD |
9,991.3057 USD 1,499,695.00000 XTS 0.006662225183 USD*|
799.9999 USD 120,719.98491 XTS 0.006626905235 USD |
99.9999 USD 15,500.00000 XTS 0.006451612903 USD*|
66.6666 USD 10,666.65600 XTS 0.006250000000 USD |
0.6240 USD 100,000.00000 XTS 0.000006240000 USD |
0.1999 USD 1,999,000.00000 XTS 0.000000100000 USD |
0.8000 USD 800,000,000.00000 XTS 0.000000001000 USD |
0.0900 USD 90,000,000.00000 XTS 0.000000001000 USD |
0.0010 USD 100,000,000.00000 XTS 0.000000000010 USD |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
Average Price in Recent Trades: NO FEEDS Bid Depth: 1,957,814.15436 XTS Ask Depth: 20,582,540.38032 XTS Min Depth: 2,000,000.00000 XTS
Last Error: insufficient depth (37005)
Details:
37005 insufficient_depth: insufficient depth
{"reason":"After executing orders there was insufficient depth remaining","market_stat":{"quote_id":22,"base_id":0,"bid_depth":192781415436,"ask_depth":2061254038032,"avg_price_24h":{"ratio":"1.72982868043448879","quote_asset_id":22,"base_asset_id":0},"last_error":null},"(((1000*1000*int64_t(1000)*1000*int64_t(1000)) / 5)/1000)":200000000000}
th_a market_engine.cpp:433 execute
default (unlocked) >>> wallet_market_
wallet_market_cancel_order wallet_market_order_list wallet_market_submit_bid
wallet_market_cover wallet_market_submit_ask wallet_market_submit_short
Bid Depth: 1,957,814.15436 XTS
< 2M
-
The 1 hr rule is in terms of blocks where the market actually executes. If you attempt to stall the market then no time will run off the clock.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
I think I should got 1,000,000 USD at this attack for now, but don't know why the market stop match... and about 700,000 USD is grab by others :'(
I have to stop here, but the plane what I will do is:
I will get about 1,000,000 USD.
then I will give a bid order at price 0.011 USD, with 1,000,000 USD will buy about 100,000,000 XTS.
then give a ask order at price 0.012 USD.
wait some time, when the average price down to normal, start the margin call, and I can get 100,000,000 XTS
I use about 5,000,000 XTS for this attack
I have try, but why there is depth error?
default (unlocked) >>> blockchain_market_order_book USD XTS
BIDS (* Short Order) | ASKS
TOTAL QUANTITY PRICE | PRICE QUANTITY TOTAL COLLATE
RAL
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
5,169.1045 USD MARKET PRICE | 10.000000000000 USD 100,000.00000 XTS 1,000,000.0000 USD
300,000.0000 USD 30,000.00000 XTS 10.000000000000 USD*| 100.000000000000 USD 199,999.00000 XTS 19,999,900.0000 USD
4,122.9218 USD 412,292.18476 XTS 0.010000000000 USD*| 1000.000000000000 USD 1,000,000.00000 XTS 1,000,000,000.0000 USD
0.3968 USD 53.96960 XTS 0.007352941176 USD*| 100000000.000000000000 USD 4,000,000.00000 XTS400,000,000,000,000.0000 USD
0.9999 USD 136.00000 XTS 0.007352941176 USD*| 100000000.000000000000 USD 1,000,000.00000 XTS100,000,000,000,000.0000 USD
0.9999 USD 137.00000 XTS 0.007299270073 USD*| 10000000000000.000000000000 USD 1.00000 XTS10,000,000,000,000.0000 USD
2,100.0000 USD 300,000.00000 XTS 0.007000000000 USD |
9,991.3057 USD 1,499,695.00000 XTS 0.006662225183 USD*|
799.9999 USD 120,719.98491 XTS 0.006626905235 USD |
99.9999 USD 15,500.00000 XTS 0.006451612903 USD*|
66.6666 USD 10,666.65600 XTS 0.006250000000 USD |
0.6240 USD 100,000.00000 XTS 0.000006240000 USD |
0.1999 USD 1,999,000.00000 XTS 0.000000100000 USD |
0.8000 USD 800,000,000.00000 XTS 0.000000001000 USD |
0.0900 USD 90,000,000.00000 XTS 0.000000001000 USD |
0.0010 USD 100,000,000.00000 XTS 0.000000000010 USD |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
Average Price in Recent Trades: NO FEEDS Bid Depth: 1,957,814.15436 XTS Ask Depth: 20,582,540.38032 XTS Min Depth: 2,000,000.00000 XTS
Last Error: insufficient depth (37005)
Details:
37005 insufficient_depth: insufficient depth
{"reason":"After executing orders there was insufficient depth remaining","market_stat":{"quote_id":22,"base_id":0,"bid_depth":192781415436,"ask_depth":2061254038032,"avg_price_24h":{"ratio":"1.72982868043448879","quote_asset_id":22,"base_asset_id":0},"last_error":null},"(((1000*1000*int64_t(1000)*1000*int64_t(1000)) / 5)/1000)":200000000000}
th_a market_engine.cpp:433 execute
default (unlocked) >>> wallet_market_
wallet_market_cancel_order wallet_market_order_list wallet_market_submit_bid
wallet_market_cover wallet_market_submit_ask wallet_market_submit_short
-
:'( :'( :'(
somebody have withdraw the short order
I have try, but why there is depth error?
default (unlocked) >>> blockchain_market_order_book USD XTS
BIDS (* Short Order) | ASKS
TOTAL QUANTITY PRICE | PRICE QUANTITY TOTAL COLLATE
RAL
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
5,169.1045 USD MARKET PRICE | 10.000000000000 USD 100,000.00000 XTS 1,000,000.0000 USD
300,000.0000 USD 30,000.00000 XTS 10.000000000000 USD*| 100.000000000000 USD 199,999.00000 XTS 19,999,900.0000 USD
4,122.9218 USD 412,292.18476 XTS 0.010000000000 USD*| 1000.000000000000 USD 1,000,000.00000 XTS 1,000,000,000.0000 USD
0.3968 USD 53.96960 XTS 0.007352941176 USD*| 100000000.000000000000 USD 4,000,000.00000 XTS400,000,000,000,000.0000 USD
0.9999 USD 136.00000 XTS 0.007352941176 USD*| 100000000.000000000000 USD 1,000,000.00000 XTS100,000,000,000,000.0000 USD
0.9999 USD 137.00000 XTS 0.007299270073 USD*| 10000000000000.000000000000 USD 1.00000 XTS10,000,000,000,000.0000 USD
2,100.0000 USD 300,000.00000 XTS 0.007000000000 USD |
9,991.3057 USD 1,499,695.00000 XTS 0.006662225183 USD*|
799.9999 USD 120,719.98491 XTS 0.006626905235 USD |
99.9999 USD 15,500.00000 XTS 0.006451612903 USD*|
66.6666 USD 10,666.65600 XTS 0.006250000000 USD |
0.6240 USD 100,000.00000 XTS 0.000006240000 USD |
0.1999 USD 1,999,000.00000 XTS 0.000000100000 USD |
0.8000 USD 800,000,000.00000 XTS 0.000000001000 USD |
0.0900 USD 90,000,000.00000 XTS 0.000000001000 USD |
0.0010 USD 100,000,000.00000 XTS 0.000000000010 USD |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------
Average Price in Recent Trades: NO FEEDS Bid Depth: 1,957,814.15436 XTS Ask Depth: 20,582,540.38032 XTS Min Depth: 2,000,000.00000 XTS
Last Error: insufficient depth (37005)
Details:
37005 insufficient_depth: insufficient depth
{"reason":"After executing orders there was insufficient depth remaining","market_stat":{"quote_id":22,"base_id":0,"bid_depth":192781415436,"ask_depth":2061254038032,"avg_price_24h":{"ratio":"1.72982868043448879","quote_asset_id":22,"base_asset_id":0},"last_error":null},"(((1000*1000*int64_t(1000)*1000*int64_t(1000)) / 5)/1000)":200000000000}
th_a market_engine.cpp:433 execute
default (unlocked) >>> wallet_market_
wallet_market_cancel_order wallet_market_order_list wallet_market_submit_bid
wallet_market_cover wallet_market_submit_ask wallet_market_submit_short
Bid Depth: 1,957,814.15436 XTS
< 2M
-
oh, I have missed that, then it's more difficult to control the price.
The 1 hr rule is in terms of blocks where the market actually executes. If you attempt to stall the market then no time will run off the clock.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
-
@alt: so all is fine now? market is still safe?
-
@alt: so all is fine now? market is still safe?
no, control the average price to higher is still very quickly, only need 1 block.
control to low price is more difficult.
In fact, this is not a big problem, we can get the medium price just like feed price, sort and use the middle price.
and use a time more than 1 hour.
what I am worried about is the rule:
1. margin call can create bts, this can be use to attack the whole system. I still prefer just clear the short position can't be cover.
2. the short price is limit, if the limit is too lower for some reason, like a sudden price grow of bts, nobody ask with a lower price, and no asset can be create.
I have post for my thought here.
I have no doubt that market consensus will make bitusd track the price of USD.
but the rules with leak will break the market consensus.
the rules with too many limit will stop the market consensus.
I think we should make a rule with less limit, and without leak.
here is my solution.
the main different is the short bitusd is separate from bid XTS.
for example:
If I want to short 100 bitUSD with price 1bitUSD/xts, I need to freeze 200 XTS, and I can get 100 bitUSD immediately.
then I can usd these bitUSD to buy XTS with a different price, for bit order. maybe 0.5 bitUSD/XTS or whatever, there is no limit for the price of bid order.
the same, there is no limit for the price of ask order. there is no limit for the market depth check.
the key is to limit the short price.
the maximum short price is coming from the minimum matched bid price of latest blocks(maybe latest 24*60*6 blocks).
at the beginning there is no matched bid price, we can set a safety initial limit price, come from the central trade market, like 0.01USD/XTS.
-
USD：XTS
short USD
quantity 1
price 0.04536595820001758 because 0.04536595820001758 is min
failed
info
Order failed: stupid order (20034) You are attempting to short at more than 5% above the buy price. This short is based on economically unsound principles, and is ill-advised. If you're sure you want to do this, place your short again and set allow_stupid_short to true
-
Order failed: stupid order (20034) You are attempting to short at more than 5% above the buy price. This short is based on economically unsound principles, and is ill-advised. If you're sure you want to do this, place your short again and set allow_stupid_short to true
lol .. very nice :)
-
USD：XTS
short USD
quantity 1
price 0.04536595820001758 because 0.04536595820001758 is min
failed
info
Order failed: stupid order (20034) You are attempting to short at more than 5% above the buy price. This short is based on economically unsound principles, and is ill-advised. If you're sure you want to do this, place your short again and set allow_stupid_short to true
HAHAHA +5%
-
OMG i got the wrong direction :'( :'( :'( :'( :'( :'( :'(
short usd less bts mean high risk………………
-
@alt: so all is fine now? market is still safe?
no, control the average price to higher is still very quickly, only need 1 block.
control to low price is more difficult.
In fact, this is not a big problem, we can get the medium price just like feed price, sort and use the middle price.
and use a time more than 1 hour.
what I am worried about is the rule:
1. margin call can create bts, this can be use to attack the whole system. I still prefer just clear the short position can't be cover.
2. the short price is limit, if the limit is too lower for some reason, like a sudden price grow of bts, nobody ask with a lower price, and no asset can be create.
I have post for my thought here.
I have no doubt that market consensus will make bitusd track the price of USD.
but the rules with leak will break the market consensus.
the rules with too many limit will stop the market consensus.
I think we should make a rule with less limit, and without leak.
here is my solution.
the main different is the short bitusd is separate from bid XTS.
for example:
If I want to short 100 bitUSD with price 1bitUSD/xts, I need to freeze 200 XTS, and I can get 100 bitUSD immediately.
then I can usd these bitUSD to buy XTS with a different price, for bit order. maybe 0.5 bitUSD/XTS or whatever, there is no limit for the price of bid order.
the same, there is no limit for the price of ask order. there is no limit for the market depth check.
the key is to limit the short price.
the maximum short price is coming from the minimum matched bid price of latest blocks(maybe latest 24*60*6 blocks).
at the beginning there is no matched bid price, we can set a safety initial limit price, come from the central trade market, like 0.01USD/XTS.
I agree median price would be harder to manipulate... more expensive to calculate, but harder to manipulate.
-
anyone having trouble connecting to test network through GUI?
-
anyone having trouble connecting to test network through GUI?
network_add_node "207.12.89.119:1776"
-
which branch are this dry run use, i try the branch master and develop, neither work because of can't connet.
and the p2p log is:
Received a rejection from 107.170.30.182:1778 in response to my "hello", reason:
"You're on a different chain than I am.
I'm on 6af511b5e7edfb4a36e946443eb514cd8c5e47d5fad578b75c03447d94df71fd
and you're on 4f07657a990f68ed155b6bf7d20f37e46991d84481439394abbec9eab60a73f7"
-
which branch are this dry run use, i try the branch master and develop, neither work because of can't connet.
and the p2p log is:
Received a rejection from 107.170.30.182:1778 in response to my "hello", reason:
"You're on a different chain than I am.
I'm on 6af511b5e7edfb4a36e946443eb514cd8c5e47d5fad578b75c03447d94df71fd
and you're on 4f07657a990f68ed155b6bf7d20f37e46991d84481439394abbec9eab60a73f7"
Should be develop but the seed nodes seems to have carried out a mutiny. Try:
anyone having trouble connecting to test network through GUI?
network_add_node "207.12.89.119:1776"
-
network_add_node "207.12.89.119:1776"
does't work
-
Try any of:
network_add_node "69.164.192.144:33863"
network_add_node "180.153.142.120:8764"
network_add_node "207.12.89.119:1776"
network_add_node "114.215.104.153:1776"
network_add_node "188.138.107.159:45883"
network_add_node "188.138.107.159:58090"
-
https://www.youtube.com/watch?v=Pb-K2tXWK4w
1) You can now increase the call price of a cover order
(5% fee still applies)
2) Switched to 1 hour moving price average rather than feeds
3) You now need 51 delegates to publish a feed (up from 3)
4) The client now warns you if you are making a bid or ask that is 5% worse than best price
GUI's hosted by our UI dev Valentine:
http://valzav.com/BitSharesXT.dmg
https://www.dropbox.com/s/0adsrsaw28v9zbd/BitSharesXT-0.0.15.exe
md5's:
Windows: a1fd771b49d22ff4ebc15c9a80a6ac28
OSX (.dmg): 0d66cbbfb05f37c8d457b00daa37dab1
if it's possible to add
K线图-----K chart,
5 日均线------5 average daily lines,
10日均线-------10 average daily lines,
30日均线-------30 average daily lines,
-
Try any of:
network_add_node "69.164.192.144:33863"
network_add_node "180.153.142.120:8764"
network_add_node "207.12.89.119:1776"
network_add_node "114.215.104.153:1776"
network_add_node "188.138.107.159:45883"
network_add_node "188.138.107.159:58090"
thinks, it works.
-
Sending the market fees (USD) to an insurance fund rather than converting them to XTS and burning them as dividends or paying the funds to delegates would provide a more controlled way of insuring against price volatility.
Over time the network would end up accumulating a large balance of USD that it could hold in reserve. If something happened then this reserve could be drained or even "go negative" for a while. So if you assume a reasonable spread on market orders (buy/sell overlap) then it is very likely the market will have a large and growing balance of USD.
When a short is unable to cover, the network can just give up some of its own USD instead.
So in a major price correction you just have to ask yourself what percent of the USD will be "uncovered", how long will it take the network to accumulate that percent, and how likely is it to occur.
The event is most likely to occur as a result of an "attack" where someone tries to manipulate the price. Increasing the reward for the attack by printing XTS makes the attack more likely. If you can trigger a margin call and insure that your bid is very low then the potential printing is unbounded.
I think having BitUSD "unbacked" after such an event may be better at discouraging the attack. The attackers prize would thus be limited to collecting the margin rather than printing unlimited XTS. The market peg might still hold even with surplus USD floating around until enough fees are collected to take it out of circulation.
So... I am going to propose the following changes:
1) USD fees are never converted to XTS to be burned, they are kept as insurance on black swans
2) If the "current price" is greater than max bid, then we average in max bid. If the current price is less than min ask, then we average in min ask. This has the effect of using the median because you are essentially truncating outliers and limiting the effect a single block can have on the average price.
Someone pointed out that FDIC insurance (printing XTS) may be ok for some bit assets (USD) it would be a major problem for other bit assets (Bit PPC) in the event the BitAsset lost the interest of the market participants. This would result in a major problem where one "stale" bit asset that was still insured would be very insecure.
-
OK Cool. I knew you just needed to sleep over stuff so you come to the right decisions, and get rid of crazy thoughts (in red below). With this issue (hopefully) out of the way, can you please sleep over the urgent necessity to have bitUSD5 right out of the gate... It is after 2 am anyway...
The concept of using newly issued XTS to back a new short position.... is interesting.
The effect is the same as having "unbacked USD" in circulation. You "Created It" with so much collateral that another 66% fall in value would have to occur for BitUSD holders to actually receive the funds. It create downward pressure on BitUSD price breaking the peg with "artificial" shorting power when what the market needs is buying power.
I think it is just a "kick the can" approach. We need to take USD out of circulation not put more into circulation.
Actually with my approach you do not change the market (you do not crate downward pressure as you put it). You sell the same amount you just bought at the same price nevertheless.
The only thing it removes is the artificial buying pressure the purchase by the initial insurance provides (which it (the initial insurance) does by buying bitUSD with newly created BTSX!). Which is one of the worst things to do in rising bitUSD prices.
Actually, rising BitUSD prices brings in new SHORTS from real market players. So the added buying pressure keeps things real.
-
Sending the market fees (USD) to an insurance fund rather than converting them to XTS and burning them as dividends or paying the funds to delegates would provide a more controlled way of insuring against price volatility.
Over time the network would end up accumulating a large balance of USD that it could hold in reserve. If something happened then this reserve could be drained or even "go negative" for a while. So if you assume a reasonable spread on market orders (buy/sell overlap) then it is very likely the market will have a large and growing balance of USD.
When a short is unable to cover, the network can just give up some of its own USD instead.
So in a major price correction you just have to ask yourself what percent of the USD will be "uncovered", how long will it take the network to accumulate that percent, and how likely is it to occur.
The event is most likely to occur as a result of an "attack" where someone tries to manipulate the price. Increasing the reward for the attack by printing XTS makes the attack more likely. If you can trigger a margin call and insure that your bid is very low then the potential printing is unbounded.
I think having BitUSD "unbacked" after such an event may be better at discouraging the attack. The attackers prize would thus be limited to collecting the margin rather than printing unlimited XTS. The market peg might still hold even with surplus USD floating around until enough fees are collected to take it out of circulation.
So... I am going to propose the following changes:
1) USD fees are never converted to XTS to be burned, they are kept as insurance on black swans
2) If the "current price" is greater than max bid, then we average in max bid. If the current price is less than min ask, then we average in min ask. This has the effect of using the median because you are essentially truncating outliers and limiting the effect a single block can have on the average price.
Someone pointed out that FDIC insurance (printing XTS) may be ok for some bit assets (USD) it would be a major problem for other bit assets (Bit PPC) in the event the BitAsset lost the interest of the market participants. This would result in a major problem where one "stale" bit asset that was still insured would be very insecure.
Excellent idea.
What happens to the BitUSD in the fund over time? Does it just stay there or does it slowly burn to keep it from accumulating forever?
-
Fund please.
XTSLYifrtHXLvYjMrDYF2djApYYNRMcurcp5
Thanks!
-
Sending the market fees (USD) to an insurance fund rather than converting them to XTS and burning them as dividends or paying the funds to delegates would provide a more controlled way of insuring against price volatility.
Over time the network would end up accumulating a large balance of USD that it could hold in reserve. If something happened then this reserve could be drained or even "go negative" for a while. So if you assume a reasonable spread on market orders (buy/sell overlap) then it is very likely the market will have a large and growing balance of USD.
When a short is unable to cover, the network can just give up some of its own USD instead.
So in a major price correction you just have to ask yourself what percent of the USD will be "uncovered", how long will it take the network to accumulate that percent, and how likely is it to occur.
The event is most likely to occur as a result of an "attack" where someone tries to manipulate the price. Increasing the reward for the attack by printing XTS makes the attack more likely. If you can trigger a margin call and insure that your bid is very low then the potential printing is unbounded.
I think having BitUSD "unbacked" after such an event may be better at discouraging the attack. The attackers prize would thus be limited to collecting the margin rather than printing unlimited XTS. The market peg might still hold even with surplus USD floating around until enough fees are collected to take it out of circulation.
So... I am going to propose the following changes:
1) USD fees are never converted to XTS to be burned, they are kept as insurance on black swans
2) If the "current price" is greater than max bid, then we average in max bid. If the current price is less than min ask, then we average in min ask. This has the effect of using the median because you are essentially truncating outliers and limiting the effect a single block can have on the average price.
Someone pointed out that FDIC insurance (printing XTS) may be ok for some bit assets (USD) it would be a major problem for other bit assets (Bit PPC) in the event the BitAsset lost the interest of the market participants. This would result in a major problem where one "stale" bit asset that was still insured would be very insecure.
This is actually much closer to how the FDIC works. I didn't want to point it out, but bytemaster's original analogy was for TARP. The US FDIC works by all depositors and banks paying an insurance premium which pays out in the case of a failure. I like it.
-
Sending the market fees (USD) to an insurance fund rather than converting them to XTS and burning them as dividends or paying the funds to delegates would provide a more controlled way of insuring against price volatility.
Over time the network would end up accumulating a large balance of USD that it could hold in reserve. If something happened then this reserve could be drained or even "go negative" for a while. So if you assume a reasonable spread on market orders (buy/sell overlap) then it is very likely the market will have a large and growing balance of USD.
When a short is unable to cover, the network can just give up some of its own USD instead.
So in a major price correction you just have to ask yourself what percent of the USD will be "uncovered", how long will it take the network to accumulate that percent, and how likely is it to occur.
The event is most likely to occur as a result of an "attack" where someone tries to manipulate the price. Increasing the reward for the attack by printing XTS makes the attack more likely. If you can trigger a margin call and insure that your bid is very low then the potential printing is unbounded.
I think having BitUSD "unbacked" after such an event may be better at discouraging the attack. The attackers prize would thus be limited to collecting the margin rather than printing unlimited XTS. The market peg might still hold even with surplus USD floating around until enough fees are collected to take it out of circulation.
So... I am going to propose the following changes:
1) USD fees are never converted to XTS to be burned, they are kept as insurance on black swans
2) If the "current price" is greater than max bid, then we average in max bid. If the current price is less than min ask, then we average in min ask. This has the effect of using the median because you are essentially truncating outliers and limiting the effect a single block can have on the average price.
Someone pointed out that FDIC insurance (printing XTS) may be ok for some bit assets (USD) it would be a major problem for other bit assets (Bit PPC) in the event the BitAsset lost the interest of the market participants. This would result in a major problem where one "stale" bit asset that was still insured would be very insecure.
Very glad that you're thinking of this direction. Sending USD fees to a fund (operated by the network) than buying XTS to burn not only helps the security, it also helps to make the bitUSD an asset with dividends which I think is important for the success of bitUSD. I like this idea.
-
Very glad that you're thinking of this direction. Sending USD fees to a fund (operated by the network) than buying XTS to burn not only helps the security, it also helps to make the bitUSD an asset with dividends which I think is important for the success of bitUSD. I like this idea.
It does not make it an asset with dividends, it just goes from the users' bank account to the DAC's bank account and the market peg will continue to function like it always did.
What it does do is build up some capital inside the DAC which may become like AAPL's cash hoard. This value "on the balance sheet" is still accumulated to BTS X shareholders because for the BitUSD to exist on our balance sheet, someone has tied up 2x the value in collateral somewhere which means it is "out of circulation".
As crazy as it may sound, it actually results in a 2x ROI for BTSX to hold USD reserves rather than sell them. You don't see it in the share supply, but I suspect we could create a "virtual share supply" calculation that calculates the XTS held in collateral for the USD in the fund and "subtract" it from the XTS supply.
It does mean that some shorts will NEVER be able to cover at any price because the USD is "out of circulation". This shouldn't really be a problem, all users are entitled to hold their USD so a short has to increase their bid for USD to get priority.
Boy the economics of this are complex.... holding USD is a bet against XTS, but requires someone else to make an equal and opposite leveraged bet for XTS. The result is the same as increasing the demand for XTS and burning it as dividends in terms of how it should impact the XTS price.
-
So now we have global self-insured decentralized autonomous bank with hard-coded reserves and tranparent ledgers... I think I feel a glitch in the matrix...
-
Somewhere in alts attack I managed to pick up 21Mil USD. If they're useful somewhere let me know, I'll send them.
-
It does mean that some shorts will NEVER be able to cover at any price because the USD is "out of circulation". This shouldn't really be a problem, all users are entitled to hold their USD so a short has to increase their bid for USD to get priority.
Not never, they will be able to cover in the event the insurance fund needs to be used up. - but that is theoretic discussion...
In practice those would be shorts that the price has moved a lot in their favor; they can close that position and open a new one at the current price, freeing most of their collateral.
As I said in my previous post I like that plan a lot - one question tho. You plan to use only fees generated when somebody does not have BTSX, so he pays in bitUSD, correct? If this is indeed the case, I fear this can be too slow of a accumulation (as in fund growth) at the beginning. It would be nice if you can think of a way to make it faster at launch/when the fund is low, without increasing too much business logic/code complexity of course.
-
It does mean that some shorts will NEVER be able to cover at any price because the USD is "out of circulation". This shouldn't really be a problem, all users are entitled to hold their USD so a short has to increase their bid for USD to get priority.
Not never, they will be able to cover in the event the insurance fund needs to be used up. - but that is theoretic discussion...
In practice those would be shorts that the price has moved a lot in their favor; they can close that position and open a new one at the current price, freeing most of their collateral.
As I said in my previous post I like that plan a lot - one question tho. You plan to use only fees generated when somebody does not have BTSX, so he pays in bitUSD, correct? If this is indeed the case, I fear this can be too slow of a accumulation (as in fund growth) at the beginning. It would be nice if you can think of a way to make it faster at launch/when the fund is low, without increasing too much business logic/code complexity of course.
MARKET FEES from bid/ask overlap will be much higher than TRANSFER fees paid. Perhaps as high as 1% of trade volume.
-
It does mean that some shorts will NEVER be able to cover at any price because the USD is "out of circulation". This shouldn't really be a problem, all users are entitled to hold their USD so a short has to increase their bid for USD to get priority.
Not never, they will be able to cover in the event the insurance fund needs to be used up. - but that is theoretic discussion...
In practice those would be shorts that the price has moved a lot in their favor; they can close that position and open a new one at the current price, freeing most of their collateral.
As I said in my previous post I like that plan a lot - one question tho. You plan to use only fees generated when somebody does not have BTSX, so he pays in bitUSD, correct? If this is indeed the case, I fear this can be too slow of a accumulation (as in fund growth) at the beginning. It would be nice if you can think of a way to make it faster at launch/when the fund is low, without increasing too much business logic/code complexity of course.
MARKET FEES from bid/ask overlap will be much higher than TRANSFER fees paid. Perhaps as high as 1% of trade volume.
OK that's what you call 'market fees' - good than. That should be enough.
On another note we have an argument in which you claimed those are not fees... :)
-
https://www.youtube.com/watch?v=Pb-K2tXWK4w
1) You can now increase the call price of a cover order
(5% fee still applies)
2) Switched to 1 hour moving price average rather than feeds
3) You now need 51 delegates to publish a feed (up from 3)
4) The client now warns you if you are making a bid or ask that is 5% worse than best price
GUI's hosted by our UI dev Valentine:
http://valzav.com/BitSharesXT.dmg
https://www.dropbox.com/s/0adsrsaw28v9zbd/BitSharesXT-0.0.15.exe
md5's:
Windows: a1fd771b49d22ff4ebc15c9a80a6ac28
OSX (.dmg): 0d66cbbfb05f37c8d457b00daa37dab1
yesterday i created 20 usd with 84 xts , is it a bug ?
{"type":"ask_op_type","data":{"amount":4200000,"ask_index":{"order_price":{"ratio":"0.047619047619047616","quote_asset_id":22,"base_asset_id":0},"owner":"XTS7wvWjSuuFszcVHis3PcAtPjMJTjuWWeYb"}}}
{"type":"short_op_type","data":{"amount":4200000,"short_index":{"order_price":{"ratio":"0.047619047619047616","quote_asset_id":22,"base_asset_id":0},"owner":"XTS4ukE6dmDYkp3fxEKmtHRm3f3M4VN6579c"}}}
Transaction #dffe91ef
-
crosposting:
Bitcoin price flash crashes to $451 on BitFinex due to margin calls
https://bitsharestalk.org/index.php?topic=7019.msg93442#msg93442
-
@alt: so all is fine now? market is still safe?
no, control the average price to higher is still very quickly, only need 1 block.
control to low price is more difficult.
In fact, this is not a big problem, we can get the medium price just like feed price, sort and use the middle price.
and use a time more than 1 hour.
what I am worried about is the rule:
1. margin call can create bts, this can be use to attack the whole system. I still prefer just clear the short position can't be cover.
2. the short price is limit, if the limit is too lower for some reason, like a sudden price grow of bts, nobody ask with a lower price, and no asset can be create.
I have post for my thought here.
I have no doubt that market consensus will make bitusd track the price of USD.
but the rules with leak will break the market consensus.
the rules with too many limit will stop the market consensus.
I think we should make a rule with less limit, and without leak.
here is my solution.
the main different is the short bitusd is separate from bid XTS.
for example:
If I want to short 100 bitUSD with price 1bitUSD/xts, I need to freeze 200 XTS, and I can get 100 bitUSD immediately.
then I can usd these bitUSD to buy XTS with a different price, for bit order. maybe 0.5 bitUSD/XTS or whatever, there is no limit for the price of bid order.
the same, there is no limit for the price of ask order. there is no limit for the market depth check.
the key is to limit the short price.
the maximum short price is coming from the minimum matched bid price of latest blocks(maybe latest 24*60*6 blocks).
at the beginning there is no matched bid price, we can set a safety initial limit price, come from the central trade market, like 0.01USD/XTS.
What are your thoughts on bytemaster's latest revision?
-
It does not make it an asset with dividends, it just goes from the users' bank account to the DAC's bank account and the market peg will continue to function like it always did.
What it does do is build up some capital inside the DAC which may become like AAPL's cash hoard. This value "on the balance sheet" is still accumulated to BTS X shareholders because for the BitUSD to exist on our balance sheet, someone has tied up 2x the value in collateral somewhere which means it is "out of circulation".
As crazy as it may sound, it actually results in a 2x ROI for BTSX to hold USD reserves rather than sell them. You don't see it in the share supply, but I suspect we could create a "virtual share supply" calculation that calculates the XTS held in collateral for the USD in the fund and "subtract" it from the XTS supply.
It does mean that some shorts will NEVER be able to cover at any price because the USD is "out of circulation". This shouldn't really be a problem, all users are entitled to hold their USD so a short has to increase their bid for USD to get priority.
Boy the economics of this are complex.... holding USD is a bet against XTS, but requires someone else to make an equal and opposite leveraged bet for XTS. The result is the same as increasing the demand for XTS and burning it as dividends in terms of how it should impact the XTS price.
Well, I meant that it has the effect like an asset with dividends as some shorts will never be covered. It's something like I burn some BTC and all the BTC holders will benefit. As this burning happens continuously it's quite similar with dividends. The recycle of the fund is like a negative dividends but it happens much less so the overall effect is like positive dividends. Anyway I think it's good to make an asset backed with something like this to avoid its price going to zero.
-
^^ no, burning bitassets does not have the same effect as burning a fixed-supply (or fixed rate of creation) currency. The locked up BitUSD ultimately results in the price of BTSX going up, not bitUSD
-
https://www.youtube.com/watch?v=Pb-K2tXWK4w
1) You can now increase the call price of a cover order
(5% fee still applies)
2) Switched to 1 hour moving price average rather than feeds
3) You now need 51 delegates to publish a feed (up from 3)
4) The client now warns you if you are making a bid or ask that is 5% worse than best price
GUI's hosted by our UI dev Valentine:
http://valzav.com/BitSharesXT.dmg
https://www.dropbox.com/s/0adsrsaw28v9zbd/BitSharesXT-0.0.15.exe
md5's:
Windows: a1fd771b49d22ff4ebc15c9a80a6ac28
OSX (.dmg): 0d66cbbfb05f37c8d457b00daa37dab1
yesterday i created 20 usd with 84 xts , is it a bug ?
{"type":"ask_op_type","data":{"amount":4200000,"ask_index":{"order_price":{"ratio":"0.047619047619047616","quote_asset_id":22,"base_asset_id":0},"owner":"XTS7wvWjSuuFszcVHis3PcAtPjMJTjuWWeYb"}}}
{"type":"short_op_type","data":{"amount":4200000,"short_index":{"order_price":{"ratio":"0.047619047619047616","quote_asset_id":22,"base_asset_id":0},"owner":"XTS4ukE6dmDYkp3fxEKmtHRm3f3M4VN6579c"}}}
Transaction #dffe91ef
This seems like it should have created 2 USD not 20. Can you post your transaction history?
-
I'm glad you're on our side.
+5%
me2
+5% for Alt
-
Assert Exception
>>> blockchain_market_order_book USD BTC
BIDS (* Short Order) | ASKS
TOTAL QUANTITY PRICE | PRICE QUANTITY TOTAL COLLATERAL
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.0000 USD 1.00000000 BTC 1.000000000000 USD |
Last Error: Assert Exception (10)
!"Not Implemented":
Details:
10 assert_exception: Assert Exception
!"Not Implemented":
{}
th_a market_records.cpp:65 get_quantity
>>> about
{
"bitshares_toolkit_revision": "c6a3c16aa297c977d3f5de61194f30e1af186e8c",
"bitshares_toolkit_revision_age": "34 hours ago",
"fc_revision": "8468f392cebb291587e0d87cdf9bef9bf167acfc",
"fc_revision_age": "80 hours ago",
"compile_date": "compiled on Aug 16 2014 at 20:43:39"
}
-
@alt: so all is fine now? market is still safe?
no, control the average price to higher is still very quickly, only need 1 block.
control to low price is more difficult.
In fact, this is not a big problem, we can get the medium price just like feed price, sort and use the middle price.
and use a time more than 1 hour.
what I am worried about is the rule:
1. margin call can create bts, this can be use to attack the whole system. I still prefer just clear the short position can't be cover.
2. the short price is limit, if the limit is too lower for some reason, like a sudden price grow of bts, nobody ask with a lower price, and no asset can be create.
I have post for my thought here.
I have no doubt that market consensus will make bitusd track the price of USD.
but the rules with leak will break the market consensus.
the rules with too many limit will stop the market consensus.
I think we should make a rule with less limit, and without leak.
here is my solution.
the main different is the short bitusd is separate from bid XTS.
for example:
If I want to short 100 bitUSD with price 1bitUSD/xts, I need to freeze 200 XTS, and I can get 100 bitUSD immediately.
then I can usd these bitUSD to buy XTS with a different price, for bit order. maybe 0.5 bitUSD/XTS or whatever, there is no limit for the price of bid order.
the same, there is no limit for the price of ask order. there is no limit for the market depth check.
the key is to limit the short price.
the maximum short price is coming from the minimum matched bid price of latest blocks(maybe latest 24*60*6 blocks).
at the beginning there is no matched bid price, we can set a safety initial limit price, come from the central trade market, like 0.01USD/XTS.
What are your thoughts on bytemaster's latest revision?
The nice thing about it is it protects the interests of Investors in the network by supporting BTSX price and tending to increase ROI. But does it really solve the underlying problem? If the "insurance" fund went negative (admittedly a small probability) then what? Would more BTSX have to be printed if a problem event occurred? Another drawback is that it also makes it much more complex to understand the economics, as Bytemaster said. It would make it harder for market participants to properly value BTSX.
I don't have anywhere near a complete understanding of the BTSX market system, but isn't the root of the problem an imperfection in the functioning of the market? With proper collateral requirements and price change restrictions or temporary halts, why couldn't the collateral for shorts always be made to be sufficient for covering them?
-
this is correct:
default (unlocked) >>> blockchain_market_order_book
quote_symbol: BTC
base_symbol: BTSX
this is backwards:
default (unlocked) >>> wallet_market_order_list
base_symbol: BTC
quote_symbol: BTSX
-
https://www.youtube.com/watch?v=Pb-K2tXWK4w
1) You can now increase the call price of a cover order
(5% fee still applies)
2) Switched to 1 hour moving price average rather than feeds
3) You now need 51 delegates to publish a feed (up from 3)
4) The client now warns you if you are making a bid or ask that is 5% worse than best price
GUI's hosted by our UI dev Valentine:
http://valzav.com/BitSharesXT.dmg
https://www.dropbox.com/s/0adsrsaw28v9zbd/BitSharesXT-0.0.15.exe
md5's:
Windows: a1fd771b49d22ff4ebc15c9a80a6ac28
OSX (.dmg): 0d66cbbfb05f37c8d457b00daa37dab1
yesterday i created 20 usd with 84 xts , is it a bug ?
{"type":"ask_op_type","data":{"amount":4200000,"ask_index":{"order_price":{"ratio":"0.047619047619047616","quote_asset_id":22,"base_asset_id":0},"owner":"XTS7wvWjSuuFszcVHis3PcAtPjMJTjuWWeYb"}}}
{"type":"short_op_type","data":{"amount":4200000,"short_index":{"order_price":{"ratio":"0.047619047619047616","quote_asset_id":22,"base_asset_id":0},"owner":"XTS4ukE6dmDYkp3fxEKmtHRm3f3M4VN6579c"}}}
Transaction #dffe91ef
This seems like it should have created 2 USD not 20. Can you post your transaction history?
When you take into account the precision difference between USD and XTS 20 looks like it is the right answer.. I think XTS has 5 digits and USD has 4
-
sorry, for language reason, I have not understand the algorithm to get the average price.
I am trying to learning it.
@alt: so all is fine now? market is still safe?
no, control the average price to higher is still very quickly, only need 1 block.
control to low price is more difficult.
In fact, this is not a big problem, we can get the medium price just like feed price, sort and use the middle price.
and use a time more than 1 hour.
what I am worried about is the rule:
1. margin call can create bts, this can be use to attack the whole system. I still prefer just clear the short position can't be cover.
2. the short price is limit, if the limit is too lower for some reason, like a sudden price grow of bts, nobody ask with a lower price, and no asset can be create.
I have post for my thought here.
I have no doubt that market consensus will make bitusd track the price of USD.
but the rules with leak will break the market consensus.
the rules with too many limit will stop the market consensus.
I think we should make a rule with less limit, and without leak.
here is my solution.
the main different is the short bitusd is separate from bid XTS.
for example:
If I want to short 100 bitUSD with price 1bitUSD/xts, I need to freeze 200 XTS, and I can get 100 bitUSD immediately.
then I can usd these bitUSD to buy XTS with a different price, for bit order. maybe 0.5 bitUSD/XTS or whatever, there is no limit for the price of bid order.
the same, there is no limit for the price of ask order. there is no limit for the market depth check.
the key is to limit the short price.
the maximum short price is coming from the minimum matched bid price of latest blocks(maybe latest 24*60*6 blocks).
at the beginning there is no matched bid price, we can set a safety initial limit price, come from the central trade market, like 0.01USD/XTS.
What are your thoughts on bytemaster's latest revision?
-
except the average price.
I think the other important thing is about the method to create asset.
for safe reason, we have to set a maximum price limit for short.
for now, the short price means two things:
1. how much XTS do you need to freeze , for lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.
In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need set a limit for the second thing.
but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.
So I prefer to change the short operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.
-
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high
// TODO: rename avg_price_24h to average_price_1h
market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);
// limit the maximum movement rate of the price.
if( _current_bid->get_price() > min_cover_ask )
market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
else
market_stat->avg_price_24h.ratio += min_cover_ask.ratio;
if( _current_ask->get_price() < max_short_bid )
market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
else
market_stat->avg_price_24h.ratio += max_short_bid.ratio;
market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);
-
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high
// TODO: rename avg_price_24h to average_price_1h
market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);
// limit the maximum movement rate of the price.
if( _current_bid->get_price() > min_cover_ask )
market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
else
market_stat->avg_price_24h.ratio += min_cover_ask.ratio;
if( _current_ask->get_price() < max_short_bid )
market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
else
market_stat->avg_price_24h.ratio += max_short_bid.ratio;
market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);
When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.
In other words, the average only counts the average of the spread on each block after filling all orders.
-
+5%
-
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high
// TODO: rename avg_price_24h to average_price_1h
market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);
// limit the maximum movement rate of the price.
if( _current_bid->get_price() > min_cover_ask )
market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
else
market_stat->avg_price_24h.ratio += min_cover_ask.ratio;
if( _current_ask->get_price() < max_short_bid )
market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
else
market_stat->avg_price_24h.ratio += max_short_bid.ratio;
market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);
When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.
In other words, the average only counts the average of the spread on each block after filling all orders.
Actually, this does make me aware of a potential bug. It may be the case that this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L324 should come AFTER this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L390
I will verify with bytemaster.
-
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high
// TODO: rename avg_price_24h to average_price_1h
market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);
// limit the maximum movement rate of the price.
if( _current_bid->get_price() > min_cover_ask )
market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
else
market_stat->avg_price_24h.ratio += min_cover_ask.ratio;
if( _current_ask->get_price() < max_short_bid )
market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
else
market_stat->avg_price_24h.ratio += max_short_bid.ratio;
market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);
When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.
In other words, the average only counts the average of the spread on each block after filling all orders.
but when somebody is attack, the high bid maybe not been filled. for example, the attacker maybe can fill all ask order under price 100USD/XTS
-
I think the average price is still not hard to manipulate
current_bid->get_price() maybe very high
// TODO: rename avg_price_24h to average_price_1h
market_stat->avg_price_24h.ratio *= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR-1);
// limit the maximum movement rate of the price.
if( _current_bid->get_price() > min_cover_ask )
market_stat->avg_price_24h.ratio += _current_bid->get_price().ratio;
else
market_stat->avg_price_24h.ratio += min_cover_ask.ratio;
if( _current_ask->get_price() < max_short_bid )
market_stat->avg_price_24h.ratio += _current_ask->get_price().ratio;
else
market_stat->avg_price_24h.ratio += max_short_bid.ratio;
market_stat->avg_price_24h.ratio /= (BTS_BLOCKCHAIN_BLOCKS_PER_HOUR+1);
When this section of code is called, all matching orders should have been filled. So any high bids would have been filled, leaving current_bid at this point to be the highest bid which no longer matches any asks.
In other words, the average only counts the average of the spread on each block after filling all orders.
but when somebody is attack, the high bid maybe not been filled. for example, the attacker maybe can fill all ask order under price 100USD/XTS
This is a good point if you can completely control the order book you are right.... we need to guard it on both sides.
-
To have the highest bid be that high would be incredibly expensive for the attacker as he would have to pay that price for the entire depth of the market. He would also have to use USD rather than shorting because you cannot create a short oder at prices that high.
-
Actually, this does make me aware of a potential bug. It may be the case that this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L324 should come AFTER this line: https://github.com/BitShares/bitshares_toolkit/blob/03dbac9fd674aae29d50cdab2685318c47c89667/libraries/blockchain/market_engine.cpp#L390
I will verify with bytemaster.
This doesn't look like a bug in code that will affect validation, though it may effect how price charts are rendered eventually. I will refactor the code to correct our price histories, but it shouldn't result in a hard fork.
-
except the average price.
I think the other important thing is about the method to create asset.
for safe reason, we have to set a maximum price limit for short.
for now, the short price means two things:
1. how much XTS do you need to freeze , for lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.
In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need set a limit for the second thing.
but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.
So I prefer to change the short operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.
another advantage is we don't need the init feed price from delegate. wait all 101 delegates to input the feed price for all 25 assets is not an easy work.
we can just set a safe price(very low) limit at the source code.
because these price don't need very exactly. It have no influence on the bid price, just reduce the issue speed at the first 360 blocks.
-
Maybe we could think bitusd is important than btsx.
This is wrong. If USA begin monetary reform，then bitusd will reform again.
So btsx is important .
bitusd can be roll-back like nxt.
-
except the average price.
I think the other important thing is about the method to create asset.
for safe reason, we have to set a maximum price limit for short.
for now, the short price means two things:
1. how much XTS do you need to freeze , for lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.
In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need set a limit for the second thing.
but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.
So I prefer to change the short operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.
another advantage is we don't need the init feed price from delegate. wait all 101 delegates to input the feed price for all 25 assets is not an easy work.
we can just set a safe price(very low) limit at the source code.
because these price don't need very exactly. It have no influence on the bid price, just reduce the issue speed at the first 360 blocks.
another advantage
I have some XTS, now I want to buy something with bitUSD, what should I do?
for now, I have to short first, than ask. I have to wait for a good price.
with the new rule, I just need to lend bitUSD from system with my backup XTS, I don't need to trade to somebody else.
It will be very easy to use bitUSD.
-
except the average price.
I think the other important thing is about the method to create asset.
for safe reason, we have to set a maximum price limit for short.
for now, the short price means two things:
1. how much XTS do you need to freeze , for lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.
In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need set a limit for the second thing.
but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.
So I prefer to change the short operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.
If the price of XTS double, I think the delegate's can update their feeds to start, maybe I did not get your idea?
-
I have some XTS, now I want to buy something with bitUSD, what should I do?
for now, I have to short first, than ask. I have to wait for a good price.
with the new rule, I just need to lend bitUSD from system with my backup XTS, I don't need to trade to somebody else.
It will be very easy to use bitUSD.
Just sell your XTS for BitUSD... no need to short first.
-
I have some XTS, now I want to buy something with bitUSD, what should I do?
for now, I have to short first, than ask. I have to wait for a good price.
with the new rule, I just need to lend bitUSD from system with my backup XTS, I don't need to trade to somebody else.
It will be very easy to use bitUSD.
Just sell your XTS for BitUSD... no need to short first.
no, I want to short bitUSD....
I don't want to buy it now....
If I can, I will always lend bitUSD from the system ;D
-
except the average price.
I think the other important thing is about the method to create asset.
for safe reason, we have to set a maximum price limit for short.
for now, the short price means two things:
1. how much XTS do you need to freeze , for lend the assets from BTS bank.
2. how much XTS can you buy , with these assets you just lend out.
In fact , we only want to set a limit for the first thing, how much you can lend from the bank.
we don't need set a limit for the second thing.
but now, we have limit both. so something maybe not work find. for example:
at the first day, delegate set a price about 0.1 bitgold/XTS. we have more than 25 assets, maybe nobody short bitgold success.no bitgold issued.
at the second day, the price of XTS is double.
what situation we will have to face? people want to sell/bid/short XTS at price 0.2biggod/XTS, but no bitgold issued, so nobody can bid. and nobody can short, from the system limit of the price, you can only short at price 0.13bitgod/XTS. If the price never down, the trade maybe never active.
So I prefer to change the short operation to only issue asset, without must bid XTS immediately. you can bid anytime.
and some other advantages with this change.
for example, I think USD will up from GOLD. so I can lend bitGOLD, and use this bigGOLD to buy USD directly.
If the price of XTS double, I think the delegate's can update their feeds to start, maybe I did not get your idea?
once the feed price is success(maybe 50 delegate now?) input, the limit price will change to use the average price instead of feed price.