Mercury - Fully trustless cryptocurrency exchange - Looking for testers!

[mappum]

The world's first trustless cryptocurrency exchange

Download
An early alpha preview is available for download. We're looking for testers, download it and try it out!

• Windows (.exe)
• OSX (.dmg)
• Linux (.jar)

Source Code: https://github.com/mappum/mercury

Website: http://mercuryex.com

Twitter: @MercuryExchange



Introducing Mercury

Mercury is a desktop wallet that eliminates the need for centralized exchanges. Currencies can be traded peer-to-peer, directly from the wallets of the traders.

Mercury Wallet implements the Cross-Chain Atomic Swap protocol, allowing users to buy and sell different cryptocurrencies, without any third-parties holding their funds. Trades happen on the blockchain(s), not in some exchange's database.

I've been working on Mercury for the past few months, and it is ready for an early alpha release.




What can I trade on Mercury?

Mercury v0.1 currently supports:

• Bitcoin
• Litecoin
• Dogecoin

Many more currencies and crypto-assets will be added in the future if they are in high demand by Mercury users. Rather than supporting all altcoins, I strongly believe in only supporting cryptocurrencies that provide real value, especially innovative "Bitcoin 2.0" technologies. Any crypto-asset can be tradable on Mercury, as long as it at least supports transaction scripts like Bitcoin's.

Some possible assets to be added:

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

[jwinterm]

Do you plan to release source, or windows binary only?

Do you need to have a running core/qt wallet open to make a transaction using this app/service? So, would you need to have running synced bitcoin, litecoin, and dogecoin qt/core wallets synced and running to make trades?

[mappum]

Do you plan to release source, or windows binary only?

Do you need to have a running core/qt wallet open to make a transaction using this app/service? So, would you need to have running synced bitcoin, litecoin, and dogecoin qt/core wallets synced and running to make trades?

Yes, the source is on Github, I'll make it public right now. I didn't post it at first because it's not really ready to support a huge amount of users, but I understand that it's important for people to be able to trust the software.

The wallet runs light (SPV) clients for each currency, so no other wallets are neccessary. The first time you run the wallet, it will take only a few minutes to sync the blockchains, then you can start sending/receiving money or trading via the peer-to-peer networks for each coin.

[mappum]

Thanks for the feedback, I open-sourced the code!

[jwinterm]

Do you plan to release source, or windows binary only?

Do you need to have a running core/qt wallet open to make a transaction using this app/service? So, would you need to have running synced bitcoin, litecoin, and dogecoin qt/core wallets synced and running to make trades?

Yes, the source is on Github, I'll make it public right now. I didn't post it at first because it's not really ready to support a huge amount of users, but I understand that it's important for people to be able to trust the software.

The wallet runs light (SPV) clients for each currency, so no other wallets are neccessary. The first time you run the wallet, it will take only a few minutes to sync the blockchains, then you can start sending/receiving money or trading via the peer-to-peer networks for each coin.

Thanks! Sounds very interesting. Put thread on watch mode, hope to see some more updates soon...

[TwinWinNerD]

This looks awesome. Once you are out of Beta, I will sure use it!

[bassguitarman]

i'll test

[ncsupanda]

i'll test

Seconded.

[fatbitcoinfan]

This looks great!

A decentralized exchange is tantalizingly close.

At first glance, it looks like it's vulnerable to transaction malleability, though. Do you have a way to defend against the following attack?

In this context:

B creates TX3: "Pay v alt-coins to <A-public-key> if (x for H(x) known and signed by A) or (signed by A & B)"
 
B creates TX4: "Pay v alt-coins from TX3 to <B's public key>, locked 24 hours in the future, signed by B"
 
B sends TX4 to A
 
A signs TX4 and sends back to B
 
 2) B submits TX3 to the network

A broadcasts an equally valid TX3' with a different hash, which eventually gets into the blockchain instead of TX3. (A has deliberately made connections to many more nodes than B, so A will receive TX3 quickly and can then send TX3' to many nodes in one hop.)

Now TX4 is useless. A waits until his timelock expires and gets his coins back. B's coins are stuck.

A watches the Mercury community's public discussions to see if anybody complains that their coins are stuck.

If so, A creates TX5: "Pay 0.5*v alt-coins from TX3' to A and 0.5*v alt-coins to B", signs it, and sends B a private message saying,
"Hello B,

I'm scamming you. You can sign TX5 and get half of your coins back. Or not. It's up to you.

Don't bother replying. I won't read it.

Your friendly scammer,
A"

[swapcoiner]

I wish you to carry forward your development, being trustless lot of core, hack possibilities there. Too far to go to have an secured working exchanger. Will see if I can test it.

[Fargo]

How long till launch?

[mappum]

At first glance, it looks like it's vulnerable to transaction malleability, though. Do you have a way to defend against the following attack?

That's a reasonable concern. It will be completely solved once OP_CHECKLOCKTIMEVERIFY is implemented in Bitcoin Core (refunds can then come from a timelocked output, instead of a pre-signed timelocked refund transaction). Until then, changes in Bitcoin Core 0.9 have made mutating transactions expensive enough that this should not be a huge issue (the attacker would need to mine the mutated transaction in a block). The alpha version of Mercury only allows trading with the Bitcoin Testnet, and before I open it up to real trading I'll have to be sure this attack is not viable.

[duplan]

Please add the very innovative BURST to your Project , it's JAVA based so that should make it easier …

Burst community and Devs are very active and helpful , too .

All the Best !

BURST Source Code https://github.com/BurstProject/burstcoin

[doof]

I vote for coloured coins as next feature

[bitwarrior]

Mercury exchange looks promising, hopefully will be able to use it when it formally launch. Wanting to see more coins get listed on it.
Thanks.

[tf2honeybadger]

I'm interested in testing as well.

[mappum]

How long till launch?

I'll release the alpha within the next 2 weeks, stay tuned!

[dzimbeck]

Yeah this is a good attempt but it doesnt work!

Transaction malleability will destroy any trade. ONLY coins with checklocktimeverify can do AT. I also think Qora has it. If you try AT without it, you are going to run into Malleability and one partly will lose all their Bitcoins.

Also, SPV clients rely on a server correct?!? Then its not trustless because the servers data could be interfered with to say a tx has confirmed when it hasnt causing you to submit your TX and give the attacker coins. I might be misunderstanding SPV but from what I'm reading it communicates with servers and thus their data can be spoofed and it requires a lot of trust.

I would recommend manually rewriting the clients and pruning the blockchain instead of SPV. And then you can only wait for a Malleability patch or Checklocktimeverify.

[dzimbeck]

Although I see your response and P2SH is maybe only slightly more expensive to change TXID, I used to quote articles on that. However, I believe its a lot easier than you realize to change the txids. You dont need to mine the block, only get access to the mempool and inject your changed TX to other pools in the hopes they get mined. I really would not risk users funds like this. If it happens even once, they lose all their coins.

[duplan]

Yeah this is a good attempt but it doesnt work!

Transaction malleability will destroy any trade. ONLY coins with checklocktimeverify can do AT. I also think Qora has it. If you try AT without it, you are going to run into Malleability and one partly will lose all their Bitcoins.

Also, SPV clients rely on a server correct?!? Then its not trustless because the servers data could be interfered with to say a tx has confirmed when it hasnt causing you to submit your TX and give the attacker coins. I might be misunderstanding SPV but from what I'm reading it communicates with servers and thus their data can be spoofed and it requires a lot of trust.

I would recommend manually rewriting the clients and pruning the blockchain instead of SPV. And then you can only wait for a Malleability patch or Checklocktimeverify.

BURST has successfully implemented AT , proof is here : http://ciyam.org/at/

All else can be mostly read on its bitcointalk thread https://bitcointalk.org/index.php?topic=731923.0

Here is also a little article , read also the comments , it seems Vitalik tries to talk it down out of envy … https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/