Author Topic: Dry Run 15: Fifteen ( Market GUI ! )  (Read 28794 times)

0 Members and 1 Guest are viewing this topic.

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile
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.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Xeldal

  • Guest
Somewhere in alts attack I managed to pick up 21Mil USD.   If they're useful somewhere let me know, I'll send them.
« Last Edit: August 16, 2014, 02:08:27 pm by Xeldal »

Offline oldman

  • Hero Member
  • *****
  • Posts: 556
    • View Profile
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...


Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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.
Weibo:http://weibo.com/zhangweis

Offline maqifrnswa

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
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.
maintains an Ubuntu PPA: https://launchpad.net/~showard314/+archive/ubuntu/bitshares [15% delegate] wallet_account_set_approval maqifrnswa true [50% delegate] wallet_account_set_approval delegate1.maqifrnswa true

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
Fund please.
XTSLYifrtHXLvYjMrDYF2djApYYNRMcurcp5
Thanks!
BitShares committee member: abit
BitShares witness: in.abit

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
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?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline tonyk

  • Hero Member
  • *****
  • Posts: 3308
    • View Profile

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.
Lack of arbitrage is the problem, isn't it. And this 'should' solves it.

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline cgafeng

Try any of:
Code: [Select]
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.
BTC:1EYwcZ9cYVj6C9LMLafdcjK9wicVMDV376

Offline sudo

  • Hero Member
  • *****
  • Posts: 2255
    • View Profile
  • BitShares: ags
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,


Offline vikram

Try any of:
Code: [Select]
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"

Offline cgafeng

network_add_node "207.12.89.119:1776"
does't work
« Last Edit: August 16, 2014, 03:48:21 am by cgafeng »
BTC:1EYwcZ9cYVj6C9LMLafdcjK9wicVMDV376

Offline vikram

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:
Code: [Select]
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"