Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: How BitShares Prevents Front Running [BLOG POST]  (Read 775 times)

0 Members and 1 Guest are viewing this topic.

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.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12058
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: You Can't Front Run BitShares [BLOG POST]
« Reply #1 on: January 29, 2015, 04:53:00 PM »
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 »
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline carpet ride

  • Hero Member
  • *****
  • Posts: 544
    • View Profile
You Can't Front Run BitShares [BLOG POST]
« Reply #2 on: January 29, 2015, 05:51:00 PM »
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 liondani

Re: You Can't Front Run BitShares [BLOG POST]
« Reply #3 on: January 29, 2015, 06:23:12 PM »
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...   :)
  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #4 on: January 29, 2015, 07:15:22 PM »
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 monsterer

Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #5 on: January 29, 2015, 08:31:46 PM »
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: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #6 on: January 29, 2015, 08:44:53 PM »
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

Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #7 on: January 29, 2015, 08:48:11 PM »
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: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #8 on: January 29, 2015, 08:49:25 PM »
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?

You don't know the IP address of the delegate to protect against DDOS attacks.

Edit: And even if you did it would still be prudent to encrypt to protect against man-in-the-middle attacks.
« Last Edit: January 29, 2015, 08:56:15 PM by arhag »

Offline liondani

Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #9 on: January 29, 2015, 08:52:08 PM »
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).

I am sure Bytemaster will seriously consider your proposals... (at least I hope so)
  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline monsterer

Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #10 on: January 29, 2015, 08:59:19 PM »
You don't know the IP address of the delegate to protect against DDOS attacks.

Edit: And even if you did it would still be prudent to encrypt to protect against man-in-the-middle attacks.

Yes, I suppose that is prudent. In that case can't the sender just use whatever technology the encrypted memo stuff uses to encrypt the transaction only for the delegates account, or something?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #11 on: January 29, 2015, 09:11:17 PM »
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.

If you want to "buy in bulk" then you can still get good deals, just not "instantly".    The wallet can submit one order every 10 seconds to take the best offer on the table at that point in time.   From the user's perspective it is very similar to a market order it just isn't filled "instantly".
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.

Offline monsterer

Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #12 on: January 29, 2015, 09:15:05 PM »
If you want to "buy in bulk" then you can still get good deals, just not "instantly".    The wallet can submit one order every 10 seconds to take the best offer on the table at that point in time.   From the user's perspective it is very similar to a market order it just isn't filled "instantly".

This is a horrible idea in practice, though - you'll wind up missing out on the best price in fast moving markets and you'll pay more in transaction fees to boot. In addition, you'll end up placing limit orders instead of buying the top of the book if someone gets there before you.
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: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #13 on: January 29, 2015, 09:17:08 PM »
Yes, I suppose that is prudent. In that case can't the sender just use whatever technology the encrypted memo stuff uses to encrypt the transaction only for the delegates account, or something?

Sure. It can use a one-time public key included in the transaction, EC multiply its corresponding private key with the delegate's public key, and use the corresponding shared secret to do symmetric encryption of any sensitive information in the transaction. Not all information in the transaction would be encrypted. Certainly not the one-time public key, but also the information that proves the transaction signer is paying the appropriate valid transaction fee (or has already paid it with the previous commitment transaction) is important to make public so that the nodes can know to relay the transaction forward and not be susceptible to DDOS attacks. Then when the delegate receives this semi-encrypted transaction it would use its private key and do EC multiplication with the one-time public key to get the shared secret that decrypts the sensitive information, such as the market the limit order is in, the quantity, and the specified price limit of the order.

julian1

  • Guest
Re: How BitShares Prevents Front Running [BLOG POST]
« Reply #14 on: January 29, 2015, 10:05:08 PM »
I made a comment in technical support about an alternative,

Quote
The potential for front-running exists because a delegate can see the unconfirmed order tx, and has the opportunity to insert a new tx in the block to take advantage of it.

Could this be avoided by simply changing the market-engine so that unconfirmed orders in inventory are only tested/matched against orders that have already been confirmed/written to the blockchain?

If orders in inventory are never matched against each other then won't that eliminate the delegate's ability to front-run the trade?

I'll also add that I don't think the current approach is ideal for a few reasons.

1. There's a whole body of economic theory devoted to studying the principle of Consumer Surplus (http://en.wikipedia.org/wiki/Economic_surplus), which is the difference in price that two parties are willing to contract for according to their preferences compared with the equilibrium market price. It's considered a foundation benefit of the free market by economists, and the Bitshares market-engine currently ends up distributing that benefit to the currency holders via burning instead of the contracting parties by giving a better outcome than a centrally determined option.

2. It's contrary to other market matching engines, and will be very off-putting to any professional (fx)  trader that we might want to attract.

2. For my own project http://xchain.info which is a Bitcoin to Bitshares UIA asset exchange platform, I wanted to offer a Bitcoin to other bitAsset option by playing a market maker. However offloading my own risk by making automated counter trades on an external exchange like bter/btc38 is a lot more difficult due to the different market-engine mechanics.

 

Google+