Quote from: JonnyBitcoin on January 29, 2016, 12:15:55 am

For simplicity once the order is placed on the books at +10% maybe it should be left there. Trying to adjust it adds un needed complexity.
even if the order isn't executed for months it will still be good for the system as it adds depth.

Simple is best. Perhaps the committee should collect and sell the fees on the first day of every month and leave them there.
This would make it simple for the rest of us to quickly audit what has happened.

What to do with the BTS earned from the sells though?

Recharge the fee pools.

@abit ah.. yes, sorry, wrong quote.. I'll try again:

I wanted to offer a simpler approach to the issue of CER changing mid-transaction.

The problem: if you pay fees with a UIA who's CER happens to drop before your tx is processed, then your transaction will be rejected.

To avoid rejection of transactions, we can have the GUI slightly overpay UIA fees.

How much you overpay can be a setting in the wallet. The default could be 1%.

It will prevent this problem 99.9% of the time.

If you want to save a few cents at the risk of rejected transactions, you could set it to 0%.

I like this approach because it doesn't require changes to witness_node or the protocol. (afaik)
You can already overpay in the CLI.. so I think essentially it can be used as a form of 'rejection insurance' as a GUI feature too. Wouldn't this solve it?

Yes, it's a good idea, simple and effective. Thanks!

It seems that this transaction is unable to be included into the chain:
{"ref_block_num":53301,"ref_block_prefix":3943068053,"expiration":"2016-01-28T23:15:39","operations":[[2,{"fee":{"amount":10000,"asset_id":"1.3.0"},"fee_paying_account":"1.2.97184","order":"1.7.31917","extensions":[]}]],"extensions":[],"signatures":["201c4f122098dba6a959035c686b260b46018c4fd1c3bae71a1a087640cbea174a575391f56afa8a3b145e2790821fbc407fa904fb7acb2dcd5f04ca1e9b921314"],"operation_results":[[2,{"amount":1,"asset_id":"1.3.781"}]]}


i am right that the tradingfees are not going to the referrals?

i think the real problem is that, not every fee is shared with the referral.

Trading fee? You mean %-fee? If so, it's set by the issuer and go to the issuer for sure, why referrals?
I believe the 10 BTS order placing fee is shared with referral program.

The asset you created is there, you just need some patient when opening your account -> asset page.

For migration, please check http://docs.bitshares.eu/bitshares/migration/index.html

Some data related to DacPlay here (dig from the block chain data):

bts.api (registrar):
Lifetime fees paid   58,100 BTS
Cashback   82,300 BTS
Registered Accounts (200+)

cryptofresh (referrer, but also a referrer of OpenLedger): 
Lifetime fees paid   34,900 BTS
Cashback   90d - 14,820 / 27,830 BTS
Referred Accounts (50)

btsabc (referrer):
Lifetime fees paid   20,140 BTS
Cashback   90d - 2,100 / 6,620 BTS
Referred Accounts (69)

ebit (referrer):
Lifetime fees paid   7,620 BTS
Cashback   242.3 BTS
Referred Accounts (29)

www.bts-hk (referrer):
Cashback   64.2 BTS
Referred Accounts (11)

A dump?

Quote from: svk on January 27, 2016, 06:15:26 pm

Quote from: xeroc on January 27, 2016, 03:28:18 pm

nothing you can do on your end since you have to receive the data before you can filter it ..

No there is, what I'm saying is he needs to filter the outgoing data from the witness node using a proxy server. A node websocket server using socket.io should do the trick. He would need to host his own witness_node then obviously.

So, I would need to have the mobile wallets all connect to one dedicated witness node? Could we just have a few/all of the Witnesses provide this as an option to their service? So, for mobile clients, the Witnesses will only serve up just the filtered stuff? Heck, this might be a great value-add for all Witnesses, no? Many more mobile wallets will be released after our I'm sure. Thoughts?

Sounds like a paid service? Interesting..