Mercury - Fully trustless cryptocurrency exchange - Looking for testers! - page 4.

mappum

member

Activity: 82

Merit: 13

Quote from: slothbag on March 25, 2015, 07:27:03 PM

Great

So if we had a non Bitcoin based coin like Nxt, Ripple or BitShares, and they implemented some sort of PayOnSecretReveal & SecretReveal API would that be pretty straight forward to implement into Mecury?

It's slightly more complicated than that in order to allow the deposits to be redeemed by the refund transactions, but that sort of API would be most of what is required. I don't know a lot about how these currencies differ from Bitcoin, do they still have the same input/output system, with scripting?

slothbag

sr. member

Activity: 369

Merit: 250

Quote from: mappum on March 25, 2015, 06:54:24 PM

The currently implemented coin clients will already do this (they check for a node running on localhost, and if there is one they use it as a trusted peer). You're right, it might be a good idea to get Nubits to work like that, so that a SPV client doesn't have to get developed first.

Great

So if we had a non Bitcoin based coin like Nxt, Ripple or BitShares, and they implemented some sort of PayOnSecretReveal & SecretReveal API would that be pretty straight forward to implement into Mecury?

mappum

member

Activity: 82

Merit: 13

Quote from: slothbag on March 25, 2015, 06:12:10 PM

Hi mappum, do you plan to add support for interacting with coin daemons instead of relying on inbuilt SPV clients? This way people could host their own nubits daemon and mecury could just call its APIs? This seems to me a much more scalable solution.

The currently implemented coin clients will already do this (they check for a node running on localhost, and if there is one they use it as a trusted peer). You're right, it might be a good idea to get Nubits to work like that, so that a SPV client doesn't have to get developed first.

slothbag

sr. member

Activity: 369

Merit: 250

Hi mappum, do you plan to add support for interacting with coin daemons instead of relying on inbuilt SPV clients? This way people could host their own nubits daemon and mecury could just call its APIs? This seems to me a much more scalable solution.

mappum

member

Activity: 82

Merit: 13

Quote from: ?? on ??

Good news on that front - our source code audit is nearly complete, meaning we will be open-source in the very near future. We'll post here as soon as you can access the code.

In the meantime, we have our Documentation available here: http://docs.nubits.com/, and our NuBitsj library here: https://github.com/Cybnate/NuBitsj

Shoot us a message if we can be of help! info at nubits dot com.

I'm a little worried about NubitsJ. Since Nubits uses PoS, the blockchain can't be safely verified by an SPV client. It seems that NubitsJ tries to solve that by trusting a centralized server for blockchain download, which is very insecure (full trust is being placed in that server).

If a more secure model can be worked out, I will work on adding Nubits. This might involve a client with a little more overhead than SPV (e.g. a pruned full-node).

mappum

member

Activity: 82

Merit: 13

Quote from: ?? on ??

nice it looks like good work., any chance we see Monero on it?

Sure, Monero is a good candidate since it has a good amount of trade volume. I'll try to get it in the next release or two.

wdnj

hero member

Activity: 762

Merit: 500

Awesome project,good work Cheesy

TwinWinNerD

legendary

Activity: 1680

Merit: 1001

CEO Bitpanda.com

Is NXT on your radar too?

mappum

member

Activity: 82

Merit: 13

Quote from: tuaris on March 19, 2015, 09:31:49 PM

This look interesting and it's in Java Grin

The code seems well written and easy to follow. I'll study see if I can contribute to it in anyway. Perhaps I'll start by adding in a new coin.

Thank you for making it open source.

Awesome

If you add a new coin, look at my fork of Bitcoinj: https://github.com/mappum/altcoinj
Each coin has a NetworkParameters class in the params package.

Just letting you know, I'd prefer coins to be ones that have significant volume, I don't want to just add every boring altcoin. Some important ones that need to be added are Nubits and Ethereum (but those are a little more complicated).

tuaris

hero member

Activity: 780

Merit: 501

This look interesting and it's in Java Grin

The code seems well written and easy to follow. I'll study see if I can contribute to it in anyway. Perhaps I'll start by adding in a new coin.

Thank you for making it open source.

mappum

member

Activity: 82

Merit: 13

Quote from: CryptInvest on March 19, 2015, 09:57:43 AM

Hi! Please, support my order! Sell me some DOGE!

Looks like someone made the trade

mappum

member

Activity: 82

Merit: 13

Quote from: dzimbeck on March 19, 2015, 09:24:07 AM

Hey I just wanted to make a suggestion. I know we talked earlier about AT and malleability and it was concluded it still is a problem until the update of checklocktimeverify.

However, I think I have a really good idea that may help you fully avoid malleability. In BitHalo, we use "instant refund" for preventing a malleable transaction. If you have a refund based on the TXID of the transaction in question to a multisignature account controlled by both parties then you can do AT! The amount must only slightly exceed the amount being traded. Hell, even a small refund would be a deterrent if it exceeded the probability of a successful attack.

Thus if a party deliberately changes the TXID before broadcast then he loses the refund. This can help you until checklocktimeverify is added and can make 100% sure your exchange is trustless.

This way we know that p2sh is indeed more resilient. Because we should try and attack the mercury exchange to test its resilliance to these attacks. If you want, i can give you a p2sh malleability script in python.

Please read my whitepaper on instant refunds and let me know what you think. If you have a question for me please PM me since i dont always check bitcointalk. The whitepaper is here... www.bithalo.org

