BitShares Forum
Main => General Discussion => Topic started by: bluebit on March 05, 2015, 04:34:17 pm
-
http://www.coinbuzz.com/2015/03/04/cant-touch-mercury-exchange/
Competition heating up, not looking good.
-
Let's get BitUSD on there.
-
Our products that actually make money are our BitAssets. If people don't use our decentralized exchange, but still use our BitAssets, we still win.
This should be a top priority... what current 100% delegate is up to this integration job?
-
yeah more decentraliced secured exchanges using torrent http://www.coinffeine.com/
using multisig www.multisigna.com
-
http://www.coinbuzz.com/2015/03/04/cant-touch-mercury-exchange/
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.
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.
-
Sad BitShares didn't make the list.
This is open source, we can add it!
-
http://www.coinbuzz.com/2015/03/04/cant-touch-mercury-exchange/
Competition heating up, not looking good.
What competition? Show me their orderbook!
-
AFAIK .. order book is processed on a CENTRALIZED server .. hence, no competition to BTS imho
-
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.
-
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?
-
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 (https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md) and my tweak (https://bitsharestalk.org/index.php?topic=14318.msg189679#msg189679) 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.
-
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?
-
I forwarded the critique: https://bitcointalk.org/index.php?topic=946174.msg10682854#msg10682854
-
It is a little late to be a decentralized exchange. I hope bitasset is not late to success.
-
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 (https://github.com/drltc/bitbond-proposal/blob/master/btc-trade.md) and my tweak (https://bitsharestalk.org/index.php?topic=14318.msg189679#msg189679) 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
-
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?
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!?
-
RIP BitShares. It was nice knowing you...
-
RIP BitShares. It was nice knowing you...
+5%
-
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?
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 ! ;)