BitShares Forum
Main => General Discussion => Topic started by: xeroc on October 08, 2015, 07:46:27 am
-
I would like to discuss a potential issue that mindphlux made me aware of today.
Let's assume
- an exchange does not honor the upgrade to bts 2.0
- a single delegate in bts1 is still active after the snapshot
- arbitrage between 1.0 and 2.0 honoring exchanges happen
- the price feeds incorporate both exchanges as source for the feed
then we may see a big problem when people selling their (arguable) worthless BTS1 tokens and arbitraging kills the other (BTS2) markets.
This may also lead to plenty of settlements and maybe even a black swan in BitShares 2.0 if we publish prices there directly.
Hence, I propose to NOT publish price feeds and delay this by 1 or 2 days until things settle down ..
What would be the consequences for open short positions? They can't settle for 2 days
What are the consequences for longs: none that I would be aware of
What are the consequences for arbitraging people: they lose money
What are the opportunities: get cheap BTS (in BTS2) from people arbitraging BTS1/BTS2
Discuss!
-
- arbitrage between 1.0 and 2.0 honoring exchanges happen
I think here is your answer....
How would it be possible since exchange 1 would have the 0.9 wallet installed and exchange 2 the bts2.0 wallet?
the bts2.0 wallet could not receive bts from a bts1 wallet because they are on a different chain....
-
- the price feeds incorporate both exchanges as source for the feed
witnesses on bts2.0 should ignore the exchange that does not make the migration (the price feed script should not get any price feeds from them)
-
witnesses on bts2.0 should ignore the exchange that does not make the migration (the price feed script should not get any price feeds from them)
Sure .. but how do we know this at launch?
I think here is your answer....
How would it be possible since exchange 1 would have the 0.9 wallet installed and exchange 2 the bts2.0 wallet?
the bts2.0 wallet could not receive bts from a bts1 wallet because they are on a different chain....
Step-by-step:
1) Wait for the snapshot
2) send BTS1 to the exchange that does NOT honor the snapshot
3) sell them against BTC
4) send BTC to an exchange that DOES honor the snapshot
5) buy more BTS (in the 2.0 chain)
Tada .. this all can be fixed by exchanges by
do not allow BTS1 deposits or withdrawals after the snapshot!
The idea of 0.9.3 was to have the delegates do that part and stop the blockchain .. I hope it will be that way .. not sure though .. :(
-
Publishing price feed for BTS1 on the BTS2 is effectively publishing wrong feed. Probably order of magnitude wrong. And it will undeniably be done on purpose, because no delegate on just launched BTS2 will be able to explain how he did not know BTS1 existed.
Add to that that BTS2 will be launched with 17 (?) delegates controlled by BM. So he will not be aware of his old blockchain?
And yes any delegate candidate should make triple sure he got the correct feeds before submitting ANY feed at all times, but particularly at launch time/ during her initial bid for witness position.
-
Anyone else has some input?
-
I absolutly agree that it's safest not to publish feeds when one exchange has not honoured the upgrade.
-
Different chains, different conversion rates. You are totally right. So what exchanges won't be migrating?
-
If there are no feeds published then the following will happen:
1. Users will not be able to transfer BitAssets due to the lack of a core-exchange-rate
2. No margin calls will be executed
3. Shorts will not be able to adjust margin positions
I doubt there will be any exchanges that do not honor the upgrade, it would cost them all future BTS revenue.
-
If there are no feeds published then the following will happen:
1. Users will not be able to transfer BitAssets due to the lack of a core-exchange-rate
2. No margin calls will be executed
3. Shorts will not be able to adjust margin positions
I doubt there will be any exchanges that do not honor the upgrade, it would cost them all future BTS revenue.
So then I would need someone to review my code .. I don't want to be the one to be blamed afterwards ..
Gonna put a huge header into the script with a warning
//edit: is there a need for a minimum number of published feeds?!?
-
If there are no feeds published then the following will happen:
1. Users will not be able to transfer BitAssets due to the lack of a core-exchange-rate
2. No margin calls will be executed
3. Shorts will not be able to adjust margin positions
I doubt there will be any exchanges that do not honor the upgrade, it would cost them all future BTS revenue.
So then I would need someone to review my code .. I don't want to be the one to be blamed afterwards ..
Gonna put a huge header into the script with a warning
//edit: is there a need for a minimum number of published feeds?!?
Here is a short yet informative disclaimer:
if time.time() < 1444953600 : return
-
xeroc.
Perhaps until we have everything ironed out you should have your bot require an input to publish. So for example it will pull pricing and convert it to human readable form, and give a prompt. Would you like to publish this feed? Yes or No.
Alternately if this would be too much of a pain to implement you could change it so that rather than submitting the transaction to publish it just printed the transaction to screen. Then witnesses would have to double check the numbers, copy paste, and publish manually.
Ultimately if we need to manually update feeds 3 times a day or so for the first few days we will all be okay.
-
Is there any way to temporarily protect open short positions in 2.0 without blatant market manipulation?
-
xeroc.
Perhaps until we have everything ironed out you should have your bot require an
input to publish. So for example it will pull pricing and convert it to human
readable form, and give a prompt. Would you like to publish this feed? Yes or
No.
Alternately if this would be too much of a pain to implement you could change it
so that rather than submitting the transaction to publish it just printed the
transaction to screen. Then witnesses would have to double check the numbers,
copy paste, and publish manually.
Sounds like a great idea .. I am going to implement a confirmation dialog! Have
the code somewhere already!
-
How about letting the configuration file default to NONE exchange? And once a particular exchange formally announces that it has switched over to 2.0, the witness themselves update their feed's configuration file to 'activate' that particular exchange. What we want is that the feed is coming from exchanges who formally announced they have switched over to 2.0 successfully.
-
How about letting the configuration file default to NONE exchange? And once a particular exchange formally announces that it has switched over to 2.0, the witness themselves update their feed's configuration file to 'activate' that particular exchange. What we want is that the feed is coming from exchanges who formally announced they have switched over to 2.0 successfully.
Many +5%s !!!
Yes, very short precise, technical explanation / translation of my view as well (expressed in my initial post in this thread).
-
good idea .. i'll disable all by default and let them be enabled by the witness maintainer ..
Gonna implement on my flight to China on Sunday ..
-
As I mentioned here https://bitsharestalk.org/index.php/topic,18477.msg243368.html#msg243368
39% of bts1 delegates don't officially support bts2.0 migration (they don't upgraded to v0.9.3) http://bitsharesblocks.com/delegates
Should I assume the plan for them is to dumb bts1 coins to exchanges that will continue to trade bts1 coins?...
Do we know if such exchanges are in existence and which they are? bter(?),btc38(?)