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.

cny,usd的利息一样时不能锚定的。所以我是觉得USD和CNY应该允许以交易手续费的形式烧掉一部分，才可以保证它们不会归零。只要有收益，作为资产就会有实际的价值，而不是仅仅因为三个字母来引导市场的看法实现锚定。
像分红，利息之类的，我想市场价格应该会有体现。比如1bitUSD = 0.99USD，因为没有利息。

Well from the actual running result of btsx, it's quite different than what you described.

*  You can vote for low-pay delegates so that they receive only a small percent (10% or less) of possible pay. The rest is destroyed.

Most of the BTSX top 101 delegates have 100%, some 80% and few less. I would say the average is about 95%. This won't change much for DNS.

*  You can vote for full-time employees who will have to sell a large part of their stake for their income while also increasing the value of the whole network.

Isn't POS for less resource consumption?

*  You aren't just giving 101 individuals the majority - there will be more than 101 different delegates over the course of a year, and they also want what is good for the DAC and will vote for a diverse set of delegates.

I don't see top delegates change much for BTSX.

with TITAN each unspend output has a seperate private key that can be derived from the master private key of your account. You will not be able to sign any transactions if you do not have the corresponding privkey of the unspent outputs.
However, you do not necessarily need the master private key .. but I am not sure if it is wise to work on derived private keys (and possibly expose them) as there are some security issues with ECC concerning derived private keys .. best practice would be to let the wallet handle derived priv keys..

Or are you talking about unsigned raw transactions .. that should be possible with titan .. but currently is not yet implemented.

TITAN is based on ECC as is bitcoin .. I don't know about the explicit transaction structure but I am very sure something like 'offline' signing is possible and will be implemented in future .

Further .. BM once stated that he has some nice ideas about some observer-keys that can only do read-only .. (ECC magic)

Thanks for the answer. If I choose not to use TITAN, will things be easier? At least from blockchain point of view, I don't see any barrier. I withdraw some from an account and deposit to an account with a public key. Wrap them into 2 operations in a transaction, sign it and broadcast it. The barrier is at wallet which doesn't allow generation of a raw transaction and transmission of a signed transaction.

How can I protect my private key using similar way of offline wallet without ever exposing private key in any way in online machine/wallet? I guess it can be split in 2 sub-questions.
1. How can I generate a transaction without private key?
I don't know whether it's possible with TITAN. If it's not and I choose to compromise the anonymity, how can I generate the raw transaction on an online machine?
2. How can I sign it on an offline machine?
Is it the same algorithms as bitcoin? If yes, then it's quite easy to sign and for me, I need to sign in javascript as I'm using chromebook as offline machine for even higher security.

不过titan下轻钱包可行性有点问题，你不提供私钥，又不下载区块，这样你没办法知道你的账户收了多少钱，没人可以帮你查询。

记得BM说过有observer的方案，应该可以解决这个问题。

In the meantime if you want to connect to the network for the first time:

Code: [Select]

network_add_node "107.170.172.14:46952" add
network_add_node "188.138.107.159:56497" add
network_add_node "146.185.186.245:8701" add
network_add_node "106.185.26.162:8761" add
network_add_node "107.170.30.182:8701" add
network_add_node "107.170.172.14:8701" add
network_add_node "162.243.219.145:8701" add
network_add_node "107.170.170.214:48387" add
network_add_node "95.85.33.16:8764" add
network_add_node "84.238.140.192:8701" add
network_add_node "176.9.234.166:8701" add

network_add_node "162.243.219.145:8701" add



Edit:
Works now after wiping the data dir but the sync is very slow with 1000+ for about half an hour.
End of edit.

Didn't work for me with the latest code.

(wallet closed) >>> about
{
  "bitshares_toolkit_revision": "9ed7cd7ce32914af1cb5055140f30f51351ec1d7",
  "bitshares_toolkit_revision_age": "78 minutes ago",
  "fc_revision": "0fced2ddffb380572ed50c181e8496a9d8777a62",
  "fc_revision_age": "80 minutes ago",
  "compile_date": "compiled on Jul  4 2014 at 07:41:33"
}

(wallet closed) >>> network_add_node "188.138.107.159:56497" add
OK
(wallet closed) >>> network_add_node "146.185.186.245:8701" add
OK
(wallet closed) >>> network_add_node "106.185.26.162:8761" add
OK
(wallet closed) >>> network_add_node "107.170.30.182:8701" add
OK
(wallet closed) >>> network_add_node "107.170.172.14:8701" add
OK
(wallet closed) >>> network_add_node "162.243.219.145:8701" add
OK
(wallet closed) >>> network_add_node "107.170.170.214:48387" add
OK
(wallet closed) >>> network_add_node "95.85.33.16:8764" add
OK
(wallet closed) >>> network_add_node "84.238.140.192:8701" add
OK
(wallet closed) >>> network_add_node "176.9.234.166:8701" add
OK
(wallet closed) >>>
(wallet closed) >>> network_add_node "162.243.219.145:8701" add
OK
--- there are now 4 active connections to the p2p network
--- there are now 3 active connections to the p2p network
--- there are now 4 active connections to the p2p network
--- there are now 3 active connections to the p2p network
--- there are now 2 active connections to the p2p network
--- there are now 3 active connections to the p2p network
--- there are now 4 active connections to the p2p network
--- syncing with p2p network, 8797 blocks left to fetch
--- there are now 5 active connections to the p2p network
--- there are now 4 active connections to the p2p network