I have write a  script to test toolkit automation
this can used to test some condition like flood transaction
I think somebody maye need this too
#!/usr/bin/expect -f

set timeout -1

set wallet_name "default"
set account_from "alt"
set account_to "delegate-alt"
send_user "wallet name is: $wallet_name\n"
send_user "wallet passphrase: "
stty -echo
expect_user -re "(.*)\n"
stty echo
set wallet_pass $expect_out(1,string)

spawn ./bitshares_client --server --httpport 9989

expect -exact "--- there are now 1 active connections to the p2p network"
expect -exact "(wallet closed) >>> "
send -- "info\r"
expect -exact "(wallet closed) >>> "
send -- "wallet_open $wallet_name\r"
expect -exact "$wallet_name (locked) >>> "
send -- "wallet_unlock 999999\r"
expect -exact "passphrase: "
send -- "$wallet_pass\r"
#expect -exact "$wallet_name (unlocked) >>> "
#send -- "wallet_rescan_blockchain\r"
sleep 2
expect -exact "$wallet_name (unlocked) >>> "
send -- "wallet_transfer 10 DRINK $account_from $account_to \"test flood...\"\r"
expect -exact "$wallet_name (unlocked) >>> "
send -- "wallet_transfer 11 DRINK $account_from $account_to \"test flood...\"\r"
expect -exact "$wallet_name (unlocked) >>> "
send -- "wallet_transfer 12 DRINK $account_from $account_to \"test flood...\"\r"
expect -exact "$wallet_name (unlocked) >>> "
send -- "wallet_transfer 13 DRINK $account_from $account_to \"test flood...\"\r"
expect -exact "$wallet_name (unlocked) >>> "
send -- "wallet_account_transaction_history\r"
interact
#expect -exact "$wallet_name (unlocked) >>> "
#send -- "exit\r"
#expect eof


bts 的 p2p 网络建立节点连接依赖于 upnp 特性，所以请大家打开路由器上的 upnp 选项，这样别人才能和你建立连接，
我们的 p2p 网络才足够健壮。否则可能像现在一样，开了一整天，只能建立一个连接。
打开 upnp 不会增加你的安全隐患，关于 upnp 介绍参考以下连接:
http://baike.baidu.com/view/27925.htm

Quote from: alt on May 28, 2014, 01:12:53 am

I saw network_num_connections is always 1
so I check the netstat, I am wondering why so many state is SYN_SENT?
It's because of firewall?
or does the p2p network depend on upnp when the node is behind a local gateway?

Code: [Select]

alt@alt-ThinkPad-T430s ~ $ netstat -nap | grep bitshares
tcp        0      0 0.0.0.0:5678            0.0.0.0:*               LISTEN      22148/bitshares_cli
tcp        0      0 127.0.0.1:5679          0.0.0.0:*               LISTEN      22148/bitshares_cli
tcp        0      0 127.0.0.1:5680          0.0.0.0:*               LISTEN      22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        223.65.189.69:5679      SYN_SENT    22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        79.173.81.171:5678      SYN_SENT    22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        223.65.189.69:36560     SYN_SENT    22148/bitshares_cli
tcp        0      0 10.10.40.72:5678        107.170.30.182:5678     ESTABLISHED 22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        171.105.59.67:5678      SYN_SENT    22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        42.2.241.201:5678       SYN_SENT    22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        112.64.144.162:5678     SYN_SENT    22148/bitshares_cli
tcp        0      1 10.10.40.72:5678        93.48.105.80:5678       SYN_SENT    22148/bitshares_cli


Right now it depends upon UPNP...

Dan,  I am a little  confused with git submodule, mabe git subtree is more suitable for us?

https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt
git-subtree(1)
==============

NAME
----
git-subtree - Merge subtrees together and split repository into subtrees


SYNOPSIS
--------
[verse]
'git subtree' add -P <prefix> <commit>
'git subtree' add -P <prefix> <repository> <ref>
'git subtree' pull -P <prefix> <repository> <ref>
'git subtree' push -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]


DESCRIPTION
-----------
Subtrees allow subprojects to be included within a subdirectory
of the main project, optionally including the subproject's
entire history.

For example, you could include the source code for a library
as a subdirectory of your application.

Subtrees are not to be confused with submodules, which are meant for
the same task. Unlike submodules, subtrees do not need any special
constructions (like .gitmodule files or gitlinks) be present in
your repository, and do not force end-users of your
repository to do anything special or to understand how subtrees
work. A subtree is just a subdirectory that can be
committed to, branched, and merged along with your project in
any way you want.

They are also not to be confused with using the subtree merge
strategy. The main difference is that, besides merging
the other project as a subdirectory, you can also extract the
entire history of a subdirectory from your project and make it
into a standalone project. Unlike the subtree merge strategy
you can alternate back and forth between these
two operations. If the standalone library gets updated, you can
automatically merge the changes into your project; if you
update the library inside your project, you can "split" the
changes back out again and merge them back into the library
project.

For example, if a library you made for one application ends up being
useful elsewhere, you can extract its entire history and publish
that as its own git repository, without accidentally
intermingling the history of your application project.

[TIP]
In order to keep your commit messages clean, we recommend that
people split their commits between the subtrees and the main
project as much as possible. That is, if you make a change that
affects both the library and the main application, commit it in
two pieces. That way, when you split the library commits out
later, their descriptions will still make sense. But if this
isn't important to you, it's not *necessary*. git subtree will
simply leave out the non-library-related parts of the commit
when it splits it out into the subproject later.

I have a laundry list of items that need to be addressed.  There have been a number of requests discussed in this thread and in the attack thread that are causing some delays.   Things I need to handle are:

