New BSIP: charge additional fee for kill_or_fill orders

[abitmore]

The kill_or_fill feature was designed for significant positions (link). Technically, it causes much more load pressure to nodes, thus it's reasonable to charge a higher fee.

Due to lacking of auto-bridging feature (see #45), the kill_or_fill feature is mostly used by arbitrage bots to instantly make profits without risk, so it's a good idea to ask them to share some profits to the system. This kind of orders contributed a big part of fees (among all orders) to the system (@clockworkgr please comment).

Nowadays there are many bots competing in this field, with current mechanism the fastest bots win. A fast bot is able to quickly a) find the arbitrage opportunities, b) sign transactions containing fill_or_kill orders, and c) send the transactions to witnesses or next witness before other bots. Usually they'll sign and broadcast/spam much more transactions than actually needed, because this strategy may increase their chance of being included in next block, it's risk free because the redundant orders won't be included in new blocks thus won't be charged. They competes on faster hardware, faster network, better algorithms and etc. IMHO, having a few bots are good for the system because they do improve liquidity, but when having many bots, with current mechanism, the increased competition resulted in too little additional value to the network.

So, IMHO an even good idea is to introduce an auction mechanism, say, the orders that provided higher fees (sharing more profits to the system) would have higher priority when being included into next block. Although this would require a major modification on the transaction queuing algorithm which is not easy, I think it's worthwhile.

[pmconrad]

Technically, it causes much more load pressure to nodes, thus it's reasonable to charge a higher fee.

I disagree. A fill-or-kill order that is not filled will not even be relayed through the P2P net. If it does get filled it consumes even less resources than a normal limit order, because it doesn't end up in the database (it may even take some existing orders from the book).

Even if you take the additional API load from unfilled orders into account, it seems unfair to charge a successful fill-or-kill order more just because there are many (possibly unrelated) unsuccessful ones out there.

[abitmore]

The idea is to treat all the fill-or-kill orders as a whole. Behind every successful fill-or-kill order there are tens of failed orders that didn't pay a fee but have caused load pressure on nodes, some of them caused load on API nodes, some of them caused load pressure on p2p nodes (I guess some people are running modified API nodes that broadcast tx without evaluation). On the other hand, if a tx get included into the chain, it means profit, so reasonable to charge a fee.

The "possibly unrelated" argument doesn't sound. If you check your P2P logs you'll know most of them ARE related.

[abitmore]

Actually, if we talk about whether it's fair, IMHO auction makes perfect sense here. The ones who pay more will get the chance. If there is no competition (e.g. as you said an "unrelated order"), no additional fee would apply.

[pmconrad]

treat all the fill-or-kill orders as a whole

That's what I call unfair.

IMO load pressure on API and/or P2P from these transactions should be treated like a DOS attack. I might be a good idea to implement countermeasures against DOS anyway, i. e. find metrics / heuristics to detect malicious peers and/or clients, then disconnect and/or blacklist them.

Arbitrage as such is good for market health and should not be discouraged.

For an auction system you'd need a list of all competing transactions so you can choose the one with the highest fee. Our infrastructure currently does not support that - we don't hold conflicting transactions, we keep the first and discard the rest. Also, given a large set of potentially conflicting transactions, it is computationally infeasible to find the highest-paying subset of these that does not contain any conflicts. Finally, the auction system doesn't solve the problem, it makes it worse. Most of the competitors still don't pay a fee, but for the auction you must relay them all across the whole network.

[bangzi1001]

Any statistic about how much those bots make?

[CryptoKong]

I would suggest being vary careful in taxing the arb bots, they are what keep our markets in balance and create a hell of a lot of activity, if anything we want to be making them more efficient not less.

I am not against the proposal, we just need to tread carefully here any increase in fee will lower profitability and lower the amount of activity, I do quite like the auction approach though :)

[abitmore]

If we consider BitShares a business, we should think how to profit. Value of BTS token comes from the ability to profit in comparison to many of other cryptocurrencies. The fact is, nowadays some businesses built on top of BitShares platform are earning a lot, at the same time the platform is operating at a huge loss, this is one of the reasons that BTS token gained little interest.

When pricing a product (for us, E.G. a feature in the system), cost should not be the only factor to concern, the definition of "fair" is not obvious, although cost and "fair" are both important. The fact is our product brought value for the buyers, there is a lot of demand, but we don't know how much is the maximum a buyer would pay, that's why auction is a good idea. I do admit that we need great efforts and more cost to implement and run the auction mechanism. Actually it would be best to have a way to measure the cost and return, but not that important if we can't find one in short time. It's hard to make a perfect auction mechanism e.g. to achieve highest profit, but not that hard to make a "working" one as a start.

Profit margin depends on competition. With an auction mechanism in place, if there is less competition aka fewer activities, the remaining bots would profit easier or profit more, so there would be a balance. One fact is, market-making bots and traders provide liquidity by increasing depth of order books, arb bots merely reduce depth, although they do provide useful service to traders due to the lack of auto-bridging feature(#45).

To be clear, auction doesn't need to be built into protocol, it's not a protocol change, instead, it's mainly a change about block producing and transaction queuing which is related to local transaction processing and P2P. We don't need a hard fork. It would be totally compatible with old nodes, although the more nodes which implemented the feature, the better the effects. Yes, as @pmconrad said, those nodes would need higher cost to run, and may suffer DoS, these are the challenges we need to face.

[abitmore]

A related idea, maybe changing the game:

• no long pay witnesses from reserve pool, instead, pay them a part of additional fees earned from transactions.

Currently the witness job is too easy, in the meanwhile some thinks the return is too low.

The change rewards the ones who made more efforts, would lead to competition among witnesses, would attract competitive businesses.

To get best effects, we may need to change witness voting/scheduling mechanism.

[bangzi1001]

I agree to have a donation fee feature if users want higher priority when witnesses process transactions. This should apply to all type of transactions rather than just kill_or_fill orders (Arb bot alone don't really earn much per Arb).

Anyway, if witness job is easy then nobody will complaint about price feed. If witness pay is good enough like EOS, big players eg. Bitfinex will be attracted to become witness too.

[shulthz]

if users want higher priority when witnesses process transactions.

What‘s that mean？

[bangzi1001]

if users want higher priority when witnesses process transactions.

What‘s that mean？

Same concept as ETH, you pay higher gas price if you want your transaction process faster.

[xeroc]

IMHO, processing fill-or-kill orders should be limited on API level, like @pmconrad says. If public APIs limit it, those that want to use that feature have to provide value to the network by running their own node (it's recommended for bots anyways).

Hence, instead of limiting on-chain functionality, I'd much rather limit API functionality (or rates).

On a side note: The BBF uses fill-or-kill orders to be be able to do proper accounting as it doesn't not want to track order states and instead has each create_order be filled right afterwards (to its entirety). That makes post-processing (for accounting) much easier.

[abitmore]

I wonder, is it a good idea to simply disallow multiple orders with fill-or-kill flag enabled in one transaction?

[abitmore]

@xeroc it's not exactly an API issue, but also a P2P issue. When the bot owners are running their own node which is recommended, their transactions will be broadcast to every other nodes (peers) they connected via p2p, which will actually cause loads on all the peers.

[xeroc]

• If we consider BitShares as business, the extra feature for fill_or_kill could be considered premium feature that asks for an additional fee.
• From tech/ scalability POV, it doesn't make much sense as killed ops/txs don't make it onto the chain
• From market POV, it makes sense to allow arbitrators to do arbitrage cheaply ..

Difficult to optimize, this is

[abitmore]

@xeroc good summary.

[xeroc]

* 

Difficult to optimize, this is

Thinking about it, it's not the developers responsibility to make this decision, but the dev could build the option to make that decision into the chain - the committee then has to decide.

[abitmore]

Similar business goals could be achieved via BSIP 85: Maker Order Creation Fee Discount. Closing this one.