Author Topic: Mercury, first fully decentralized exchange releases source code  (Read 5022 times)

0 Members and 1 Guest are viewing this topic.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
Quote
This protocol is definitely not made under the assumption that all parties are acting honestly, it would not be considered trustless if that were the case. Not going through with orders is much less critical than other types of attacks, since no funds would be stolen, the only damage is that funds will be locked up for a few hours before the refund unlocks.

However, this attack is completely solved by using security deposits: traders pay a one-time deposit or fee when they first begin using the trading platform to initialize their trading identity (which is pseudonymous). If the trader using that identity fails to go through with trades (they could possibly be given 3 strikes), the orderbook server will ban that identity, and the trader will have lost their security deposit. This mechanism makes it unprofitable to back out of trades.
Seriously? I can get banned from the central order book processing service?

Quote
Front running can be solved by including signatures along with orders that prove they are actually backed by unspent outputs, and by communicating over a p2p gossip network to ensure the orderbook is valid. These things will be worked on in the future, and will essentially make this model fully decentralized (but are more complicated, so Mercury's federated model should work fine until then). They will also require full node verification (or UTXO set queries), so they are not yet viable with SPV clients.
I hope the check for valid UTXO in any case ..
However, we might have different interpretations of front running .. but how does that prevent front running by the order processing entity? They can choose to process their own orders first!?
If you could go on BTCTALK and put forward your arguments a constructive and insightful discussion might arise ! ;)


Offline bitmeat

  • Hero Member
  • *****
  • Posts: 1116
    • View Profile

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Quote
This protocol is definitely not made under the assumption that all parties are acting honestly, it would not be considered trustless if that were the case. Not going through with orders is much less critical than other types of attacks, since no funds would be stolen, the only damage is that funds will be locked up for a few hours before the refund unlocks.

However, this attack is completely solved by using security deposits: traders pay a one-time deposit or fee when they first begin using the trading platform to initialize their trading identity (which is pseudonymous). If the trader using that identity fails to go through with trades (they could possibly be given 3 strikes), the orderbook server will ban that identity, and the trader will have lost their security deposit. This mechanism makes it unprofitable to back out of trades.
Seriously? I can get banned from the central order book processing service?