Best,
David

Right, I mentioned that solution here before:

Quote from: mappum on February 06, 2015, 08:06:16 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.

But it turns out to not be very viable from a UX standpoint, since traders have to already have a significant balance of the coin they want to buy (so they would have to buy it on another exchange), and they could then not trade their entire balance. It's still an option if necessary, but I'd actually rather lobby for OP_CHECKLOCKTIMEVERIFY to be added to coins since it only requires a soft fork and it is also necessary for micropayment channels and some escrow protocols.

CryptInvest

legendary

Activity: 2156

Merit: 1132

Hi! Please, support my order! Sell me some DOGE!

dzimbeck

legendary

Activity: 2412

Merit: 1044

Hey I just wanted to make a suggestion. I know we talked earlier about AT and malleability and it was concluded it still is a problem until the update of checklocktimeverify.

However, I think I have a really good idea that may help you fully avoid malleability. In BitHalo, we use "instant refund" for preventing a malleable transaction. If you have a refund based on the TXID of the transaction in question to a multisignature account controlled by both parties then you can do AT! The amount must only slightly exceed the amount being traded. Hell, even a small refund would be a deterrent if it exceeded the probability of a successful attack.

Thus if a party deliberately changes the TXID before broadcast then he loses the refund. This can help you until checklocktimeverify is added and can make 100% sure your exchange is trustless.

This way we know that p2sh is indeed more resilient. Because we should try and attack the mercury exchange to test its resilliance to these attacks. If you want, i can give you a p2sh malleability script in python.

Please read my whitepaper on instant refunds and let me know what you think. If you have a question for me please PM me since i dont always check bitcointalk. The whitepaper is here... www.bithalo.org

Best,
David

blacklizard

full member

Activity: 139

Merit: 103

Quote

I don't know of any high-volume colored coin assets on the market right now

GetHashing's smart asset has a net worth of $100K since it's backed by physical hardware which will double in the next weeks when batch 2 of the hardware comes online. GH basically created the first decentralized and freely tangible mining shares and a fully transparent and also decentralized cloud wallet / mining platform with all user data (inc the entire wallet strings) being stored in the users browser in LocalData and the user SALT.

There is also a few good assets on the Coinprism directory but what's really missing is a Marketplace. I thought Mercury would be the perfect solution since both, atomic-swap trading and colored coins are just about to gain momentum. Perhaps a smaller and niche kind of market for open assets using Mercury would benefit both.

mappum

member

Activity: 82

Merit: 13

Quote from: blacklizard on March 17, 2015, 03:07:56 PM

@mappum how you getting on with adding support for colored coins? Are you going to use the open assets protocol?

I'm holding off until there are some real assets to trade (I don't know of any high-volume colored coin assets on the market right now). However, I expect some companies to start issuing colored coin-based assets very soon.

mappum

member

Activity: 82

Merit: 13

Quote from: GingerAle on March 17, 2015, 11:10:56 AM

because no one is holding your coins - the coins are just locked up in algorithmic contracts. Therefore, you never have to send your money to an exchange in order to exchange it. Your money essentially stays in your wallet until the contract is filled, and then the transaction is sent.

(did I get this right?)

Yep, that's correct

More details about the contract protocol are here: https://en.bitcoin.it/wiki/Atomic_cross-chain_trading

blacklizard

full member

Activity: 139

Merit: 103

@mappum how you getting on with adding support for colored coins? Are you going to use the open assets protocol?

olcaytu2005

legendary

Activity: 1470

Merit: 1024

Quote from: GingerAle on March 17, 2015, 11:10:56 AM

Quote from: olcaytu2005 on March 17, 2015, 11:08:17 AM

Quote from: mappum on March 17, 2015, 12:42:02 AM

Quote from: olcaytu2005 on March 15, 2015, 03:14:09 PM

what it mean trustless? unsafe?

Trustless means you don't have to trust anyone else, so your funds are as safe as possible. When using centralized exchanges, you are trusting the exchange operators with your money so they have the power to do what they want with your money. In a trustless exchange, only you ever hold your money.

thank you but how decentralized exchanges do achieve that?

because no one is holding your coins - the coins are just locked up in algorithmic contracts. Therefore, you never have to send your money to an exchange in order to exchange it. Your money essentially stays in your wallet until the contract is filled, and then the transaction is sent.

(did I get this right?)

Yes thank you i got it

GingerAle

legendary

Activity: 1260

Merit: 1008

Quote from: olcaytu2005 on March 17, 2015, 11:08:17 AM

Quote from: mappum on March 17, 2015, 12:42:02 AM

Quote from: olcaytu2005 on March 15, 2015, 03:14:09 PM

what it mean trustless? unsafe?

Trustless means you don't have to trust anyone else, so your funds are as safe as possible. When using centralized exchanges, you are trusting the exchange operators with your money so they have the power to do what they want with your money. In a trustless exchange, only you ever hold your money.

thank you but how decentralized exchanges do achieve that?

because no one is holding your coins - the coins are just locked up in algorithmic contracts. Therefore, you never have to send your money to an exchange in order to exchange it. Your money essentially stays in your wallet until the contract is filled, and then the transaction is sent.

(did I get this right?)

Topic: Mercury - Fully trustless cryptocurrency exchange - Looking for testers! - page 4. (Read 35176 times)