new proposal to prevent front-running of trades

[zack]

I am building off of Paul's idea explained on page 25: http://www.truthcoin.info/papers/truthcoin-whitepaper.pdf

trade_shares needs to be split into 2 transactions: commit_trade, reveal_trade

commit_trade ex:  {pubkey, sig, hash}
this transaction costs a safety deposit. If you don't reveal within the next 10 blocks, then you lose your deposit.

reveal_trade ex: {pubkey, sig, market, shares}
This transaction reclaims the safety deposit you lost. sha256(reveal_trade) must equal the hash from the commit_trade.

The order that the trades are fed into the market maker is the order of the commit_trades rather than the reveal_trades.

[psztorc]

This pre-commit idea is the method used by Namecoin, and we have discussed it before in the front-running thread.

Under your proposal, maximum trade frequency would decrease from roughly (1 / second) to (1 / 10 minutes), a factor of 600. I would imagine it would be frustrating to have to wait that long just to discover if your order had gone through or not.

Wouldn't it be possible for front-runners to hash all {market , share} combinations, which would prevent the hash from really hiding anything? You could add salt, but that would cost more blockchain-space.

I assume the deposit is destroyed and doesn't go to anyone? Otherwise you are in strategy-hell.

What happens if I have 1000s of trades committed, but I reveal each them slowly in reverse commit-order over the next 10 blocks. The node must recalculate and rebroadcast the price each time, correct?

I suppose it depends on how concerned one is about front-running.

[koeppelmann]

that would mean that the current price is always 10 blocks old, right?

How would a order look like? You only define the amount to spend and the share type or a (maximum) price as well?

Who would get the safety deposit if the trade is not revealed? What % of the trade volume do you have in mind as a safety deposit?

[vbuterin]

Yep, this is pretty similar to an idea that I've seen in the bitshares circles. One of the only ways to do it.

The other strategy that Bitshares has is they do trading in batches, so txs get committed in phase 2k, and then revealed in phase 2k+1, and sorted by price and simultaneously evaluated at the end. One optimization (not sure whether or not they do it) is to have round k+1 of committing and round k of revealing happen at the same time.

Under your proposal, maximum trade frequency would decrease from roughly (1 / second) to (1 / 10 minutes), a factor of 600.

Hence why you make a faster block time, say 12s. I'm actually in the process of discussing the safety of our own algorithms for this with some academics at Cornell right now; will let you know the results if you are interested. I think something like 5 blocks for a commit+reveal phase can get you down to a 90s average confirmation time.

Wouldn't it be possible for front-runners to hash all {market , share} combinations, which would prevent the hash from really hiding anything? You could add salt, but that would cost more blockchain-space

Sure, but that would cost a large fee. The fee can be made to be proportional to the size of the trade if desired, although at some privacy cost (you would need to supply at least a rough idea of the size of the trade at commit time to make the fee enforceable). If you don't like that then you can have a two-level fee: a fee for not revealing during the reveal period, and a much higher fee for never revealing. This lets you enforce the smaller fee at reveal time and not subject users to too much risk since they only need to pay the larger fee if they are malfeasant.

[psztorc]

Under your proposal, maximum trade frequency would decrease from roughly (1 / second) to (1 / 10 minutes), a factor of 600.

Hence why you make a faster block time, say 12s. I'm actually in the process of discussing the safety of our own algorithms for this with some academics at Cornell right now; will let you know the results if you are interested. I think something like 5 blocks for a commit+reveal phase can get you down to a 90s average confirmation time.

The huge costs and risks of a faster interblock time are hardly worth this tiny issue of front-running resistance... Why you would even want more block headers at all is beyond me.

Wouldn't it be possible for front-runners to hash all {market , share} combinations, which would prevent the hash from really hiding anything? You could add salt, but that would cost more blockchain-space

Sure, but that would cost a large fee. The fee can be made to be proportional to the size of the trade if desired, although at some privacy cost (you would need to supply at least a rough idea of the size of the trade at commit time to make the fee enforceable). If you don't like that then you can have a two-level fee: a fee for not revealing during the reveal period, and a much higher fee for never revealing. This lets you enforce the smaller fee at reveal time and not subject users to too much risk since they only need to pay the larger fee if they are malfeasant.

I am referring to individuals building a big spreadsheet of { hash(Market A, Buy 1 share), hash(Market A, Buy 2 shares), ...,  hash(Market B, Buy 1 share), ..., ... }. So that they know what a trade is as soon as it happens, and can front-run as normal.

That would not cost a fee as the blockchain would never know about it at all.

( In fact, if the front-runner just wanted to front-run a victim, they could just submit the same hash and then spend 9 blocks trying to figure out what it was. Do you plan to force weird trades like {Market A, Buy 1.00000008465 shares}? )