1) Enforce minimal market depth.
2) Increase default collateral requirement to 10x.
3) Fix a bug where wallet loading errors erase wallet contents.
4) Cover a position without requiring additional capital.

针对bts交易攻击，以上是 bm 的4点修改计划。今天bm又提交了部分代码，市场深度是要求买单/卖单都有1%的xts。

Initial code for tracking market depth prior

Requires at least 1% of the shares to be on each side of the market
before automatic trading will execute for a given pair.

有几个问题：
1. 对xts有16个资产，如果想交易，买单卖单就要保证至少 32%的xts挂在市场上，不知道这样是否会压抑市场交易？
2. 这个市场深度好像无法有效保护攻击，有10%xts 就很可能发动攻击。
比如bitusd的买单，总共有4万个xts，要买4000万个bitusd。我先挂 1xts买 1万亿bitusd，再按10倍抵押，拿40万个xts，发行10亿亿个bitusd，把买单打穿，同时我的最低价成交，获得1万亿 bitusd。
实际攻击成本可能更低。在市场上bitusd买单本来就不多，比如 4千个xts的时候，我自己挂1个xts买1万亿bitusd，同时挂4万个xts买10亿亿bitusd（仅仅是为了满足市场深度的限制，不需要成交）。然后我只需要拿出10倍抵押，也就是4万个xts发行10亿亿bitusd，最后卖给自己1万亿。

我觉得解决办法应该抓住两个重点：
1. 对发行bitusd的卖单可以做延迟，比如1小时之后才能成交，这样买单会有博弈，发行的bitusd无法保证被自己拿到，增加攻击风险。
2. 对发行bitusd的价格可以做限制，比如涨跌幅度不能超过10倍。

BTS网络可以赚取交易费盈利，从而给所有持有 xts  者分红。
所有被直接销毁的交易费就是BTS网络赚取的利润，因为xts总量减少，所以每个xts相对升值了。
客户端钱包显示的用户xts余额，实际上是 xts 数量*400万/(400万-总的销毁交易费)。为便于描述，我把单位定义为 yts吧。

下面问题就来了

比如我最开始挂了个单子，卖 1yts，换 1000 usd。这个单子一致没成交。现在 xts 分红了，总量只有399万了。
我这个卖单是继续 1yts 换 1000 usd，还是变成  400/399 yts 换100usd？
现在的代码中会按 400/399 yts 卖出去。就是把本该属于我的分红，通过降价转移到了买家那里。

经过和网友们讨论，yidaidaxie给出了一个方案，在成交算法中要考虑到分红。多出的 yts应退还给我。

除了成交算法，强制平仓里面也应该考虑这个因素，不要忽略分红导致的 xts 增值。

I have an idea about margin call.
For example, I short 1000 usd with 2bts  backing.
when the price is up to 1000 usd /1.5  bts, margin call excute.
forced  execute  a buy order: buy 1000 usd with price 1000usd/1.5bts.
this buy order can not be cancel.
and 5% fee of bts will assessed.

the one who hold bitusd have two choice: sell bitusd with 1000usd/1.5bts, or hold continue to sell for more high price.

From this we can avoid to create bitusd with no backing.

比如我以2bts抵押发行了 1000 bitusd。
当bitusd涨到超过 1000 usd/1.5bts 时会执行强制平仓。
网络强制挂出一个买单：按  1000usd/1.5bts 的价格，买 1000 usd。
这个买单无法撤销。5% 的平仓费用被扣除。

持有bitusd的人有两种选择：按1000usd/1.5bts 价格卖掉获利；或者选择继续持有等待更高价格，当然风险自担。
这样能避免生成无抵押的 bitusd。

按白皮书所说，应该是按当前市场的最高买价判断是否需要强制平仓。
如果需要强制平仓，选取欠缺幅度最大的空头，用冻结的 bts 以当前市场上的卖单价强制成交。
问题是，如果当前市场上的卖单价很高，保证金不够用怎么办？甚至极端情况下，当前市场上根本就没有卖单呢？

User’s   who   do   not   negotiate   a   trade   ‘off   chain’   can   place   their   bids/asks   on   chain.   After   a   miner
has   processed   all   transactions   he   has   received,   he   will   pair   all   compatible   bids/asks   in   highest
bid   to   lowest   ask   order.   Once   all   trades   that   can   be   made   are   made,   the   block   chain   will   be   left
with   buy/sell   spread   of   unfulfilled   orders.   These   orders   represent   the   market   consensus   that   the
true   price   is   above   the   buy   and   below   the   sell.   At   this   point,   the   buy   price   is   checked   against
the   margin   requirements   of   all   short   positions   and   any   short   position   with   insufficient   margin   is
forced to accept the current sell price with the lowest margin position being executed first.

中文翻译

那些不愿意进行“离链”谈判的用户可以将他们的买卖单放入块链当中。当矿工处理完接受到的所有交易数据时，他会把所有相容的买卖单按最高的买入价和最低的卖出价顺序配对。一旦所有能够匹配的交易完成，块链会将剩下未履行的买卖单列表。这些订单表示市场的共识价格在在买入价和卖出价之间。这个时候，会根据买入价检查所有空头仓位的保证金要求，所有保证金不足的空头仓位都会按当前卖出价进行强制平仓，保证金欠缺幅度最大的空头仓位将被首先平掉。

“Everything in the world is about sex except sex. Sex is about power.”

― Oscar Wilde

In this chain, every girl can claim herself as a custom bitaccess, include:
1. BitGirlPic： use this  to watch the pictures.
2. BitGirlLive:   use this to watch the live show.
everyone can buy/sell these bitacces with bts to accept service