Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
I keep saying it and will say it again.
We need relative orders that allow orders to be placed in relation to the feed price and then move with it.
If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?
It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.
I'm against this because put a lot of trust in the publishing feeds and risk on the system since witness could easily manipulate the feed and run with a lot of money. Also this can easily be work around using third part tools or bots.
I'm actually talking about making a third party tool or bot to do what jonny's asking since you can't do it on the chain.
That's a fair concern about relying on someone else's data. You could use your own feed so it doesn't rely on anyone else.
Really? Do you have a list?I think metaexchange, but anyway we just start BTS 2.0, the system is in its infancy now, there's lots of tools coming out soon. I for instance am building something. Now it is time for take the ass off the chair and make the world we wish to see.
I keep saying it and will say it again.
We need relative orders that allow orders to be placed in relation to the feed price and then move with it.
If you had a script that did that, but you had to pay a transaction fee when the price drifted by some value from the original, would you use it?
It can be implemented using your own server (I'd make a worker to write the tool and split it with xeroc for using his library). But without a hardfork and some serious coding, it isn't immediately implementable on the chain.
I think the first step is to not charge nothing (except anti-spam prevention) for operations that locks up money in the system, like borrow, vesting or making our order book.Reducing call order update fee was discussed among committee members, and bitcrab did a survey IIRC.
http://www.investopedia.com/articles/active-trading/042414/what-makertaker-fees-mean-you.aspQuoteThe maker-taker plan harks back to 1997, when Island Electronic Communications Network creator Joshua Levine designed a pricing model aimed to give providers an incentive to trade in markets with narrow spreads. Under this scenario, makers would receive a $0.002/share rebate and takers would pay a $0.003/share fee, and the exchange would keep the $0.001/share difference. By the mid-2000s, rebate capture strategies had emerged as a staple of market incentive features, with payments ranging from 20 to 30 cents for every 100 shares traded.
I'm thinking give the incentive only to the short-seller-maker to reduce the premium and compensate for the added risk inherent with the short side in bitshares.
We are refunding 99% of order creation fee if it is canceled. So the cost to create/cancel is very small (just enough to prevent spam).
The end result is that the "order creation fee" becomes a "minimum fee" for filled orders which has the effect of preventing dust orders.
The minimum order fee will probably be similar to a transfer fee, $0.20 per filled order, $0.05 for lifetime members.
