I have some question about the maching algorithm:
1. how about the maker-taker ?
    http://www.marketswiki.com/mwiki/Maker-taker
   
2. A short 1000 usd with price 10usd/bts
    B short  1000 usd with price 100usd/bts
    C buy 1000 usd with price 1usd/bts
I think the result is C buy 1000 usd from B, with  price 100usd/bts.
but now, the result is C buy 1000 usd from A, with price 1 usd/bts.

Sorry for my poor Englist.

假定现在的市场是这样的：
1. A拿出 10bts，以 100 usd/bts 价格发行 1000个usd
2. B拿出 10bts，以 10 usd/bts 价格下单买 100 个usd

按现有算法成交结果：B 交出 10 bts，获得 100 usd；
A卖出 100个usd，对应抵押11(1+10)个BTS，剩下的 9bts 继续挂 100usd/bts发行价。

我认为合理的算法应该是:
B 应该按A的发行价100usd/bts，拿出 1 bts获得 100 usd，剩下9个 bts应保留。
A卖出的 100个usd，对应抵押应为 2(1+1)个BTS

http://www1.agsexplorer.com/#

2014-01-21 23:54:34    Pnx4ZC3RSbMnKdhvGrqqkvakJNNPw4J88k    tx    0.0001 PTS
2014-01-21 23:54:34    PbX9dBdhhAMcn5zepxLKhgKue5oURZ4pyo    tx    0.0099 PTS
2014-01-21 23:54:34    Pjo3PyxRvxLvYezG7WFeUUYbTJBMcJHJTw    tx    30.0 PTS
2014-01-21 22:11:04    PjdiYHfdD5RSb92g1SqQjjNy8eQhsuw4oR    tx    50.0 PTS

bts交易会基于pos+共识机制，交易确认时间小于30s。
对于pos和共识在区块链生成的过程中分别起到什么作用一直没理解，有人懂了吗？
https://bitsharestalk.org/index.php?topic=1138.msg29905#msg29905

There is never an opportunity for a 'chain fork' because of the ripple style consensus algorithm used to extend the chain.  Those who create transactions are merely signing the global consensus ledger and making it impossible for the core consensus nodes to create an alternative chain.

Ripple operates just fine without TaPOS so the only thing TaPOS is doing is making the ledger signing more distributed and harder to forge than in ripple alone. 

So the proper comparison is Consensus + TaPOS.

Failure to agree is agreeing to fail as Ripple states it.

I would like to make a point about decentralization:  Separation of Powers is decentralized even if there is only one party trusted with a given task at any given moment.   

Suppose for a second you had the following situation: a single server that signs every block and distributes it to everyone.  Yikes "that is centralized!" most people would complain, but lets examine the 'power' this server has?

1) It is well known and thus cannot get away with a double spend.
2) It cannot change the history of the block chain, everyone else has cemented the server's prior signatures in stone via TaPOS
3) It cannot produce alternate chains for different users because all users are comparing notes as to the current head block.
4) It cannot change the validation rules arbitrarily because every block produced must be validated by all nodes or all transactions stop until someone else can be appointed the block creation role.

So it seems that the only power this ONE node has is to select which transactions to include.   This is no different than one or 2 nodes in the bitcoin network or any network based upon proof of work.   

The last step toward decentralization is robust automatic failover in the event this one node is shutdown or attempts (but fails) to comment fraud.   Systems like Ethereum automatically shift who has this role every single block based upon a mining lottery.  Even their POS system is based upon a mining lottery where the ease of mining is adjusted by your balance.  Here you still centralize the process of selecting transactions ONE BLOCK at a time, you just have very short term limits.  Dictator for a block if you will.

Consensus is simply an algorithm to decentralize the process of selecting which transactions go into every block and to provide robust automatic failover in the event a single node goes down.

现在群发邮件的实现方式是对每个收件人单独发送一个加密邮件到p2p网络上，这样导致对带宽、硬盘的很大浪费。

所以我对此做了一些修改
1. 随机产生一个aes key，用这个aes key加密邮件内容。
2. 增加一块数据，把这个 aes key用收件人的公钥加密，保存这个加密后的aes key列表，这样只有列表中的人才能得到  aes key并解密邮件。
只需要把这个邮件发送到网络，所有收件人都能收到了。

但是这个新增加的数据块导致与旧版本的bts不兼容，无法互相发送邮件，所有人都升级到新版本才能没问题。

所以我没把这个修改提交到 github，只在论坛提了下建议，不知道为什么没人回复，是不是我英文太烂了啊。大家觉得这个修改有用吗？如果觉得有用去帖子下帮我用英文再补充一下吧。
https://bitsharestalk.org/index.php?topic=2177.0

When I send a mail to many peaple, client will send too many mails to the network, each one for a person. When the mail is large, with an attachment, It's very Inefficient。I think we should broadcast only one mail to the network。

1. generate a random key: aes_key
2. encrypt mail with this key:
    em.data = aes_encrypt( aes_key, fc::raw::pack(*this) );
3. encrypt this aes_key to the vector for all receive
    for(n=0, n++, n<sizeof( reiceivelists))
{
    auto priv_dh_key = fc::ecc::private_key::generate();
    em.dh_key_list[n]        = priv_dh_key.get_public_key();
    auto aes_key2      = priv_dh_key.get_shared_secret( reiceivelists[n] );
    em.aes_key_list[n] = aes_encrypt( aes_key2, fc::raw::pack(aes_key) );
    em.check[n] = ......
}

every receiver can decrypt the aes_key correct with their own public key. then decrypt the mail with the shared aes_key.
The problem is: this will change the data struct of encrypted_message, the old client can not receive mail which send from new client  ....
I think there is a good chance to do it before the real release at the end of Jan.

every time I want to send pts to others, always ask me for a fee of 0.01 pts. I don't know why, here is the info:

This transaction is over the size limit. You can still send it for a fee of 0.01 PTS, which goes to the nodes that process your transaction and helps to support the network. Do you want to pay the fee?