Mercury - Fully trustless cryptocurrency exchange - Looking for testers!

[bhokor]

Wow really nice project some ETA for beta release?

[1714950489]

1714950489

[1714950489]

1714950489

[1714950489]

1714950489

[1714950489]

1714950489

[1714950489]

1714950489

[tobeaj2mer01]

If there is BTC/Fiat, it will be better, I will try it after it launches.

[GingerAle]

If there is BTC/Fiat, it will be better, I will try it after it launches.

now how would u do decentralized crypto -> fiat?

[mappum]

If there is BTC/Fiat, it will be better, I will try it after it launches.

now how would u do decentralized crypto -> fiat?

That would be possible with assets issued on the blockchain by a gateway service, for example if a bank takes USD deposits and sends you USD colored coins in return. You can then trade those USD coins just as you would any other coin on the blockchain, safely and transparently.

Of course, this means trusting the service to honor the colored coins and not to default if you want to redeem them for "real" USD. However, this is still much safer than other centralized financial institutions since the accounting is all done publicly on the blockchain, and everyone can tell if the service is ripping you off or not. And there could be a diversity of gateway providers to use, for instance commercial banks or even the Federal Reserve.

There is no way to get away from some amount of centralized trust when using fiat, we can't magically turn it into a cryptocurrency. However, USD-backed assets on the blockchain is the closest we can get.

[Nicolai Larsen]

Am I the only one who can't get the .jar file to work in Linux (Linux Mint)?

[CoinAwesome]

Am I the only one who can't get the .jar file to work in Linux (Linux Mint)?

Same here.

Code:

 $ java -jar MercuryWallet-0.0.2.jar 
Exception in thread "main" java.lang.NoClassDefFoundError: javafx/application/Application
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
Caused by: java.lang.ClassNotFoundException: javafx.application.Application
	at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
	... 13 more

Any idea?

[noel57]

The heading of your thread is quite repelling FULLY TRUSTLESS, how can I now test this with my coins since you have concluded that is fully trusted , I should not be surprised if my btc, ltc and doge just disappear after I make the deposit .

[Hueristic]

So, why not add BTC Testnet? I'm sure they will give you all the help you need without having to risk actually coins.

[Uptrenda]

Mappum I noticed you were forced to add a third-party signing key to your contract scheme because of TX malleability (which introduces liability / security risk.) This is actually a problem we've been working on solving using a timechain - a new data-structure based on time-lock encryption. By using a timechain you could time-lock a chain of ECDSA private keys that could be released automatically to allow your customers to be able to claim refunds if a contract isn't completed after a certain time-frame. The advantage of this scheme is that nobody would have to be trusted to hold private keys or release them which means that Mercury could come out of alpha and be used with real money right now.

Of course - as the saying goes: now you have two problems. There is currently no viable implementation of the timechain and to build one you would need access to a small GPU cluster. But I think if someone was serious about security and doing this: it would allow you to avoid the TX malleability problem entirely and release a viable product that couldn't be hacked at all - which is huge.

We've been experimenting with doing something like this ourselves but a prototype that can be used with real money is still a long way off. I thought I'd at least give you a heads up with this since it can benefit you more than us at this point.

Link to the paper: http://roberts.pm/timechain
tl; dr, you can improve security for a range of purposes by stitching together a time-lock encrypted chain of RSA keys with AES whose decryption is incentivised with fees from cryptocurrencies and rewards from its own blockchain.

[GingerAle]

Mappum I noticed you were forced to add a third-party signing key to your contract scheme because of TX malleability (which introduces liability / security risk.) This is actually a problem we've been working on solving using a timechain - a new data-structure based on time-lock encryption. By using a timechain you could time-lock a chain of ECDSA private keys that could be released automatically to allow your customers to be able to claim refunds if a contract isn't completed after a certain time-frame. The advantage of this scheme is that nobody would have to be trusted to hold private keys or release them which means that Mercury could come out of alpha and be used with real money right now.

Of course - as the saying goes: now you have two problems. There is currently no viable implementation of the timechain and to build one you would need access to a small GPU cluster. But I think if someone was serious about security and doing this: it would allow you to avoid the TX malleability problem entirely and release a viable product that couldn't be hacked at all - which is huge.

