受托人ID：sunshine.clerk
名字：瑞波支付
团队：个人
硬件配置：Ubuntu 14.04.1系统，i7CPU8核，8G内存，1T硬盘，100M带宽。
技术能力：国内较早参与InvictusInnovations/BitShares，Keyhotee等代码测试，并有部分代码贡献；参与了bitshares_toolkit的DRY测试，了解BTSX命令钱包特性和受托人技能要点，在linux下编程开发多年，每天有充裕的自主时间，工作本身与互联网行业相关。
预计的手续费收取率：可做到较低费率运行，服务器在单位机房内，无个人费用支出。
以前为社区做过什么贡献：研读开源代码，努力发现技术以及运营黑点，促进bts事业健康发展
竞选宣言：做Bitshares网络最专业的代表，做一名合格的阳光记账员。

Quote from: cdryan on July 15, 2014, 12:35:11 pm

事实上我只理解了一点，燃烧是不是就是销毁？销毁的BTX，价值本质上转移到了剩下的每一个BTX，而产生的bit美元相当于系统向外开了1美元的借条。

如果系统能保证这一美元的借条，任何时候回来都能得到等价美元的BTX。。会不会出现bit美元（借条）换不到BTX？

出现极端情况，比如大型的系统性风险，让整个系统内的人都能做出未来将大跌几十倍的状况（3I被法办、中心化交易所被查封、软件系统性BUG），这就会造成所有人选择烧币在极短时间内将自己所持有的币全部烧成美元

这可能会造成整个系统在恢复后已经一个BTS都不剩或者只剩很少一点的状况，这样的话，BitUSD也将失去价值，整个系统崩溃

所以BTS的烧币不能是销毁，因为一旦是销毁，在BTS总量有限的情况下大家将倾向于持币不烧而等着升值，因为可以预期短期内就会涨得很厉害，这样容易做出一个整体上45度角一直上扬的趋势

类似于往气球里不断吹气，这个气球将会快速变大，而且没有出口，到一定程度的时候爆炸。

这样的话，整个交易所的崩溃是肯定的，只是时间问题，所以不能是销毁，因为市价不可能无限制上涨，而且一旦涨到某个程度，系统内的BitUSD会充盈产生过剩的通胀。BitUSD一旦超出市场的需要就很麻烦了，因为BitUSD没有任何出口（没有消失的机制），可能要么导致BitUSD本质上贬值进而无法锚定USD，或者导致剩余没燃烧的BTS失去意义。我感觉很可能会崩溃

比较合理的设置，应该还是借鉴现在的抵押机制；不要真正的燃烧BTS，而是暂时抵押在系统里，当系统内的BitUSD持有人想换回BTS的时候，可以通过市价去找系统内的BTS持有者购买，或者通过受托人像系统购买，这样可以维持BTS与BitUSD在系统内的平衡，同时可以制衡受托人的汇率，因为若是他代理烧币的价格不合适，我们可以选择不找他烧币而去寻找手上持有BitUSD现货想要出手的人。这样的话系统的内部竞争也更强。

然后这个机制能否准确锚定BitUSD与USD的真实价格，我觉得还不能确定
老锚定所依靠的我认为并不纯粹是多倍抵押，还要依靠的是社会共识机制，即我们大家都认为应该BitUSD=USD，一切都是在这个共识下去通过多空博弈完成
按照这个受托人代理烧币的抵押机制，实际上就是按照市价1：1抵押了，若是在每一刻所产生的BitUSD都是根据共识机制1:1抵押所得来，并且涨跌轻缓的时候我认为后续也有可能做到锚定
但在BTS价格暴涨暴跌之时，新的抵押（烧币）继续依赖市价，老的BitUSD存货是否也一定会根据汇率变动而和系统内的BTS进行交易达到平衡？（在BTS大跌的时候有可能系统内的BitUSD会看好后市上涨而买入BTS）
这个地方我昨晚想了很久，都没想清楚，结果就睡着了，一觉醒来想到哪里全忘了

双烧如何？BitUSD可以烧成BTS

Can you send some XTS to me for testing dry run 7?
mywallet (unlocked) >>> wallet_account_create jeffreylee
"XTS5i1eWiWThrZgYVjNruQZuZW2vQKZtjEeZjRJMqev3S9XnheFw9"

Quote from: alt on June 27, 2014, 12:01:39 am

Dan, I have an idea to balance the speed and security.
make the period dynamic.
suppose current block should generic by delegate-1 at 00:00:00 , next should by delegate-2.
If delegate-2 receive the block before 00:00:30, then generic next block at 00:00:30.
else if receive before 00:01:00, then generic next block at 00:01:00
we can set a max waitting time like 2 minutes, if delegate-2 still not receive block after 2 minutes, then it can ignore delegate-1.

I think a delegate can generate multi blocks in one turn.
more transactions received, should generate more blocks.
Just give a limit, like 4 blocks or 2 minutes. the period can improve to 15 seconds.
Give a msg to  network when quit, so next delegate can running.
If there are no transactions, don't generate block.

If a delegate find that its network speed is very slow, It can send a give up message to btsx network.so next delegate can running.

Current git-master is not compiling:

Quote

[ 86%] Building CXX object libraries/net/CMakeFiles/bts_net.dir/node.cpp.o
/home/coin/coins/invictus/bitshares_toolkit/libraries/net/node.cpp: In constructor

https://github.com/BitShares/bitshares_toolkit/issues/410

cd libraries/fc
git fetch --all
git pull

Quote from: JeffreyLee on June 26, 2014, 02:23:16 am

send to me some XTS for testing,
"native_pubkey": "XTS5zxMWxoPsPRCtSSWncPRujHFZpAxqkATCueCn5af6gamYcgxpX",

sent 111xts

thanks,has received.

I found a bug and fixed it.
Command json FILE generated json data format is error

pull requests url:
https://github.com/InvictusInnovations/BitShares/pull/26

bts is cleared?
>>> balance
0.00000000 bts
0.00000000 usd