这个不是bug，是你钱包里面有bitcny存在，你平仓的时候就会显示利息产生，这个利息是指你钱包存在的bitcny产生的利息。我查了一下我的记录，也有好几个是这样的

不是bug才怪了。
平完仓，结果cny多了，bts反而少了。
yield那行是利息，才0.0001CNY。
还好只是显示bug。

BTW ... please also note that @toast has released a new version of the market_maker bot .. my bots are currently under-maintained due to lack of time

Yes, it's https://github.com/freetradebots/bts_bots

Steps:
1. submit an ask order which matches the highest bid order in the market, but have a volume greater than the bid order
2. wait for one block, so that the ask order list in the market and appear in GUI as cancel-able
3. try to cancel the ask order
4. wait for one block, the 'cancel' expire, the ask order executes
5. open transaction history page, or type 'wallet_account_transaction_history' in the console
5.1 balance column in the 'cancel' line shows N/A
5.2 balance column in the 'fill ask' line shows a (incorrect) value which equals to a value if the 'cancel' succeeded (in BTS)
5.3 balance column in the 'ask proceeds' line shows a corrent value (in BitAsset)
6. do other transactions, then check the history again, will see the following balances be messed up

Maybe an API issue.

BTW the 'balance' command returns a correct value.

Quote from: onceuponatime on January 24, 2015, 10:04:13 pm

Typing this in the console works for me:

wallet_collect_vested_balances <account_name>

Thank you!!!   If you have the time and know the answer ...

Is there a way to simply view the balances or do I have to collect them all to "see" them? 

Also, if I do this is there some penalty?

I remember months back when this was discussed that it was a 2 yr vesting(?) period and there was a penalty for pulling out early. But, things have changed so much and I never know which discussion (of possible paths to take) was the one that was finally chosen (there are a lot of paths here!). This is the hazard of being involved with many coins ... too much to follow, not enough time to follow them all as closely as they deserve.

wallet_check_sharedrop

可以走暴走的dacx搞个众筹

暴走的dacx网站上连个联系方式都没有。

Quote from: abit on January 25, 2015, 07:03:43 am

I think not only delegates but also every node (or say wallet) should check the market transactions inside new-produced blocks, if it contains bad transactions then just reject the block. The core code may already did so. No need for statistical analysis imho.

There is no "bad" market transaction. It is a perfectly valid transaction that was "lucky" enough to buy low and sell high. Of course, it wasn't actually "lucky", it was front-running. The front-runner is able to put in this transaction into the same block (and therefore as far as the blockchain is concerned both orders arrived simultaneously in time) as the transaction that it is "stealing" market savings from because it is at a more advantageous position in the block producing process: it is able to construct its front-running transaction after seeing the victim's transaction but before the deadline to include the front-running transaction into the same block is up.

I've already discussed how this could be solved by splitting market orders into two stages: a commitment followed later by a reveal. Unfortunately, this means that it would take 50 seconds for all market orders to go through rather than 10 seconds.

The compromise solution is to limit the potential front-runners to only the active delegates (by encrypting the market order transactions for the delegates only before broadcasting on the network) and to use statistical analysis to catch any misbehaving delegates. For the statistical analysis to work though, the encrypted transaction should not be capable of being decrypted by all 101 active delegates because then we have no way of confidently knowing which one of the 101 active delegates was the bad actor via statistical analysis. So, I recommend encrypting the market orders for only the next two block-producing delegates in the round.

OK, I understand now.
Usually an "evil" delegate won't submit orders by their own account, instead, they may submit the front running orders from a couple of other accounts. This may make the statistical analysis more difficult.
By the way, if you encrypt an order for a special delegate, what will happen if the delegate missed its block, even if be voted out of top 101?

Quote from: toast on January 24, 2015, 06:06:23 pm

It allows front-running by the block producers who can put mix their own orders into the block in whatever order they want. There's nothing you can do about it, so we do the worst-case matching every time and keep the profit for shareholders instead.

What are your thoughts on the solution to front-running discussed in this thread that allows for market/limit orders to be enabled while reducing the parties who could potentially front run orders to only the top 101 active delegates, and in which even that front-running risk is further protected against through statistical analysis?

I think not only delegates but also every node (or say wallet) should check the market transactions inside new-produced blocks, if it contains bad transactions then just reject the block. The core code may already did so. No need for statistical analysis imho.

Quote from: vikram on January 24, 2015, 10:07:19 pm

Quote from: CalabiYau on January 24, 2015, 08:14:21 am

I found the balances that have gone to UNKNOWN on the linux wallet.

Where did the second wallet come from? List the steps you took across both wallets in order.

1. win-wallet: wallet_collect_vested_balances <account_name x>
Result:  o.k., stake added to account x => details PM

2. linux-wallet: wallet_collect_vested_balances <account_name y>
Result: Some of the stake added to accounts, some getting "lost"  =>  details PM

3. win-wallet: account x  shows like the primary post,
The vesting claim in the linux-accounts changed the win-account.

There seems to be no "lock" after a successful claim somehow. 

Thank you for looking into this, but enjoy the Sunday anyway.

I suspect that you have (some) same private keys in both wallets.
Could you describe how you created the two wallets/accounts, and, have you export/import keys from one wallet to the other?