We've been experimenting with doing something like this ourselves but a prototype that can be used with real money is still a long way off. I thought I'd at least give you a heads up with this since it can benefit you more than us at this point.

Link to the paper: http://roberts.pm/timechain
tl; dr, you can improve security for a range of purposes by stitching together a time-lock encrypted chain of RSA keys with AES whose decryption is incentivised with fees from cryptocurrencies and rewards from its own blockchain.

uh, this is cryptocurrency world. Everyone has a small GPU cluster (well, old school miners)

or these guys

http://www.nimbix.net/

[Pab]

Another interesting take on the peer to peer exchange model:

http://veritaseum.com/

Thanks looks great for me,i hope my dev will like that also,if yes i will let you know

[CryptInvest]

Is the project is closed? Does anyone interesting concept?I enjoyed customers and noticed one significant problem - the high commission for the transaction. On centralized exchange is much cheaper.

[BCExchange]

I enjoyed customers and noticed one significant problem - the high commission for the transaction. On centralized exchange is much cheaper.

Decentralized exchanges like Mercury and B&C Exchange could be more expensive on a per-transaction basis (or at least initially), but it is balanced out by the significantly reduced risk of theft. The cheapness of transactions at Mt. Gox would have made their platform attractive, but less so when you consider that many users eventually suffered total losses of their funds.

We predict that decentralized exchanges will have an immediate user base for high-value trades, and that lesser-value trades will gain in popularity as the technology develops and scales.

[CryptInvest]

I enjoyed customers and noticed one significant problem - the high commission for the transaction. On centralized exchange is much cheaper.

Decentralized exchanges like Mercury and B&C Exchange could be more expensive on a per-transaction basis (or at least initially), but it is balanced out by the significantly reduced risk of theft. The cheapness of transactions at Mt. Gox would have made their platform attractive, but less so when you consider that many users eventually suffered total losses of their funds.

We predict that decentralized exchanges will have an immediate user base for high-value trades, and that lesser-value trades will gain in popularity as the technology develops and scales.

The price of transactions for the majority of regular traders is the most important value.

If you do not have the mass of traders, there is no liquidity and decentralized exchange will be very inefficient.

[sigma2543]

Is there a new ANN for Hg?

[labuan]

https://bittrex.com/Market/Index?MarketName=BTC-MER
congrats

[cnidari]

https://bittrex.com/Market/Index?MarketName=BTC-MER
congrats

Not the same project

[marcelocoin]

someone has price estimate, I believe that 0.0002 would be the minimum to achieve. success

[crabby]

Yes, I would strongly suggest against trying this exchange before every currency on the exchange has the appropriate security features. There is a 100% chance you will lose your coins if you use this exchange in the current state.

[MihailJ]

Darcrus and Mercury use cases, both tokens to stay on Waves



Hello loyal Darcrus, Mercury and Sigwo community. For the past month we’ve been busy gathering feedback, testing, brainstorming, developing and communicating with our team, and others, to determine the best direction to take our project as a whole.

As some of you may know, we decided to carefully examine the pros and cons of our current project needs to determine how we would continue our efforts.

Last week the Waves Platform team released a proposal to keep the feature of paying transaction fees with assets instead of Waves itself. That shed a new light on the situation we currently faced as with this proposal, asset fees are 100% guaranteed.

We discussed this further within the team and in our eyes the best solution would be to stay on Waves and instead of merging the two tokens together, keep them separated, so that no swaps are needed.

This proposed solution by Waves allows us to keep Mercury with its use cases on Waves and use Darcrus as the token needed for developers to use Gravity.

With this new use case for Darcrus, anyone wanting to develop on the Gravity platform will need to acquire $DAR from the open market to pay for access. This will allow for more liquidity in the DAR/WAVES and DAR/BTC markets on the Waves DEX.

We’re pleased with the outcome and thankful for the communities response, creativity and collaboration.

More detailed information about this can be found in the Q&A video and for those that prefer text over video, scroll down for the full transcript.

https://blog.darcr.us/darcrus-and-mercury-use-cases-both-tokens-to-stay-on-waves-826d2cd77607