BitShares Forum
Main => Technical Support => Topic started by: xeroc on October 09, 2015, 02:24:47 pm
-
(If you would like to get notified on changes, please subscribe to this topic!)
Hey there,
I pushed another update for the python-graphene library including a price feed script.
Documentation:
http://python-graphenelib.readthedocs.org/en/latest/pricefeed.html
Sources:
http://github.com/xeroc/python-graphenelib
Requirements
- Python3
easy_install-3.4 install autobahn
easy_install-3.4 install requests
easy_install-3.4 install prettytable
easy_install-3.4 install numpy
Installation:
python3 setup.py install --userNote: Do to recent changes, everyone using the scripts is required to reinstall the library too!
Meta:
+ Input is welcome
+ Contributions are welcome
+ Sofware provided AS-IS (see license)
-
Subscribed.. thanks xeroc! +5%
-
+5%
thanks xeroc!
-
thanks xeroc!
+5%
-
Forgot to mention that the current version requires manual confirmation of every feed. Hence you cant run it in a cronjob
-
thanks!!
+5%
-
As per request from the testnet thread I swapped quote and base for the core exchange rate price .. even though I am pretty certain about that it doesn't change anything .. 10 core/asset equals 0.1 asset/core
no matter how you do it :)
-
Having trouble getting feeds going. Using https://python-graphenelib.readthedocs.org/en/latest/pricefeed.html
In launching the wallet I get the following error:
:~/graphene/programs/cli_wallet# ./cli_wallet -w test_wallet --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -H 127.0.0.1:8092 -s "127.0.0.1:8090"
Logging RPC to file: logs/rpc/rpc.log
638120ms th_a main.cpp:114 main ] key_to_wif( committee_private_key ): 5...W
638121ms th_a main.cpp:118 main ] nathan_pub_key: GPH...V
638121ms th_a main.cpp:119 main ] key_to_wif( nathan_private_key ): 5...3
638122ms th_a main.cpp:166 main ] wdata.ws_server: 127.0.0.1:8090
10 assert_exception: Assert Exception
uri.substr(0,3) == "ws:":
{}
th_a websocket.cpp:600 connect
{"uri":"127.0.0.1:8090"}
th_a websocket.cpp:621 connect
I have witness running with this command:
./witness_node --rpc-endpoint "127.0.0.1:8090" --genesis-json oct5-genesis.json -d oct5 -s "104.236.51.238:2005" -s "104.236.144.84:1776" --witness-id '"1.6.24"' --private-key '["GPH...t","5...5"]'
I assume the issue is where I define -s "<ip-of-full/witness-node:port>" from the directions:
programs/cli_wallet/cli_wallet --rpc-http-endpoint="127.0.0.1:8092" -s "<ip-of-full/witness-node:port>"
but I can't find anything that makes it happy here.
-
I assume the issue is where I define -s "<ip-of-full/witness-node:port>" from the directions:
programs/cli_wallet/cli_wallet --rpc-http-endpoint="127.0.0.1:8092" -s "<ip-of-full/witness-node:port>"
but I can't find anything that makes it happy here.
I use this
./cli_wallet -w oct5_w0 --chain-id 60e21871125ea9995fe498b7f68a87a85c6583725ea5448f6fd969c59a37df83 -s ws://127.0.0.1:8090 -H 127.0.0.1:8092
That did it. Thank you Spectral.
-
it complains "No module named 'grapheneapi'"
python3 pricefeeds.py
Traceback (most recent call last):
File "pricefeeds.py", line 44, in <module>
from grapheneapi import GrapheneAPI
ImportError: No module named 'grapheneapi'
-
it complains "No module named 'grapheneapi'"
python3 pricefeeds.py
Traceback (most recent call last):
File "pricefeeds.py", line 44, in <module>
from grapheneapi import GrapheneAPI
ImportError: No module named 'grapheneapi'
You need to either install grapheneapi with
python3 setup.py install --user
or copy pricefeeds.py and config.py to the python-graphenelib directory and run it from there.
-
thanks . It works
-
could please explain the usage of following parameters in red?
################################################################################
## RPC-client connection information (required)
################################################################################
host = "localhost"
port = 8092
user = ""
passwd = ""
unlock = ""
################################################################################
## Fine tuning
################################################################################
discount = 0.995
core_exchange_factor = 1.05 # 5% surplus if paying fees in bitassets
minValidAssetPriceInBTC = 0.00001
change_min = 0.5
-
commit d6b19bc465fbd80021c20e814286cb4d27f8118d
Author: Fabian Schuh <mail@xeroc.org>
Date: Wed Oct 14 12:54:00 2015 +0200
Price Feed Script Update
+ added configuration variables to disable/enable exchanges
New config Variables:
## Enable exchanges
enable_yunbi = True
enable_btc38 = True
enable_bter = False
enable_polonie = True
enable_bittrex = True
enable_btcavg = True
-
I just merged a pull request of forum member "alt" which allows to define the collateral and short squeeze ratio.
Plese update the code and add the new configuration parameters
-
I just merged a pull request of forum member "alt" which allows to define the collateral and short squeeze ratio.
Plese update the code and add the new configuration parameters
Is there a recommended default setting? I'm afraid I am not exactly sure what these parameters do.
-
I cant give a recommendation because I am not an economist ... every pro comes with a con
-
Can the new pull be disabled in the config?
I prefer a simple price feed. ( also I'm not an economist )
-
git reset 0ac7697
I recommend every witness publishing a price feed informs themsselves about the consequences of posting their prices feeds:
https://bitsharestalk.org/index.php/topic,19102.msg245609.html#msg245609
-
Can the new pull be disabled in the config?
I prefer a simple price feed. ( also I'm not an economist )
As a witness, you must understand the market engine. a bad parameter will break the peg.
All witness must publish these parameters,
My suggest is set short_squeeze_ratio between 1001 to 1100. this parameter is very important,
when it's 1100
SQP = FEED / 1.1
when it's 1050
SQP = FEED /1.05
(https://cloud.githubusercontent.com/assets/347290/10527599/5f634e44-735f-11e5-8a32-d66092379e92.JPG)
A margin call will occur any time the highest bid is less than the CALL PRICE and greater than SQP
FEED = Settlement Price
SWAN = DEBT / COLLATERAL - the point at which the network is insolvent.
CALL = SWAN * 1.75
SQP = FEED / 1.5
1.75 and 1.5 are specified as two parameters to the price feed.
If you would like the feed to provide additional protection to the shorts, then ask the witnesses to adjust their feed publishing scripts to use SQP of FEED / 1.1.
Just beware that the consequence of protecting the shorts against thin markets is the following:
1. Shorts will end up posting less collateral
2. Greater dependence upon the feed vs the market
3. If there are no bids above the SQP price then margin will not get called even if the Feed Price is below the Call price.
-
So setting short_squeeze_ratio to 1000
SQP = FEED / 1 = old feed price = no short_squeeze projection
If my noob economist calculations are correct
-
yes, you are right.
all witness please think about it, set short_squeeze_ratio between 1001 to 1100.
-
My economist first statement!
The short_squeeze_ratio is a mechanism to allow for the spread between bid and ask and help prevent forced settlement.
-
totally correct, 1.5 is unreasonable, please update it
My economist first statement!
The short_squeeze_ratio is a mechanism to allow for the spread between bid and ask and help prevent forced settlement.
-
Can the new pull be disabled in the config?
I prefer a simple price feed. ( also I'm not an economist )
As a witness, you must understand the market engine. a bad parameter will break the peg.
All witness must publish these parameters,
My suggest is set short_squeeze_ratio between 1001 to 1100. this parameter is very important,
when it's 1100
SQP = FEED / 1.1
when it's 1050
SQP = FEED /1.05
(https://cloud.githubusercontent.com/assets/347290/10527599/5f634e44-735f-11e5-8a32-d66092379e92.JPG)
A margin call will occur any time the highest bid is less than the CALL PRICE and greater than SQP
FEED = Settlement Price
SWAN = DEBT / COLLATERAL - the point at which the network is insolvent.
CALL = SWAN * 1.75
SQP = FEED / 1.5
1.75 and 1.5 are specified as two parameters to the price feed.
If you would like the feed to provide additional protection to the shorts, then ask the witnesses to adjust their feed publishing scripts to use SQP of FEED / 1.1.
Just beware that the consequence of protecting the shorts against thin markets is the following:
1. Shorts will end up posting less collateral
2. Greater dependence upon the feed vs the market
3. If there are no bids above the SQP price then margin will not get called even if the Feed Price is below the Call price.
Thanks for the info.
However I don't think this parameter should be DECIDED by witnesses, it's better to be set as a system parameter, and adjustable by committee proposals.
-
Can the new pull be disabled in the config?
I prefer a simple price feed. ( also I'm not an economist )
As a witness, you must understand the market engine. a bad parameter will break the peg.
All witness must publish these parameters,
My suggest is set short_squeeze_ratio between 1001 to 1100. this parameter is very important,
when it's 1100
SQP = FEED / 1.1
when it's 1050
SQP = FEED /1.05
(https://cloud.githubusercontent.com/assets/347290/10527599/5f634e44-735f-11e5-8a32-d66092379e92.JPG)
A margin call will occur any time the highest bid is less than the CALL PRICE and greater than SQP
FEED = Settlement Price
SWAN = DEBT / COLLATERAL - the point at which the network is insolvent.
CALL = SWAN * 1.75
SQP = FEED / 1.5
1.75 and 1.5 are specified as two parameters to the price feed.
If you would like the feed to provide additional protection to the shorts, then ask the witnesses to adjust their feed publishing scripts to use SQP of FEED / 1.1.
Just beware that the consequence of protecting the shorts against thin markets is the following:
1. Shorts will end up posting less collateral
2. Greater dependence upon the feed vs the market
3. If there are no bids above the SQP price then margin will not get called even if the Feed Price is below the Call price.
Thanks for the info.
However I don't think this parameter should be DECIDED by witnesses, it's better to be set as a system parameter, and adjustable by committee proposals.
+1
Witnesses should have no control over this parameter.
-
Thanks for the info.
However I don't think this parameter should be DECIDED by witnesses, it's better to be set as a system parameter, and adjustable by committee proposals.
Agree, in the "separation of powers,"
- Witnesses are supposed to be economically dumb but technically literate system administrators
- Committee members are supposed to balance economics and system performance
- Proxies are well informed members of the community
- Workers are technical experts in the system
this seems like a role for committee members to suggest and users to approve. Witnesses shouldn't be held accountable for their decisions on network parameters.
-
agree, include the three parameters: core_exchange_factor , maintenance_collateral_ratio, short_squeeze_ratio
Thanks for the info.
However I don't think this parameter should be DECIDED by witnesses, it's better to be set as a system parameter, and adjustable by committee proposals.
-
I just merged a pull request of forum member "alt" which allows to define the collateral and short squeeze ratio.
Plese update the code and add the new configuration parameters
I'm not seeing any new parameters.
################################################################################
## Fine tuning
################################################################################
discount = 0.995
core_exchange_factor = 1.05 # 5% surplus if paying fees in bitassets
minValidAssetPriceInBTC = 0.00001
change_min = 0.5
## Enable exchanges
-
here is the pull request:
https://github.com/pch957/python-graphenelib/commit/30cb48559fc1436ecf46ce64d371ca27e3b4d746
I just merged a pull request of forum member "alt" which allows to define the collateral and short squeeze ratio.
Plese update the code and add the new configuration parameters
I'm not seeing any new parameters.
################################################################################
## Fine tuning
################################################################################
discount = 0.995
core_exchange_factor = 1.05 # 5% surplus if paying fees in bitassets
minValidAssetPriceInBTC = 0.00001
change_min = 0.5
## Enable exchanges
-
I skrewed up my git repository while "cleanin up" ..
I agree with the protection and SQR to be defined by the witnesses even though I am not sure they are supposed to be the same for all markets.
Anyway. what I don't like to see is workers publishing price feeds .. even though that would make running a witness legally uncritical in most countries, it would complicated running a worker (since you now need to actually RUN somthing) + you'd have the legal problems too ..
-
yes, you are right.
all witness please think about it, set short_squeeze_ratio between 1001 to 1100.
my opinion is that higher could be acceptable (and actually preferred), but we are making the ratio to the wrong value (FEED instead of SWAN).
https://bitsharestalk.org/index.php/topic,19102.msg245969.html#msg245969
Since allowing a black swan is worse than allowing margin calls in an artificial short squeeze, I'd suggest a larger short_squeeze_ratio (1100). However, that number is kind of arbitrary since it isn't a function of collateralization.
-
I skrewed up my git repository while "cleanin up" ..
I agree with the protection and SQR to be defined by the witnesses even though I am not sure they are supposed to be the same for all markets.
Anyway. what I don't like to see is workers publishing price feeds .. even though that would make running a witness legally uncritical in most countries, it would complicated running a worker (since you now need to actually RUN somthing) + you'd have the legal problems too ..
I also agree that workers shouldn't be publishing price feeds. I think people are thinking committee members should propose a short squeeze ratio that is approved, like any other network parameter change, by the users. No different legal issues than changing fees and witnesses still publish feeds.
-
the question is , how much we can set short_squeeze_ratio to?
which is better? which is bad?
if witness set it to 1000%, all short position will force margin call, and sell at 10% price. I think it's bad.
if 500% is bad? if 200% is bad? if 150% is bad? what's the rule? do we need to set a hard code limit? what's the value?
will you short bitUSD if there is no limit?
in my opnion, 110% should be the hard code limit, if we don't protect short position, nobody dare to short, bitUSD die.
-
the question is , how much we can set short_squeeze_ratio to?
which is better? which is bad?
if witness set it to 1000%, all short position will force margin call, and sell at 10% price. I think it's bad.
if 500% is bad? if 200% is bad? if 150% is bad? what's the rule? do we need to set a hard code limit? what's the value?
will you short bitUSD if there is no limit?
in my opnion, 110% should be the hard code limit, if we don't protect short position, nobody dare to short, bitUSD die.
I don't think there is one economically "correct" answer since it depends on collateralization. Well collateralized markets can have it set much higher than lower collateralized markets. At this point, you have to go by "feel" and adjust accordingly. Or we can use the price feed script to publish a squeeze ratio that is a function of SWAN or average collateralization for each market.
Maybe 1.25xSWAN is a good number? That means:
1.25xSWAN_PRICE = FEED/SQR
SQR= (FEED/SWAN_PRICE) X .8
-
the question is , how much we can set short_squeeze_ratio to?
which is better? which is bad?
if witness set it to 1000%, all short position will force margin call, and sell at 10% price. I think it's bad.
if 500% is bad? if 200% is bad? if 150% is bad? what's the rule? do we need to set a hard code limit? what's the value?
will you short bitUSD if there is no limit?
in my opnion, 110% should be the hard code limit, if we don't protect short position, nobody dare to short, bitUSD die.
I don't think there is one economically "correct" answer since it depends on collateralization. Well collateralized markets can have it set much higher than lower collateralized markets. At this point, you have to go by "feel" and adjust accordingly. Or we can use the price feed script to publish a squeeze ratio that is a function of SWAN or average collateralization for each market.
Maybe 1.25xSWAN is a good number? That means:
1.25xSWAN_PRICE = FEED/SQR
SQR= (FEED/SWAN_PRICE) X .8
Has no one else here noticed that the market is broken? Adjusting the SQR to something more reasonable would be a start, at least it would minimize the damage.
Seriously, witnesses need to be paying attention to this.
-
I borrow 100 usd from bank, reserve my phone current worth 265 usd. now you grab my phone, sell it to 100 usd.
unbelivable.
so disapoint that all witness think I am wrong.they all admit to sell the phone to 100 usd
-
It is something we have talked about at length. At this point the consensus seems to be that we will trust BM, and not adjust just yet.
-
It is something we have talked about at length. At this point the consensus seems to be that we will trust BM, and not adjust just yet.
yes, all witness choose to trust BM, not think self.
you can do this is you want 1bitUSD=1.5 USD, until all bitUSD disapear.
-
It is something we have talked about at length. At this point the consensus seems to be that we will trust BM, and not adjust just yet.
yes, all witness choose to trust BM, not think self.
you can do this is you want 1bitUSD=1.5 USD, until all bitUSD disapear.
I cannot believe that this market is working as intended. If the issue is liquidity then perhaps people should place some bids. if given the choice between bitusd being $0.5 or $1.5 I will pick $1.5. It has only been a couple of days. I don't think we are in danger of all bitusd disappearing just yet. In fact people seem unwilling to sell it even at this inflated price.
I have a number of shorts open as well. I had to add margin to them today to ensure I wouldn't get margin called. I am no happier about the current state of the network than anyone else that is currently short.
-
It is something we have talked about at length. At this point the consensus seems to be that we will trust BM, and not adjust just yet.
yes, all witness choose to trust BM, not think self.
you can do this is you want 1bitUSD=1.5 USD, until all bitUSD disapear.
I cannot believe that this market is working as intended. If the issue is liquidity then perhaps people should place some bids. if given the choice between bitusd being $0.5 or $1.5 I will pick $1.5. It has only been a couple of days. I don't think we are in danger of all bitusd disappearing just yet. In fact people seem unwilling to sell it even at this inflated price.
I have a number of shorts open as well. I had to add margin to them today to ensure I wouldn't get margin called. I am no happier about the current state of the network than anyone else that is currently short.
The issue is not that no one is providing liquidity. The issue is that the market is set up wrong, so it can't support liquidity. If you all just wait for BM to tell you what to do then having more than one witness is a waste of money.
-
It is something we have talked about at length. At this point the consensus seems to be that we will trust BM, and not adjust just yet.
yes, all witness choose to trust BM, not think [for them]selfs.
you can do this is you want 1bitUSD=1.5 USD, until all bitUSD disapear.
+5% +5% +5% +5% +5% +5% +5% +5% +5% +5%
+5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5%
+5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5%
+5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5% +5%
.... +5%
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
It is a start..one guy not wanting all bitUSD to disappear at a time .
+5% +5%
voting for you only! at thispoint
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
I updated xeroc's feed script a few hours ago and submitted feeds with maximum_short_squeeze_ratio at 1100.. It was my understanding that it would help prevent calls, of which there seem to be an unprecedented amount of. Do I understand correctly?
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
I updated xeroc's feed script a few hours ago and submitted feeds with maximum_short_squeeze_ratio at 1100.. It was my understanding that it would help prevent calls, of which there seem to be an unprecedented amount of. Do I understand correctly?
Voting for you and expecting you to figure out why you did what you did.
...
2 witnesses included in my vote so far.
-
Why is there a SQP? Doesnt only forced settlement matter?
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
I updated xeroc's feed script a few hours ago and submitted feeds with maximum_short_squeeze_ratio at 1100.. It was my understanding that it would help prevent calls, of which there seem to be an unprecedented amount of. Do I understand correctly?
Voting for you and expecting you to figure out why you did what you did.
...
2 witnesses included in my vote so far.
Looks like rnglab is onboard also. You can see a handy listing of witness positions on the asset page.
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
I updated xeroc's feed script a few hours ago and submitted feeds with maximum_short_squeeze_ratio at 1100.. It was my understanding that it would help prevent calls, of which there seem to be an unprecedented amount of. Do I understand correctly?
Voting for you and expecting you to figure out why you did what you did.
...
2 witnesses included in my vote so far.
It tightens up SQP, helping prevent the walls from crumbling down.. right?
-
Why is there a SQP? Doesnt only forced settlement matter?
"A margin call will occur any time the highest bid is less than the CALL PRICE and greater than SQP"
https://bitsharestalk.org/index.php/topic,19102.0.html
-
I'm sorry guys. I can't move the feed price alone. I've updated to 110% from 150%. I will keep a close eye on it and move it back if needed.
I updated xeroc's feed script a few hours ago and submitted feeds with maximum_short_squeeze_ratio at 1100.. It was my understanding that it would help prevent calls, of which there seem to be an unprecedented amount of. Do I understand correctly?
Voting for you and expecting you to figure out why you did what you did.
...
2 witnesses included in my vote so far.
Looks like rnglab is onboard also. You can see a handy listing of witness positions on the asset page.
checked - I will trust that!
3 witnesses
-
you should vote for me, delegate.baozi
-
you should vote for me, delegate.baozi
voting now... but shouldn't you make a committee account as well? so we can change this nonsense once...and hopefully for ever?
-
thanks
I'll apply commitee account when I can understand the whole system more better, not now.
you should vote for me, delegate.baozi
voting now... but shouldn't you make a committee account as well? so we can change this nonsense once...and hopefully for ever?
-
thanks
I'll apply commitee account when I can understand the whole system more better, not now.
you should vote for me, delegate.baozi
voting now... but shouldn't you make a committee account as well? so we can change this nonsense once...and hopefully for ever?
ohh you do not get the whole system as well?
That is indeed said.
One of the smartest around here has no clue how to change the system...
Good job BM... not only reinventing something that does not need reinventing and making a disaster out of it, but making it completely un-clear how everything works.
-
thanks
I'll apply commitee account when I can understand the whole system more better, not now.
you should vote for me, delegate.baozi
voting now... but shouldn't you make a committee account as well? so we can change this nonsense once...and hopefully for ever?
ohh you do not get the whole system as well?
That is indeed said.
One of the smartest around here has no clue how to change the system...
Good job BM... not only reinventing something that does not need reinventing and making a disaster out of it, but making it completely un-clear how everything works.
don't blame BM, I have not spent much time at BTS2.0 because of my personal business and my poor English.
I just begin to learn it when BTS2.0 have already launched.
-
thanks
I'll apply commitee account when I can understand the whole system more better, not now.
you should vote for me, delegate.baozi
voting now... but shouldn't you make a committee account as well? so we can change this nonsense once...and hopefully for ever?
ohh you do not get the whole system as well?
That is indeed said.
One of the smartest around here has no clue how to change the system...
Good job BM... not only reinventing something that does not need reinventing and making a disaster out of it, but making it completely un-clear how everything works.
don't blame BM, I have not spent much time at BTS2.0 because of my personal business and my poor English.
I just begin to learn it when BTS2.0 have already launched.
Good. I will blame... myself for not being in his head.
-
I think this is not a problem if shorts have HIGH COLLATERAL. YOU NEED MORE THAN 2Xs COLLTERAL. Try it out for yourself.
The biggest immediate problem now is that the witnesses are forcing those shorts to cover at 150% of feed price instead of near the actual value. Are only 3 witnesses paying attention?
-
I think this is not a problem if shorts have HIGH COLLATERAL. YOU NEED MORE THAN 2Xs COLLTERAL. Try it out for yourself.
The biggest immediate problem now is that the witnesses are forcing those shorts to cover at 150% of feed price instead of near the actual value. Are only 3 witnesses paying attention?
Why was it set this way? And is it a good fix to put it at 1.0 SQP? What other problems are there.
-
I think this is not a problem if shorts have HIGH COLLATERAL. YOU NEED MORE THAN 2Xs COLLTERAL. Try it out for yourself.
The biggest immediate problem now is that the witnesses are forcing those shorts to cover at 150% of feed price instead of near the actual value. Are only 3 witnesses paying attention?
Why was it set this way? And is it a good fix to put it at 1.0 SQP? What other problems are there.
1.0 is not good.
we need some premium to encourage other's to help cover the short position, at BTS1.0, it's 1.1, now it's 1.5
In fact I prefer to 1.05, otherwise 1.1 is more better than 1.5
-
There is no issue if you have lots of collateral if your a shorter. YOu need more than 3Xs.
TO BE CLEAR> THERE IS NO ISSUE.
-
There is no issue if you have lots of collateral if your a shorter. YOu need more than 3Xs.
TO BE CLEAR> THERE IS NO ISSUE.
Well there is!
If you change the rule...post factum!!!
As was done in this particular case!
-
There is no issue if you have lots of collateral if your a shorter. YOu need more than 3Xs.
TO BE CLEAR> THERE IS NO ISSUE.
Well there is!
If you change the rule...post factum!!!
As was done in this particular case!
Either your not understanding the system, or I am really wrong here. You CAN POST a ASK on the Market without getting short sqeezed if you have lots of collateral. Try it. IT works.
-
There is no issue if you have lots of collateral if your a shorter. YOu need more than 3Xs.
TO BE CLEAR> THERE IS NO ISSUE.
There is an issue. The dev team didn't actually coordinate the upgrade with exchanges so now the main sources of liquidity for bitassets are not available. Shorts can't cover their positions because they can't get any bitassets. The collateral requirement is something like 175% but shorts are getting called before that, and when they are sold they are sold more than 25% less than the actual price. So if you have bitassets and bitshares you can drive down the price of bitshares and get a risk free return of 25%. The only exchange that is upgraded is pump and dump exchange which is why we are seeing the price of bts be dumped on poloniex for 17% lower than on yunbi and btc38. Why is that happening? Because this stupid rule makes it profitable to dump bitshares. The market just needs to be shut down until other exchanges are upgraded.
-
There is no issue if you have lots of collateral if your a shorter. YOu need more than 3Xs.
TO BE CLEAR> THERE IS NO ISSUE.
Well there is!
If you change the rule...post factum!!!
As was done in this particular case!
Either your not understanding the system, or I am really wrong here. You CAN POST a ASK on the Market without getting short sqeezed if you have lots of collateral. Try it. IT works.
OK, go ahead and put it, if you believe it works...
I am ready to eat it up... to reduce my losses
-
We are currently at 6 feeds at 110%. As the european and east coast witnesses wake up I am sure this number will increase. We seem to have stopped the bleeding. I have got to try to get some sleep now.
-
We are currently at 6 feeds at 110%. As the european and east coast witnesses wake up I am sure this number will increase. We seem to have stopped the bleeding. I have got to try to get some sleep now.
I count 7. Good work! We're well on our way.
-
We are currently at 6 feeds at 110%. As the european and east coast witnesses wake up I am sure this number will increase. We seem to have stopped the bleeding. I have got to try to get some sleep now.
My feeds have been setup as well and are updating frequently, however my witness (1.6.49) datasecuritynode has since been voted out, so my publishing is not having any impact.
I can only respond if I have a voted in witness to support the market. So please vote.
I like to also backup what puppy said that the witnesses are trying to coordinate others to update also.
-
And 8, so 3 or 4 more should do it.
EDIT: Make that 9!
MSSR Publisher Published
110% bhuz 2 seconds ago
110% bitcube 6 minutes ago
150% in.abit 7 minutes ago
150% spectral 9 minutes ago
150% wackou 14 minutes ago
110% elmato 15 minutes ago
110% mindphlux.witness 28 minutes ago
110% spartako 30 minutes ago
110% dele-puppy 39 minutes ago
150% bue 1 hour ago
110% delegate-1.lafona 2 hours ago
150% harvey-xts 3 hours ago
150% holytransaction 3 hours ago
110% rnglab 6 hours ago
110% roadscape 8 hours ago
150% delegate.ihashfury 11 hours ago
150% datasecuritynode 13 hours ago
150% mr.agsexplorer 17 hours ago
150% xeldal yesterday
150% cyrano yesterday
150% bts-bitshares-argentina 2 days ago
150% fox 3 days ago
-
Ok, I've set cyrano down to 110%.
But this is really not my territory. I strongly agree that the ratio(s) should be set by the committee, not by the witnesses.
-
Ok, I've set cyrano down to 110%.
But this is really not my territory. I strongly agree that the ratio(s) should be set by the committee, not by the witnesses.
+5%
-
Ok, I've set cyrano down to 110%.
But this is really not my territory. I strongly agree that the ratio(s) should be set by the committee, not by the witnesses.
Excellent! I tend to agree with that, but unfortunately this needed to be fixed as soon as possible.
And it's done. Thank you witnesses, forced collateral selloffs are now reduced to 110% rather than 150%.
-
OK, we have some control over the madness.
Participating witness I know of:
--------------------------
elmato
mindphlux.witness
spartako
dele-puppy
delegate-1.lafona
rnglab
roadscape
bitcube
cyrano
bhuz
-----------------------
Thanks, from the whole bitshares community. Even from the ones that do not get what are you doing for them right now.
-
it's not enough, need more witness to vote for 1100, now 10 witness vote for 1100, 9 for 1500
anyone quit, it back to 1500 again
and I think we should set 1100 as a hard limit at the source code
-
OK, we have some control over the madness.
Participating witness I know of:
--------------------------
elmato
mindphlux.witness
spartako
dele-puppy
delegate-1.lafona
rnglab
roadscape
bitcube
cyrano
bhuz
-----------------------
Thanks, from the whole bitshares community. Even from the ones that do not get what are you doing for them right now.
One more - witness in.abit.
We are asking more witnesses to join in our effort to stabilise the market and to provide shorters some time to react and adjust to the new bts2 margin call mechanism. This is a temporary measure as we believe the decision for the 'maximum_short_squeeze_ratio' should ultimately be made by the committee chaired by BM. We await BM's advice.
-
Any recommendation for setting the price feed script setup on Windows?
Does it need to be run in the C:\Program Files\BitShares 2\bin folder?
-
I have no experience with Python under Windows
but I can tell you that it does not matter from which path you start it .. the script connects to the witness/full node via RPC and does not care in which directory the witness binary is or on what machine it is executed
-
xeroc/python-graphenelib
[python-graphenelib:master] 4 new commits by Fabian Schuh:
ebe489a: [PriceFeed] config: More comments and cleaning up - Fabian Schuh
0fa6fac: Readded missing value - Fabian Schuh
7dbf5a6: [Price Feed] Merge all price feed updates into a single transaction. - Fabian Schuh
f7676bb: [Price Feed] Remove debug messages - Fabian Schuh
Here we go .. an update to reduce the number of transactions to publish feeds
since you still need to pay the fee per operation .. updating to this version will not bring more profit
-
Here we go .. an update to reduce the number of transactions to publish feeds
since you still need to pay the fee per operation .. updating to this version will not bring more profit
Excellent!
-
any idea why i got following error form running the latest price feed script .
Fetching data from wallet...
[Starting Threads]: (yunbi)(btcavg)(yahoo)(poloniex)(btc38).Exception in thread Thread-5:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connection.py", line 135, in _new_conn
(self.host, self.port), self.timeout, **extra_kw)
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/util/connection.py", line 90, in create_connection
raise err
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/util/connection.py", line 80, in create_connection
sock.connect(sa)
socket.timeout: timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connectionpool.py", line 559, in urlopen
body=body, headers=headers)
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connectionpool.py", line 345, in _make_request
self._validate_conn(conn)
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connectionpool.py", line 782, in _validate_conn
conn.connect()
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connection.py", line 215, in connect
conn = self._new_conn()
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connection.py", line 140, in _new_conn
(self.host, self.timeout))
requests.packages.urllib3.exceptions.ConnectTimeoutError: (<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f01ee367fd0>, 'Connection to api.bitcoinaverage.com timed out. (connect timeout=3)')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/dist-packages/requests/adapters.py", line 369, in send
timeout=timeout
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/connectionpool.py", line 609, in urlopen
_stacktrace=sys.exc_info()[2])
File "/usr/local/lib/python3.4/dist-packages/requests/packages/urllib3/util/retry.py", line 271, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
requests.packages.urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='api.bitcoinaverage.com', port=443): Max retries exceeded with url: /ticker/EUR (Caused by ConnectTimeoutError(<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f01ee367fd0>, 'Connection to api.bitcoinaverage.com timed out. (connect timeout=3)'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "pricefeeds.py", line 249, in fetch_bitcoinaverage
response = requests.get(url=url+coin, headers=_request_headers, timeout=3)
File "/usr/local/lib/python3.4/dist-packages/requests/api.py", line 69, in get
return request('get', url, params=params, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/api.py", line 50, in request
response = session.request(method=method, url=url, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 471, in request
resp = self.send(prep, **send_kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/sessions.py", line 579, in send
r = adapter.send(request, **kwargs)
File "/usr/local/lib/python3.4/dist-packages/requests/adapters.py", line 415, in send
raise ConnectTimeout(e, request=request)
requests.exceptions.ConnectTimeout: HTTPSConnectionPool(host='api.bitcoinaverage.com', port=443): Max retries exceeded with url: /ticker/EUR (Caused by ConnectTimeoutError(<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f01ee367fd0>, 'Connection to api.bitcoinaverage.com timed out. (connect timeout=3)'))
....Error in asset EUR: no median for empty data
+-------+----------------+----------------+------------------+-------------------+---------------+-----------------------+--------------------+
| asset | BTS/base | my mean | median exchanges | blockchain median | % change (my) | % change (blockchain) | last update |
+-------+----------------+----------------+------------------+-------------------+---------------+-----------------------+--------------------+
| BTC | 69498.06949807 | 64811.95713623 | 69150.57915058 | 68535.15625000 | -0.00191 | -1.38553 | 0:05:23.343019 ago |
| CNY | 38.87355179 | 36.05850485 | 38.67918403 | 38.24285714 | 0.20771 | -1.62243 | 0:05:23.346144 ago |
| USD | 249.51735719 | 231.62213537 | 248.26977040 | 246.37083333 | -0.86347 | -1.26104 | 0:05:20.349681 ago |
+-------+----------------+----------------+------------------+-------------------+---------------+-----------------------+--------------------+
Traceback (most recent call last):
File "pricefeeds.py", line 572, in <module>
if publish_rule() :
File "pricefeeds.py", line 68, in publish_rule
realPrice = statistics.median( price["BTS"][asset] )
File "/usr/lib/python3.4/statistics.py", line 313, in median
raise StatisticsError("no median for empty data")
statistics.StatisticsError: no median for empty data
-
Bitcoinaverage timed out .. i should add more souces for the btc/* price pairs soonish ..
Who could find the api docs of some exchanges that have BTC/FIAT pairs?
-
I do not have a problem with Bitcoinaverage. twitter, perhaps it is blocking your ip address due to 'too much' polling?
-
Many witnesses have problem publishing feeds because they got these errors for RUB and SEK assets :
grapheneapi.grapheneapi.RPCError: 0 exception: unspecified
10 assert_exception: Assert Exception
!bitasset.has_settlement(): No further feeds may be published after a settlement event
{}
th_a asset_evaluator.cpp:475 do_evaluate
{"o":{"fee":{"amount":10000,"asset_id":"1.3.0"},"publisher":"1.2.333","asset_id":"1.3.111","feed":{"settlement_price":{"base":{"amount":206,"asset_id":"1.3.111"},"quote":{"amount":65121,"asset_id":"1.3.0"}},"maintenance_collateral_ratio":1750,"maximum_short_squeeze_ratio":1100,"core_exchange_rate":{"base":{"amount":206,"asset_id":"1.3.111"},"quote":{"amount":68377,"asset_id":"1.3.0"}}},"extensions":[]}}
th_a asset_evaluator.cpp:494 do_evaluate
{}
th_a evaluator.cpp:45 start_evaluate
{}
th_a db_block.cpp:631 apply_operation
I'm able to publish again removing RUB and SEK from bts_assets:
- _all_bts_assets = ["BTC", "SILVER", "GOLD", "TRY", "SGD", "HKD", "RUB", "SEK", "NZD",
+ _all_bts_assets = ["BTC", "SILVER", "GOLD", "TRY", "SGD", "HKD", "NZD",
"CNY", "MXN", "CAD", "CHF", "AUD", "GBP", "JPY", "EUR", "USD",
"KRW" ] # , "SHENZHEN", "HANGSENG", "NASDAQC", "NIKKEI"
_bases =["CNY", "USD", "BTC", "EUR", "HKD", "JPY"]
_yahoo_base = ["USD","EUR","CNY","JPY","HKD"]
- _yahoo_quote = ["XAG", "XAU", "TRY", "SGD", "HKD", "RUB", "SEK", "NZD", "CNY",
+ _yahoo_quote = ["XAG", "XAU", "TRY", "SGD", "HKD", "NZD", "CNY",
"MXN", "CAD", "CHF", "AUD", "GBP", "JPY", "EUR", "USD", "KRW"]
-
Thanks spartako, removing RUB and SEK worked for me
-
Confirmed.. removing those assets got feeds working again.. and I was getting the same error reported.
-
!bitasset.has_settlement(): No further feeds may be published after a settlement event
oha .. did we have a black swan on those two assets? How are we supposed to reinitiate the markets? @bytemaster?
-
Have you consider getting a feed from ccedk? Their api reference - http://ccedk.mojohelpdesk.com/help/article/136549
-
Good idea .. putting it on my list
-
Pushed a new update. It now supports
* Bitcoin Indonesia
* CCEDK
I also recommend to DISABLE yunbi since they do not allow trades any longer.
lines added to the configuration are prefixed with "+":
## Enable exchanges
+enable_yunbi = False # currently halted
enable_btc38 = True
enable_bter = False
enable_poloniex = True
enable_bittrex = True
enable_btcavg = True
+enable_ccedk = True
+enable_btcid = True
poloniex_trust_level = 1.0
bittrex_trust_level = 0.5
yunbi_trust_level = 0.8
+ccedk_trust_level = 1.0
+btcid_trust_level = 1.0
-
Another update!
[Price Feed] New configuration variable "price_metric" allows to set for median, mean, or weighted (by volume) price.
The default value for price_metric should be weighted. Note that this will move
the price since now Poloniex's price will have more weight as before (as it
should be). I recommend to not update all witnesses at once (which shouldn't be
a problem considering the decentralization of timezones :) )
https://github.com/xeroc/python-graphenelib/commit/bd3b095e56553f50226bf9b255646ab25ef2a9b3
-
Thanks xeroc, the update works flawlessly +5%
-
Updated and working great. Thanks xeroc !
-
hi, xeroc
if I want to monitor my account's transaction and execute some call such as transfer.
should I subscribe transaction event from witness_node(port 8090) and execute transfer from cli_wallet(port 8092)?
so I need to declair GrapheneAPI instanse with port 8092, and declair a GrapheneWebSocket instanse with port 8090?
thanks
-
hi, xeroc
if I want to monitor my account's transaction and execute some call such as transfer.
should I subscribe transaction event from witness_node(port 8090) and execute transfer from cli_wallet(port 8092)?
so I need to declair GrapheneAPI instanse with port 8092, and declair a GrapheneWebSocket instanse with port 8090?
thanks
Take a look at this script:
https://github.com/xeroc/python-graphenelib/blob/master/scripts/monitor-deposits/monitor.py
In order to initiate a transfer you need to also interface with a cli-wallet similar to this:
https://github.com/xeroc/python-graphenelib/blob/master/scripts/flood/flood.py
-
yes,I have see these two scripts, monitor through witness port and transfer through cli_wallet right?
-
yes,I have see these two scripts, monitor through witness port and transfer through cli_wallet right?
yup
-
I have pushed some more commits that mainly fixed the volume issue with CCEDK (which was my fault) ..
after upgrading the code, you can safely set the trust value back to 1.0 again
I also noticed that yunbi has volume in the BTS/CNY market but not in the BTS/BTC market .. thus you can also enable yunbi again .. althoug I would advice a trust factor of less than 1 since they have not yet finished integrating BTS2, similar to bittrex ..
-
I also noticed that yunbi has volume in the BTS/CNY market but not in the BTS/BTC market .. thus you can also enable yunbi again .. althoug I would advice a trust factor of less than 1 since they have not yet finished integrating BTS2, similar to bittrex ..
FYI, Bittrex has enabled bts deposit.
-
Oh .. no one told me .. then you can put a 1.0 as trust factor for bittrex aswell
-
[Price Feed] asset specific SQP etc
https://github.com/xeroc/python-graphenelib/commit/21f22a93c2812819fa2590866ec345f562646120
The configuration file syntax has changed!!
-
Another update:
* [2015-11-26][ea91778] | [Price Feed] Make default price parameters more clean {{Fabian Schuh}} (HEAD -> master, origin/master)
* [2015-11-26][4db1f0a] | [Price Feed] Delegate->Witness rename / More comments in configuration file {{Fabian Schuh}}
* [2015-11-26][fa0fbf9] | [Price Feed] Reduce transaction costs by only publishing individually required prices, not all {{Fabian Schuh}}
* [2015-11-26][54cb51d] | [Price Feed] Allow for asset-specific core_exchange_rate_factor {{Fabian Schuh}}
The parameters are now asset specific and can be used as follows
################################################################################
## Asset specific Borrow/Short parameters
################################################################################
# Core exchange rate for paying transaction fees in non-BTS assets
core_exchange_factor = {
"default" : 0.95, # default value
"USD" : 0.95, # asset-specific overwrite
}
# Call when collateral only pays off 175% the debt
maintenance_collateral_ratio = {
"default" : 1750, # default value
"USD" : 1750, # asset-specific overwrite
}
# Stop calling when collateral only pays off 110% of the debt
maximum_short_squeeze_ratio = {
"default" : 1100, # default value
"USD" : 1100, # asset-specific overwrite
}
Please note that the configuration has changed, changed some variable names (also delegate_name->witness_name)
-
Oh .. btw .. the last update also only publishes those feeds that need update .. hence you could spare some tx fees here
-
Mega Update in order to improve price.
https://github.com/xeroc/python-graphenelib/commit/16b9ca16c9044cc751605e0276d3223a9ef00f7b
[Price Feed] Megaupdate
* Per Asset parameters include exchanges to consider
* Exchange fetch methods are moved outside the feed script
* Python Futures
This update can now also consider prices from Huobi and BitcoinChina.
Configuration has changes
Demo configuration:
import feedsources
################################################################################
## RPC-client connection information (required)
################################################################################
host = "localhost" # machine that runs a cli-wallet with -H parameter
port = 8092 # RPC port, e.g.`-H 127.0.0.1:8092`
user = "" # API user (optional)
passwd = "" # API user passphrase (optional)
unlock = "" # password to unlock the wallet if the cli-wallet is locked
################################################################################
## Script runtime parameters
################################################################################
ask_confirmation = True # if true, a manual confirmation is required
################################################################################
## Witness Feed Publish Parameters
################################################################################
witness_name = "init0"
maxAgeFeedInSeconds = 60*60 # A feed should be at most 1hour old
change_min = 0.5 # Percentage of price change to force an update
change_max = 5.0 # Percentage of price change to cause a warning
################################################################################
## Fine tuning
################################################################################
discount = 0.995 # discount for borrowing of an asset
minValidAssetPriceInBTC = 100 * 1e-8 # minimum valid price for BTS in BTC
################################################################################
## Asset specific Settings
################################################################################
asset_config = {
"default" : { ## DEFAULT BEHAVIOR
# "median", "mean", or "weighted" (by volume)
"metric" : "weighted",
# all:* , or array of: "yahoo", "btcid", "ccedk", "yunbi", "btc38", "bter", "poloniex", "bittrex", "btcavg"
"sources" : ["*"],
# Core exchange rate for paying transaction fees in non-BTS assets
"core_exchange_factor" : 0.95,
# Call when collateral only pays off 175% the debt
"maintenance_collateral_ratio" : 1750,
# Stop calling when collateral only pays off 110% of the debt
"maximum_short_squeeze_ratio" : 1100,
},
"CNY" : {
"metric" : "median",
"sources" : ["poloniex","bittrex","huobi","btcchina"]
}
}
################################################################################
## Exchanges and settings
################################################################################
feedSources = {}
feedSources["yahoo"] = feedsources.Yahoo(trust=1.0)
feedSources["btcavg"] = feedsources.BitcoinAverage(trust=1.0)
feedSources["poloniex"] = feedsources.Poloniex(trust=1.0)
feedSources["bittrex"] = feedsources.Bittrex(trust=1.0)
feedSources["ccedk"] = feedsources.Ccedk(trust=1.0)
feedSources["btcchina"] = feedsources.BtcChina(trust=1.0)
feedSources["huobi"] = feedsources.Huobi(trust=1.0)
feedSources["yunbi"] = feedsources.Yunbi(trust=0.5)
feedSources["btc38"] = feedsources.Btc38(trust=0.5)
#feedSources["btcid"] = feedsources.BitcoinIndonesia(trust=0.0)
#feedSources["bter"] = feedsources.Bter(trust=0.0)
-
New Script just now:
+--------+---------------+------------+------------------+-------------------+---------------+-----------------------+---------------------------------+---------+
| asset | price per BTS | my mean | median exchanges | blockchain median | % change (my) | % change (blockchain) | last update | publish |
+--------+---------------+------------+------------------+-------------------+---------------+-----------------------+---------------------------------+---------+
| BTC | 0.00000846 | 0.00000835 | 0.00000836 | 119221.63120567 | -100.00085 | 0.83770 | 16769 days, 12:27:42.994040 ago | X |
| SILVER | 0.00022716 | 0.00022735 | 0.00022599 | 4384.50000000 | -100.02272 | -0.40338 | 16769 days, 12:27:42.995337 ago | X |
| GOLD | 0.00000300 | 0.00000300 | 0.00000299 | 330863.33333333 | -100.00030 | -0.70050 | 16769 days, 12:27:42.996345 ago | X |
| TRY | 0.00925493 | 0.00926271 | 0.00920743 | 107.55272727 | -100.92549 | -0.46065 | 16769 days, 12:27:42.997357 ago | X |
| SGD | 0.00449285 | 0.00449663 | 0.00446936 | 221.52592593 | -100.44929 | -0.47163 | 16769 days, 12:27:42.998336 ago | X |
| HKD | 0.02466519 | 0.02468597 | 0.02453521 | 40.38370044 | -102.46652 | -0.39283 | 16769 days, 12:27:42.999340 ago | X |
| NZD | 0.00484322 | 0.00484729 | 0.00481832 | 205.45500000 | -100.48432 | -0.49358 | 16769 days, 12:27:43.000903 ago | X |
| CNY | 0.02084914 | 0.02037820 | 0.02025377 | 48.87259259 | -102.08491 | 1.89517 | 16769 days, 12:27:43.001887 ago | X |
| MXN | 0.05274312 | 0.05278742 | 0.05246750 | 18.87548544 | -105.27431 | -0.44480 | 16769 days, 12:27:43.003357 ago | X |
| CAD | 0.00425188 | 0.00425545 | 0.00423002 | 234.01052632 | -100.42519 | -0.50158 | 16769 days, 12:27:43.004386 ago | X |
| CHF | 0.00327817 | 0.00328093 | 0.00326127 | 303.58227080 | -100.32782 | -0.48043 | 16769 days, 12:27:43.005380 ago | X |
| AUD | 0.00440713 | 0.00441084 | 0.00438424 | 225.61395349 | -100.44071 | -0.56894 | 16769 days, 12:27:43.006382 ago | X |
| GBP | 0.00211750 | 0.00211928 | 0.00210666 | 469.70408643 | -100.21175 | -0.53993 | 16769 days, 12:27:43.007386 ago | X |
| JPY | 0.39161229 | 0.39194194 | 0.38957115 | 2.54252778 | -139.16123 | -0.43149 | 16769 days, 12:27:43.008366 ago | X |
| EUR | 0.00300677 | 0.00300930 | 0.00299121 | 331.03750000 | -100.30068 | -0.46460 | 16769 days, 12:27:43.010122 ago | X |
| USD | 0.00318283 | 0.00318551 | 0.00316563 | 312.79324367 | -100.31828 | -0.44330 | 16769 days, 12:27:43.011630 ago | X |
| KRW | 3.66409018 | 3.66915853 | 3.67206229 | 0.27129753 | -466.40902 | -0.59414 | 16769 days, 12:27:43.013094 ago | X |
+--------+---------------+------------+------------------+-------------------+---------------+-----------------------+---------------------------------+---------+
Old Script just now:
+--------+-----------------+-----------------+------------------+-------------------+---------------+-----------------------+---------------------------------+---------+
| asset | BTS/base | my mean | median exchanges | blockchain median | % change (my) | % change (blockchain) | last update | publish |
+--------+-----------------+-----------------+------------------+-------------------+---------------+-----------------------+---------------------------------+---------+
| BTC | 119216.08068607 | 114454.37729791 | 117191.43976981 | 119221.63120567 | -100.00084 | 0.00466 | 16769 days, 12:29:04.809748 ago | X |
| SILVER | 4389.63472314 | 4214.00511904 | 4336.09411615 | 4384.50000000 | -100.02278 | -0.11697 | 16769 days, 12:29:04.811758 ago | X |
| GOLD | 332187.16101836 | 318896.32835105 | 328135.91972626 | 330863.33333333 | -100.00030 | -0.39852 | 16769 days, 12:29:04.813422 ago | X |
| TRY | 107.73831660 | 103.42769311 | 106.43144741 | 107.55272727 | -100.92817 | -0.17226 | 16769 days, 12:29:04.815258 ago | X |
| SGD | 221.95726058 | 213.07673182 | 219.25636479 | 221.52592593 | -100.45054 | -0.19433 | 16769 days, 12:29:04.817057 ago | X |
| HKD | 40.42935227 | 38.81179660 | 39.93904179 | 40.38370044 | -102.47345 | -0.11292 | 16769 days, 12:29:04.818777 ago | X |
| NZD | 205.90370171 | 197.66548773 | 203.39884748 | 205.45500000 | -100.48566 | -0.21792 | 16769 days, 12:29:04.822876 ago | X |
| CNY | 48.97623126 | 47.01676585 | 48.38379477 | 48.87259259 | -102.04181 | -0.21161 | 16769 days, 12:29:04.824554 ago | X |
| MXN | 18.90547887 | 18.14906523 | 18.67736392 | 18.87548544 | -105.28947 | -0.15865 | 16769 days, 12:29:04.827384 ago | X |
| CAD | 234.50768905 | 225.12501645 | 231.65069325 | 234.02761526 | -100.42643 | -0.20472 | 16769 days, 12:29:04.829030 ago | X |
| CHF | 304.22114225 | 292.04923508 | 300.51447300 | 303.58227080 | -100.32871 | -0.21000 | 16769 days, 12:29:04.830673 ago | X |
| AUD | 226.23304985 | 217.18143600 | 223.47995048 | 225.63333333 | -100.44202 | -0.26509 | 16769 days, 12:29:04.832348 ago | X |
| GBP | 470.91486712 | 452.07351535 | 465.17936621 | 469.82307692 | -100.21235 | -0.23184 | 16769 days, 12:29:04.834049 ago | X |
| JPY | 2.54642466 | 2.44454411 | 2.51577086 | 2.54252778 | -139.27075 | -0.15303 | 16769 days, 12:29:04.835712 ago | X |
| EUR | 331.66484625 | 318.39521260 | 327.59833068 | 331.03750000 | -100.30151 | -0.18915 | 16769 days, 12:29:04.840230 ago | X |
| USD | 313.35383170 | 300.81683155 | 309.55429825 | 312.79324367 | -100.31913 | -0.17890 | 16769 days, 12:29:04.843851 ago | X |
| KRW | 0.27164239 | 0.26090843 | 0.26717324 | 0.27129753 | -468.13105 | -0.12695 | 16769 days, 12:29:04.847094 ago | X |
+--------+-----------------+-----------------+------------------+-------------------+---------------+-----------------------+---------------------------------+---------+
Note the difference in CNY that comes from asking the BTC/CNY price from huobi and bitcoinchina instead of bitcoinaverage
-
5e11e12: [Price Feed] Add OkcoinUSD and OkcoinCNY
-
Quite some updates happend to the feed script ... I recommend to upgrade to it, update the configuration and give it a try ..
-
I just pushed another update that add's @alt 's TCNY asset .. the configuration file has changed slightly
-
Hi @xeroc would you please help check this log file?
https://drive.google.com/file/d/0B3xrm70jSHn4VmpvdE15UEJnWUk/view
The prices in USD / EUR / TUSD / KRW are off by 100x.
Some logs here:
"USD": {"mean": 0.0680436848863721, "median": 0.0034588223011641013, "weighted": 0.32804216106003525}
-
Hi @xeroc would you please help check this log file?
https://drive.google.com/file/d/0B3xrm70jSHn4VmpvdE15UEJnWUk/view
The prices in USD / EUR / TUSD / KRW are off by 100x.
Some logs here:
"USD": {"mean": 0.0680436848863721, "median": 0.0034588223011641013, "weighted": 0.32804216106003525}
If I use your file and run it in blame mode I get the correct prices:
(http://i.imgur.com/lSdBP4u.png)
See "recalculated price" ..
However, I see that the median price is quite of from the weighted median .. which (so I assume) is because of "dead" markets ..
I should maybe skip markets entirely that have 0 24h trading
-
Hi @xeroc would you please help check this log file?
https://drive.google.com/file/d/0B3xrm70jSHn4VmpvdE15UEJnWUk/view
The prices in USD / EUR / TUSD / KRW are off by 100x.
Some logs here:
"USD": {"mean": 0.0680436848863721, "median": 0.0034588223011641013, "weighted": 0.32804216106003525}
If I use your file and run it in blame mode I get the correct prices:
(http://i.imgur.com/lSdBP4u.png)
See "recalculated price" ..
What's "blame price" and what's "recalculated price"? Is the "recalculated price" newly fetched from the markets?
I did published those off-100x prices to block chain, same as the "blame price" in above picture, wondering what's wrong..
However, I see that the median price is quite of from the weighted median .. which (so I assume) is because of "dead" markets ..
I should maybe skip markets entirely that have 0 24h trading
-
The blame price is the price you have calculated and published .. the recalculated prices takes the same fetched data from exchanges (stored in the blame file as well) and recalculates the price .. this is useful for me to compare implementations .. the blame file also contains a git hash of your code base bit i havent compared the hash to figure out which version you are running ...
Could you update your script and try to run on the blame file?
-
The blame price is the price you have calculated and published .. the recalculated prices takes the same fetched data from exchanges (stored in the blame file as well) and recalculates the price .. this is useful for me to compare implementations .. the blame file also contains a git hash of your code base bit i havent compared the hash to figure out which version you are running ...
Could you update your script and try to run on the blame file?
Perhaps it's caused by a bug which you've fixed. Will try. Thanks.
//Update:
The latest version of script works fine. Result is same to that on your picture.
Thank you.
-
@xeroc latest version (commit 3c7b2ca1b68e33fbf47aa9d66005613b83ca1f51) with Btc38's BTS/BTC market enabled by default causes a 10% off on BTS/CNY price.
| CNY | 0.02429415 | 0.02342230 (+3.72%) | 0.02433542 (-0.17%) | 0.02429415 (+0.00%) | 0.03% ( 5) | 0.02209000 (+9.98%) | 0.02209988 (+9.93%) | 1:48:02.671795 ago | X |
blame file here: https://drive.google.com/open?id=0B3xrm70jSHn4V2dBX1duaEZ5OEE
Another minor error on my server:
Error fetching results from Ccedk! ('bool' object is not subscriptable)
-
@xeroc latest version (commit 3c7b2ca1b68e33fbf47aa9d66005613b83ca1f51) with Btc38's BTS/BTC market enabled by default causes a 10% off on BTS/CNY price.
| CNY | 0.02429415 | 0.02342230 (+3.72%) | 0.02433542 (-0.17%) | 0.02429415 (+0.00%) | 0.03% ( 5) | 0.02209000 (+9.98%) | 0.02209988 (+9.93%) | 1:48:02.671795 ago | X |
blame file here: https://drive.google.com/open?id=0B3xrm70jSHn4V2dBX1duaEZ5OEE
Another minor error on my server:
Error fetching results from Ccedk! ('bool' object is not subscriptable)
The script is a deterministic one, so it does not "cause" a wrong price. I will investigate what the reason for this is, but I assume some exchange may have published an "off"-price .. We do see some volatility right now..
-
@xeroc latest version (commit 3c7b2ca1b68e33fbf47aa9d66005613b83ca1f51) with Btc38's BTS/BTC market enabled by default causes a 10% off on BTS/CNY price.
| CNY | 0.02429415 | 0.02342230 (+3.72%) | 0.02433542 (-0.17%) | 0.02429415 (+0.00%) | 0.03% ( 5) | 0.02209000 (+9.98%) | 0.02209988 (+9.93%) | 1:48:02.671795 ago | X |
blame file here: https://drive.google.com/open?id=0B3xrm70jSHn4V2dBX1duaEZ5OEE
Another minor error on my server:
Error fetching results from Ccedk! ('bool' object is not subscriptable)
The script is a deterministic one, so it does not "cause" a wrong price. I will investigate what the reason for this is, but I assume some exchange may have published an "off"-price .. We do see some volatility right now..
It's sure caused by Btc38's BTS/BTC market, but I don't think there is enough volume to cause a 10% change on weighted average price. Maybe I'm wrong.. However I disabled that market in my production script.
-
With the newest release, the only real change is that you will need to rename "witness_name" into "producer_name". This change facilitates that non-witnesses are allowed to publish prices for privatized bitassets aswell
-
Does the BitShares price feed reference last traded prices at weighted exchanges or does it average last traded prices over a certain amount of time?
What I mean is there is that there is usually a 1-2% spread between buy and sell prices for BTS on BTC38 and Polo.
If you are force settling and you know it will reference last traded prices at a specific time then it would be in your interest to make tiny sell trades so that the last traded price is in your favour by 1-2%. If your force settle is going through at a thinly traded time it may also be in your interest & very cheap to move the price temporarily by another 1-2%.
-
Does the BitShares price feed reference last traded prices at weighted exchanges or does it average last traded prices over a certain amount of time?
What I mean is there is that there is usually a 1-2% spread between buy and sell prices for BTS on BTC38 and Polo.
If you are force settling and you know it will reference last traded prices at a specific time then it would be in your interest to make tiny sell trades so that the last traded price is in your favour by 1-2%. It your force settle is going through at a thinly traded time it may also be in your interest & very cheap to move the price by another 1-2%.
That would assume that you know when witnesses publish a price and how many witnesses publish it ..
This could be fixed by tracking trades over time or running a weighted average over time but that involves alot of work to upgrade the feed script into a time-sensitive feed script.
Fortunately, this time-sensivity is also achieved by different witnesses running their scripts at different time instants.
We may consider replacing the last price with the "(highest bid + lowest ask)/ 2" that would make it a little more "fair"
-
Does the BitShares price feed reference last traded prices at weighted exchanges or does it average last traded prices over a certain amount of time?
What I mean is there is that there is usually a 1-2% spread between buy and sell prices for BTS on BTC38 and Polo.
If you are force settling and you know it will reference last traded prices at a specific time then it would be in your interest to make tiny sell trades so that the last traded price is in your favour by 1-2%. It your force settle is going through at a thinly traded time it may also be in your interest & very cheap to move the price by another 1-2%.
That would assume that you know when witnesses publish a price and how many witnesses publish it ..
This could be fixed by tracking trades over time or running a weighted average over time but that involves alot of work to upgrade the feed script into a time-sensitive feed script.
Fortunately, this time-sensivity is also achieved by different witnesses running their scripts at different time instants.
We may consider replacing the last price with the "(highest bid + lowest ask)/ 2" that would make it a little more "fair"
Cool, yeah I'm just wondering if the forced settlement at 100% can currently be exploited.
I think your other suggestion of introducing a 1-2% forced settlement fee could also help address that if it was a potential issue...
- Settlement can be discouraged by asking for a percentage fee (1-2%) (this will move the peg AROUND parity. Flat fee for settlement can also be increase which has some negative effects on pred. markets
-
I have updated the price feed slightly to make it easier (later) to add privatized bitassets ...
It can now also poll the BitShares DEX and include its volume/price.
I also changed some syntax and style stuff in the configuration, which makes the comparison a little more tricky. Anyway, here is the diff of the example config file:
https://github.com/xeroc/python-graphenelib/compare/master...develop#diff-4343e1580d24c0ed7ff42021df7495f3L1
As you can see, the FeedSources are now way more flexible to use..
NOTE: this is still in the development branch but you can run it (if you want) by
git fetch
git checkout develop
git rebase develop
-
For forced settlement what about using the average BTS price over the following 24 hours as opposed to the BTS price in 24 hours?
I think it would be much harder for someone who wanted to manipulate their settlement price if they had to do it for an entire day as opposed to at a specific point in time. (Circa 24 hours after requesting forced settlement.)
-
For forced settlement what about using the average BTS price over the following 24 hours as opposed to the BTS price in 24 hours?
I think it would be much harder for someone who wanted to manipulate their settlement price if they had to do it for an entire day as opposed to at a specific point in time. (Circa 24 hours after requesting forced settlement.)
It's not a price feeding issue. It's a core issue. We just don't have such a feature which will tracks average price of last 24 hours.