Author Topic: How BitShares Prevents Front Running [BLOG POST]  (Read 4828 times)

0 Members and 1 Guest are viewing this topic.

Offline monsterer

Right, if you do what I said in my post above and you encrypt the reveal transaction for only delegate that is producing the block after the block in which the commitment transaction exists in,

Not sure I see the need the need to encrypt anything - if you're only sending orders to the next delegate, no one else sees them anyway?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I actually dislike the method bitshares uses to achieve this because it results in a lot worse deals for traders who want to buy in bulk from the exchange.

IMO a better idea would be to consider something like the transparent forging proposal in NXT whereby orders are sent only to the next delegate who will produce a block (which is easy to know in advance), thereby preventing anyone but the delegate from performing front-running. Since you're already trusting them to produce blocks, I don't think this changes the risk profile much.

Right, if you do what I said in my post above and you encrypt the reveal transaction for only the delegate that is producing the block after the block in which the commitment transaction exists in, and you make sure that YGWYAF orders are executed in the block after they are placed and are all executed before any other market/limit orders that are to be executed in the same block, then we can have a pretty good system.

It would allow people who want to use YGWYAF orders to use them as they usually do and know that the DAC will be the one to front run their order and give the proceeds back to the shareholders. Then anyone who chooses to do a market/limit order will know that only the delegate producing the block that will hold their reveal transaction is the one that can front run their order (and even then there is some probability that they won't be successful at it even if they try).
« Last Edit: January 29, 2015, 08:47:49 pm by arhag »

Offline monsterer

I actually dislike the method bitshares uses to achieve this because it results in a lot worse deals for traders who want to buy in bulk from the exchange.

IMO a better idea would be to consider something like the transparent forging proposal in NXT whereby orders are sent only to the next delegate who will produce a block (which is easy to know in advance), thereby preventing anyone but the delegate from performing front-running. Since you're already trusting them to produce blocks, I don't think this changes the risk profile much.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I think it would be interesting to study the probabilities of a successful front run attack in the two-stage commit and reveal model. The attackers need to put in the commitments to their front run transactions that are built based on guesses of what it will take to front run a potential market/limit order. They put in these commitments (and pay a small transaction fee for each commitment to a transaction) in every block in which a market transaction commitment has been submitted (or a subset of these depending on the state of the order book in the markets they are targeting and how profitable they think their guess will be). Then in the next block when they can see the various reveals, they need to decide which of their transaction commitments (if any) to reveal in that block to successfully front run and make a profit (or at least cut their losses from the commitment transaction fees). The probability can be further reduced by half (or more if they are competing with other front running attackers) if the order in which the revealed market/limit orders are processed is further randomized (say using the random number generated thus far by the addition of the random number, which was committed to in the previous round, revealed by the current block-producing delegate).

Depending on the transaction fee imposed for the commitments to market/limit orders (obviously it cannot be too high or else users will find it unacceptable) and the state (the liquidity) of the order books in the relevant markets, the probability of an attacker having a successful front running transaction committed in the previous block could be so low that the entire attempt would be unprofitable on average. In which case, no rational actor would even attempt to front run.

My guess, however, is that given the typical state of the order books and the highest acceptable transaction fee for market/limit order commitments, it will be profitable enough for front runners to pull this off. In which case, we are worse off than just having the front running proceeds go to the shareholders through enforced YGWYAF orders.

Too bad.  :(
« Last Edit: January 29, 2015, 07:17:12 pm by arhag »

Offline liondani

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: liondani
Thank you .. I am here at the P2P financing conference @ frankfurt and am handing hard time to describe this very concept!
having something to point people to helps big time!


I would be in the same position as you...   :)

Offline carpet ride

  • Hero Member
  • *****
  • Posts: 544
    • View Profile
Worth mentioning Flash Boys in this post?  And what criticisms, if any do you have of FB?


Sent from my iPhone using Tapatalk
« Last Edit: January 29, 2015, 05:59:21 pm by Stan »
All opinions are my own. Anything said on this forum does not constitute an intent to create a legal obligation between myself and anyone else.
Check out my blog: http://CertainAssets.com
Buy the ticket, take the ride.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Thank you .. I am here at the P2P financing conference @ frankfurt and am handing hard time to describe this very concept!
having something to point people to helps big time!
« Last Edit: January 29, 2015, 05:59:48 pm by Stan »

Offline bytemaster

« Last Edit: January 29, 2015, 07:16:49 pm by Stan »
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.