Quote
Front running can be solved by including signatures along with orders that prove they are actually backed by unspent outputs, and by communicating over a p2p gossip network to ensure the orderbook is valid. These things will be worked on in the future, and will essentially make this model fully decentralized (but are more complicated, so Mercury's federated model should work fine until then). They will also require full node verification (or UTXO set queries), so they are not yet viable with SPV clients.
I hope the check for valid UTXO in any case ..
However, we might have different interpretations of front running .. but how does that prevent front running by the order processing entity? They can choose to process their own orders first!?

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho
From http://mercuryex.com/
When making trades, your wallet will use the Mercury Order Book service to find bid or ask offers opened by other traders. This service is centralized, but it is never involved in the actual transfer of funds so it doesn't require any trust.

What are the flaws, if any in this approach?   Is this a way to make trustless transfers from bitbtc to btc?

We can also have trustless (well actually you need to trust a majority of the delegates to act as oracles) transfers from bitbtc to btc and vice versa and while keeping the order book on the blockchain as well rather than a centralized service. Check out theoretical's proposal and my tweak on it.

Also, the problem I see with the approach Mercury takes is that there is no way to prevent abuse. I assume that there is some nLockTime transaction in the atomic swap protocol to return the funds back after some amount of time, otherwise evil actors could make honest traders burn their money (or better yet extort them for some portion of the money by offering some fraction back). So with the necessary refund transaction in place as part of the protocol, the attackers could only lock the money of the other trader for some amount of time, but the key is that they can do this at no cost to the attacker. The system seems to be designed under the assumption that all actors will be honest. And even under that assumption it still has an additional flaw that it is trading assets that do not have values pegged to one another. This means even if the honest actor does not wish to hurt the other party for the sake of it, they may find that by the time they are going to claim the other coin by revealing the secret, the price could have significantly changed to their disadvantage. In that case, it would be rational to wait for the refund and buy at the new better price. The system described by the links above not only locks the trader in to carry out the exchange in a reasonable amount of time after the bids/asks are matched (or else the bidder loses their bond worth 10% of the value being traded), but there is also no serious volatility issue since the trading would occur between the Cryptocoin and the BitCryptocoin pairs only.
https://bitcointalk.org/index.php?topic=946174.msg10717582#msg10717582

Offline xiahui135

  • Sr. Member
  • ****
  • Posts: 496
    • View Profile
It is a little late to be a decentralized exchange. I hope bitasset is not late to success.


Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho
From http://mercuryex.com/
When making trades, your wallet will use the Mercury Order Book service to find bid or ask offers opened by other traders. This service is centralized, but it is never involved in the actual transfer of funds so it doesn't require any trust.

What are the flaws, if any in this approach?   Is this a way to make trustless transfers from bitbtc to btc?
you can stall the order book processing by DDOS?
how about the simply fu** up the order matching?
who is preventing them to do front running?

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho
From http://mercuryex.com/
When making trades, your wallet will use the Mercury Order Book service to find bid or ask offers opened by other traders. This service is centralized, but it is never involved in the actual transfer of funds so it doesn't require any trust.

What are the flaws, if any in this approach?   Is this a way to make trustless transfers from bitbtc to btc?

We can also have trustless (well actually you need to trust a majority of the delegates to act as oracles) transfers from bitbtc to btc and vice versa and while keeping the order book on the blockchain as well rather than a centralized service. Check out theoretical's proposal and my tweak on it.

Also, the problem I see with the approach Mercury takes is that there is no way to prevent abuse. I assume that there is some nLockTime transaction in the atomic swap protocol to return the funds back after some amount of time, otherwise evil actors could make honest traders burn their money (or better yet extort them for some portion of the money by offering some fraction back). So with the necessary refund transaction in place as part of the protocol, the attackers could only lock the money of the other trader for some amount of time, but the key is that they can do this at no cost to the attacker. The system seems to be designed under the assumption that all actors will be honest. And even under that assumption it still has an additional flaw that it is trading assets that do not have values pegged to one another. This means even if the honest actor does not wish to hurt the other party for the sake of it, they may find that by the time they are going to claim the other coin by revealing the secret, the price could have significantly changed to their disadvantage. In that case, it would be rational to wait for the refund and buy at the new better price. The system described by the links above not only locks the trader in to carry out the exchange in a reasonable amount of time after the bids/asks are matched (or else the bidder loses their bond worth 10% of the value being traded), but there is also no serious volatility issue since the trading would occur between the Cryptocoin and the BitCryptocoin pairs only.
« Last Edit: March 06, 2015, 08:01:04 am by arhag »

Offline bitmarket

  • Sr. Member
  • ****
  • Posts: 369
    • View Profile
    • BitShares TV
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho
From http://mercuryex.com/
When making trades, your wallet will use the Mercury Order Book service to find bid or ask offers opened by other traders. This service is centralized, but it is never involved in the actual transfer of funds so it doesn't require any trust.

What are the flaws, if any in this approach?   Is this a way to make trustless transfers from bitbtc to btc?
Host of BitShares.TV and Author of BitShares 101

Offline bitmarket

  • Sr. Member
  • ****
  • Posts: 369
    • View Profile
    • BitShares TV
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho
From http://mercuryex.com/
When making trades, your wallet will use the Mercury Order Book service to find bid or ask offers opened by other traders. This service is centralized, but it is never involved in the actual transfer of funds so it doesn't require any trust.
Host of BitShares.TV and Author of BitShares 101

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho

Offline speedy

  • Hero Member
  • *****
  • Posts: 1160
    • View Profile
  • BitShares: speedy

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 749
    • View Profile

Offline fundomatic

  • Full Member
  • ***
  • Posts: 149
    • View Profile

http://www.coinbuzz.com/2015/03/04/cant-touch-mercury-exchange/
Quote
Using the Cross-Chain Atomic Swap protocol, ...

Interesting.

[qoute]
At present, Mercury v0.1, an alpha version, supports:
Bitcoin
Litecoin
Dogecoin
[/quote]

Is it fun to trade just these three? I might try.

Quote
Plans to add other currencies and cryptographic assets are being considered, such as:

Ethereum
Colored coins (USD, company stock, etc.)
Sidechains
Nubits
Filecoin

Sad BitShares didn't make the list.