The current version of Mercury (0.0.1) is now ready for testing, you can download it here: https://github.com/mappum/mercury/releases/tag/0.0.1-alpha
Remember, this is alpha software and is likely to have bugs. Feel free to test it out with a small amount of money, but it's not ready to handle large sums of money.
If you encounter bugs or have any comments, please let me know and I'll address them as fast as I can. Thanks to everyone for being interested in Mercury!
Topic: Mercury - Fully trustless cryptocurrency exchange - Looking for testers! - page 8. (Read 35120 times)
February 21, 2015, 08:30:00 PM
February 21, 2015, 10:29:27 AM
Great project ， Come on : )
February 20, 2015, 07:32:31 PM
In case anyone is watching this project, I still plan on releasing the alpha version of Mercury today. I've been working all week to get it ready, and it's almost there. However, it should only be used for testing purposes, don't trust it with all your money until the system has been audited and we're sure it's safe.
I'll post a link to the download tonight.
I'll post a link to the download tonight.
February 17, 2015, 01:03:22 AM
Could a service for automatic portfolio rebalancing be developed out of this?
Just posted this in the ethereum forum: http://forum.ethereum.org/discussion/1844/automatic-portfolio-rebalancing/p1
Best / Tim
Just posted this in the ethereum forum: http://forum.ethereum.org/discussion/1844/automatic-portfolio-rebalancing/p1
Quote
Would it not be nice to have a etherium service that could automatically rebalance a portfolio with a number of cryptocurrencies? With rebalancing i mean that when there is a change of the value of one of the currencies, it is bought or sold so as to keep the ratio between the currencies in the portfolio constant.
Do you know of such a service?
Do you know of such a service?
Best / Tim
Sure, that sort of thing would work great with Mercury. But not quite yet, I'll have to develop the REST API before applications can start being built on it.
February 17, 2015, 12:37:29 AM
Could a service for automatic portfolio rebalancing be developed out of this?
Just posted this in the ethereum forum: http://forum.ethereum.org/discussion/1844/automatic-portfolio-rebalancing/p1
Best / Tim
Just posted this in the ethereum forum: http://forum.ethereum.org/discussion/1844/automatic-portfolio-rebalancing/p1
Quote
Would it not be nice to have a etherium service that could automatically rebalance a portfolio with a number of cryptocurrencies? With rebalancing i mean that when there is a change of the value of one of the currencies, it is bought or sold so as to keep the ratio between the currencies in the portfolio constant.
Do you know of such a service?
Do you know of such a service?
Best / Tim
February 16, 2015, 08:15:17 PM
@mappum awesome project!
Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.
Thanks for considering.
Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.
Thanks for considering.
I'm definitely planning to implement colored coins in Mercury. I expect a lot of interesting colored coin cryptoassets becoming available in the near future, and it would be cool to have Mercury be the most popular exchange for them as they start getting adopted.
Any ideas about which colored coin implementations are best? I'm hearing a lot about Open Assets, but I have a lot of faith in the Chromawallet team.
February 15, 2015, 07:27:08 PM
@mappum awesome project!
Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.
Thanks for considering.
Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.
Thanks for considering.
Agreed, colored coins are bitcoin2.0 on bitcoin1.0, their potential is amazing
February 15, 2015, 07:16:17 PM
With several exchanges hacked in the last 24 hours, this is looking more relevant than ever...
February 15, 2015, 11:20:14 AM
This looks great!
February 15, 2015, 02:35:35 PM
@mappum awesome project!
Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.
Thanks for considering.
Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.
Thanks for considering.
February 10, 2015, 10:47:29 AM
sooo cooolll.....I will surely download it right now 
February 10, 2015, 09:16:55 AM
Will watch this project.
February 10, 2015, 06:01:52 AM
If Mercury succeeded , it would be the killer APP of whole crypto industry .
I want to be a preAlpha-version tester
I want to be a preAlpha-version tester
I PMed you with the link.
February 09, 2015, 06:22:29 AM
If Mercury succeeded , it would be the killer APP of whole crypto industry .
I want to be a preAlpha-version tester
I want to be a preAlpha-version tester
February 08, 2015, 04:15:25 PM
The paper I read says "reducing malleability" not eliminate. When both parties are communicating p2p, they are holding on to the raws. With that raw tx malleability is so much easier, they dont need to be a miner to intercept it, they have it right there. Regardless, its a good idea to position yourself for AT because eventually all the coins should improve their own protocols. I'm happy to notice that Blackcoin just added checklocktimeverify preparing for v3.
"Raw" transactions aren't a part of the protocol, only part of the bitcoind API. I assume you mean that the protocol involves parties sending incomplete transactions to each other? In my implementation, the deposit transaction (the one that would get mutated) is never send between the parties, only its hash.
Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.
Actually, OP_CHECKLOCKTIMEVERIFY could be added in a soft fork.
Yeah and the party has a raw tx, which they have the power to change by slightly altering the sig.
February 08, 2015, 04:50:46 AM
The paper I read says "reducing malleability" not eliminate. When both parties are communicating p2p, they are holding on to the raws. With that raw tx malleability is so much easier, they dont need to be a miner to intercept it, they have it right there. Regardless, its a good idea to position yourself for AT because eventually all the coins should improve their own protocols. I'm happy to notice that Blackcoin just added checklocktimeverify preparing for v3.
"Raw" transactions aren't a part of the protocol, only part of the bitcoind API. I assume you mean that the protocol involves parties sending incomplete transactions to each other? In my implementation, the deposit transaction (the one that would get mutated) is never send between the parties, only its hash.
Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.
Actually, OP_CHECKLOCKTIMEVERIFY could be added in a soft fork.
February 08, 2015, 01:32:15 AM
I'm reading bip 66 now. +1 for removing OpenSSL. Its such a pain in the butt and there is no reason open source high security software should be trusting it. Also, I do a lot of work in Bitmessage and really would love to implement an alternative. The paper I read says "reducing malleability" not eliminate. When both parties are communicating p2p, they are holding on to the raws. With that raw tx malleability is so much easier, they dont need to be a miner to intercept it, they have it right there. Regardless, its a good idea to position yourself for AT because eventually all the coins should improve their own protocols. I'm happy to notice that Blackcoin just added checklocktimeverify preparing for v3.
Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.
Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.
February 08, 2015, 01:22:01 AM
Ok the new bitcoin core will not solve the problem. Even a 1% chance of malleability will end up becoming 100% with a dedicated scammer. For example, your program works with raw transactions. So I only need to hold on to the raw, change it a little bit and send it to as many pools and nodes as possible. If they mine my fake TX, then your TX will be considered bad and declined. Both parties work with raw transactions, thats the problem. So I can hold a bad copy and interfere.
"Sending the TX to as many pools and nodes as possible" is the part made difficult by newer versions of Bitcoin Core, nodes will now reject transactions that use e.g. non-standard signature encodings. The only way to get it in a block would be for a miner to be on a old version of Bitcoin Core, or for the attacker to mine the transaction themselves (which is expensive).
By the way, congrats so far. Its nice to see more people out there writing software and you are very familiar with scripting which is awesome. Anyways, you think that the new Bitcoin Core will not have any malleability at all? If I possess the new Bitcoin Core, and I have on me a raw transaction you are saying there is no way I can alter a single byte to change the txid? Anyways do you have any good links on that. I'm not so sure about this. If I've got the raw tx, it shouldn't be hard.
February 07, 2015, 11:05:41 PM
If A has to do that before B puts up any money, then doesn't that give B a chance to blackmail him?
That is, instead of proceeding with the transaction, B says, "Your coins are now inaccessible without my co-operation. You can get half back and give half to me, or get none back. Your choice."
That is, instead of proceeding with the transaction, B says, "Your coins are now inaccessible without my co-operation. You can get half back and give half to me, or get none back. Your choice."
No, it could be done trustlessly with SIGHASH_ANYONECANPAY. The deposit TX wouldn't be valid until both parties put in their inputs and sign it (they are both paying in the same TX). I'm not yet 100% convinced that scheme can work, and it's an inconvenience to users since they have to have collateral to be able to trade, but intuitively it seems like it could help.
February 07, 2015, 07:41:54 PM
Additionally, a way to solve the malleability attack is to require party A to deposit some coins into party B's initial multisig deposit. If A mutates the transaction, they are also tying up their own funds in the process. This solution is already possible today, I may implement it in the Mercury alpha.
If A has to do that before B puts up any money, then doesn't that give B a chance to blackmail him?
That is, instead of proceeding with the transaction, B says, "Your coins are now inaccessible without my co-operation. You can get half back and give half to me, or get none back. Your choice."
Re: malleability, I think there are still a few parts of BIP62 that aren't implemented yet and there might be sources of malleability still undiscovered. It'll take time to become confident, but it'll happen eventually.
Jump to: