Bitcoin Forum
February 20, 2019, 08:37:32 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 »  All
  Print  
Author Topic: Mercury - Fully trustless cryptocurrency exchange - Looking for testers!  (Read 34798 times)
mappum
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 25, 2015, 09:19:52 PM
 #121

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).
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550651852
Hero Member
*
Offline Offline

Posts: 1550651852

View Profile Personal Message (Offline)

Ignore
1550651852
Reply with quote  #2

1550651852
Report to moderator
1550651852
Hero Member
*
Offline Offline

Posts: 1550651852

View Profile Personal Message (Offline)

Ignore
1550651852
Reply with quote  #2

1550651852
Report to moderator
1550651852
Hero Member
*
Offline Offline

Posts: 1550651852

View Profile Personal Message (Offline)

Ignore
1550651852
Reply with quote  #2

1550651852
Report to moderator
slothbag
Sr. Member
****
Offline Offline

Activity: 369
Merit: 250



View Profile
March 25, 2015, 11:12:10 PM
 #122

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
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 25, 2015, 11:54:24 PM
 #123

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
****
Offline Offline

Activity: 369
Merit: 250



View Profile
March 26, 2015, 12:27:03 AM
 #124

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 Smiley

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
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 26, 2015, 02:31:51 AM
 #125

Great Smiley

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?
Uptrenda
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
March 26, 2015, 03:30:06 AM
Last edit: March 26, 2015, 04:04:00 AM by Uptrenda
 #126

Disclaimer: I am currently working on my own decentralized exchange although I've tried my best to make this feedback balanced and accurate.

First, let me say this is a great project. I like your user interface, your centralized order book is a nice simple idea, and you seem like a competent developer. However I can't help but think you're glossing over the security concerns by making too many assumptions. Keep in mind, I do understand this is a prototype but as it stands this design won't work for real money (at least not very well) and here is why:

1. Transaction malleability. If the transaction that the refunds depend on is mutated the refund will be invalidated, potentially locking any funds up within the contract and leaving the contract vulnerable to extortion attacks. You suggest this problem is too costly to perform but let me say: that might not be the case. A particular paper comes to mind (0) in which researchers were able to double-spend zero confirmation transactions on the Bitcoin network by having vastly more connectivity than the victim and using that connectivity to propagate the double spend TX before the legitimate TX arrives. The attack works by exploiting the properties of the mempool, as nodes will only accept the first version of a transaction for any group of inputs. Now in the context of your exchange, an attacker could simply mutate (3) the "bond" TX and propagate it to the rest of the network / the majority of miners before your original transaction arrives (1) ( 8 ). This attack would not be expensive to perform and could be done with a few hundred $5 a month VPS'. Additionally, the attacker could vastly optimise his chance of success by monitoring multiple points on the network, thereby ensuring the attacker sees transactions at the earliest possible time.

Even if the attacker only succeeds in mutating less than 5% of transactions and your exchange's transactions constitute less than 0.00001% of that TX volume - that could still translate to quite a large number of users effected (4) and OP_CHECKLOCKTIMEVERIFY won't save you here. You seem to be assuming that once Bitcoin Core merges the patch that all your problems will go away, but this relies on the assumption that alt-coins will actually merge Bitcoin Core's patches and stay up to date when generally they don't. There are still patches that were made to Bitcoin core in 2012 that have yet to be merged with Litecoin and I'm guessing it's the same story with other alt-coins too. Thus, alt-coins that aren't forked after the patches are likely to remain vulnerable to TX malleability for years - possibly indefinitely.

Of course, you could fix this whole nasty problem in a day by adding fail-safe keys to your scheme, that way if the money is locked you can still mediate ... but if you decide to do that, you then have to worry about the security of the keys and you couldn't claim that your scheme was entirely trustless if  full mediation was required.

2. Partial matching. From my understanding of your code there doesn't seem to be a mechanism for partial matching. In practice, this would mean that your users would have to wait for 8~  confirmations * confirm_time minutes (80 minutes for Bitcoin!) between every match (and large orders may require hundreds of them.) The problem comes from the fact that Bitcoin transactions are like hierarchical trees, that outputs must be spent in full, and that the distribution of amounts amongst outputs isn't guaranteed to be optimal for matching trades. Consequently, any given match - even for a small amount - could make 100% of the coins in your wallet unavailable until the contract was confirmed (which would make it incredibly painful to match trades.)

A proper exchange needs to support partial matching (5) to be able to efficiently match orders and I'd argue its even more important for "decentralized" exchanges as trades are already thousands of times slower than centralised exchanges because of the block chain.

3. Non-standard transactions. Since this is getting too long I'll just summarise this point: cross-chain contracts rely on non-standard transactions whose propagation is outright rejected on most alt-coins. The result is your contracts likely won't work on the main network and if  it does: confirmation time will take hours rather than minutes. This is a huge issue because you can't fix the lack of transaction support with any coding patch. It's an immovable object built directly into the parameters of the network and the only way around is to be able to influence the miners directly into accepting your non-standard transactions. You probably won't have this problem on the Bitcoin side because the IsStandard() rules were recently relaxed (2), but on alt-coin I can see you pulling your hair out (6) (7)
 
tl; dr, your design has major problems that you need to fix. These are all problems I've had to address in my design so if this criticism comes off as too vague I'm happy to elaborate.

(0) https://eprint.iacr.org/2012/248.pdf
(1) There have been reports of widespread transaction mutation on the main network. An attacker might already have the capabilities I've discussed.
(2) https://github.com/bitcoin/bitcoin/pull/4365/files
(3) I have a five line function in my repo - literally five lines, and it will mutate transactions on most alt-coins:
   
Quote
def mutate_tx(tx_hex):
    """
    Mutates a raw transaction using TX malleability in the scriptSig (specifically, the OP codes.) This function shouldn't be used beyond testing as it uses an ugly eval() hack.

    https://en.bitcoin.it/wiki/Transaction_Malleability
    """
    tx = CTransaction.deserialize(binascii.unhexlify(tx_hex))
    script_sig = repr(tx.vin[0].scriptSig)[9:]
    script_sig = eval("CScript([OP_1, OP_DROP, " + script_sig)
    tx.vin[0].scriptSig = script_sig
    return b2x(tx.serialize())
   
(4) I'd argue even 1 user effected would be bad since there's potentially no way to retrieve the money if  the other side discards the key.
(5) A simple solution is to sort the order book in descending order but that still doesn't guarantee optimal matching.
(6) Tier-Nolan came up with a solution to this that only requires non-standard transactions on one side of the trade. The details are available here: https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
(7) I really like cats.
( 8 ) The window of time for such attacks would be possible depending on how close the attacker was on the network to the broadcasting node. If we assume around 50 - 400ms latency between hops, then the arrival time for the initial transaction would still make a double-spend possible given the current network propagation delays: http://bitcoinstats.com/network/propagation/

And now I'm done editing.
mappum
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 26, 2015, 08:00:16 AM
 #127

Disclaimer: I am currently working on my own decentralized exchange although I've tried my best to make this feedback balanced and accurate.

First, let me say this is a great project. I like your user interface, your centralized order book is a nice simple idea, and you seem like a competent developer. However I can't help but think you're glossing over the security concerns by making too many assumptions. Keep in mind, I do understand this is a prototype but as it stands this design won't work for real money (at least not very well) and here is why:

1. Transaction malleability. If the transaction that the refunds depend on is mutated the refund will be invalidated, potentially locking any funds up within the contract and leaving the contract vulnerable to extortion attacks. You suggest this problem is too costly to perform but let me say: that might not be the case. A particular paper comes to mind (0) in which researchers were able to double-spend zero confirmation transactions on the Bitcoin network by having vastly more connectivity than the victim and using that connectivity to propagate the double spend TX before the legitimate TX arrives. The attack works by exploiting the properties of the mempool, as nodes will only accept the first version of a transaction for any group of inputs. Now in the context of your exchange, an attacker could simply mutate (3) the "bond" TX and propagate it to the rest of the network / the majority of miners before your original transaction arrives (1) ( 8 ). This attack would not be expensive to perform and could be done with a few hundred $5 a month VPS'. Additionally, the attacker could vastly optimise his chance of success by monitoring multiple points on the network, thereby ensuring the attacker sees transactions at the earliest possible time.

Even if the attacker only succeeds in mutating less than 5% of transactions and your exchange's transactions constitute less than 0.00001% of that TX volume - that could still translate to quite a large number of users effected (4) and OP_CHECKLOCKTIMEVERIFY won't save you here. You seem to be assuming that once Bitcoin Core merges the patch that all your problems will go away, but this relies on the assumption that alt-coins will actually merge Bitcoin Core's patches and stay up to date when generally they don't. There are still patches that were made to Bitcoin core in 2012 that have yet to be merged with Litecoin and I'm guessing it's the same story with other alt-coins too. Thus, alt-coins that aren't forked after the patches are likely to remain vulnerable to TX malleability for years - possibly indefinitely.

Of course, you could fix this whole nasty problem in a day by adding fail-safe keys to your scheme, that way if the money is locked you can still mediate ... but if you decide to do that, you then have to worry about the security of the keys and you couldn't claim that your scheme was entirely trustless if  full mediation was required.

2. Partial matching. From my understanding of your code there doesn't seem to be a mechanism for partial matching. In practice, this would mean that your users would have to wait for 8~  confirmations * confirm_time minutes (80 minutes for Bitcoin!) between every match (and large orders may require hundreds of them.) The problem comes from the fact that Bitcoin transactions are like hierarchical trees, that outputs must be spent in full, and that the distribution of amounts amongst outputs isn't guaranteed to be optimal for matching trades. Consequently, any given match - even for a small amount - could make 100% of the coins in your wallet unavailable until the contract was confirmed (which would make it incredibly painful to match trades.)

A proper exchange needs to support partial matching (5) to be able to efficiently match orders and I'd argue its even more important for "decentralized" exchanges as trades are already thousands of times slower than centralised exchanges because of the block chain.

3. Non-standard transactions. Since this is getting too long I'll just summarise this point: cross-chain contracts rely on non-standard transactions whose propagation is outright rejected on most alt-coins. The result is your contracts likely won't work on the main network and if  it does: confirmation time will take hours rather than minutes. This is a huge issue because you can't fix the lack of transaction support with any coding patch. It's an immovable object built directly into the parameters of the network and the only way around is to be able to influence the miners directly into accepting your non-standard transactions. You probably won't have this problem on the Bitcoin side because the IsStandard() rules were recently relaxed (2), but on alt-coin I can see you pulling your hair out (6) (7)
 
tl; dr, your design has major problems that you need to fix. These are all problems I've had to address in my design so if this criticism comes off as too vague I'm happy to elaborate.

(0) https://eprint.iacr.org/2012/248.pdf
(1) There have been reports of widespread transaction mutation on the main network. An attacker might already have the capabilities I've discussed.
(2) https://github.com/bitcoin/bitcoin/pull/4365/files
(3) I have a five line function in my repo - literally five lines, and it will mutate transactions on most alt-coins:
   
Quote
def mutate_tx(tx_hex):
    """
    Mutates a raw transaction using TX malleability in the scriptSig (specifically, the OP codes.) This function shouldn't be used beyond testing as it uses an ugly eval() hack.

    https://en.bitcoin.it/wiki/Transaction_Malleability
    """
    tx = CTransaction.deserialize(binascii.unhexlify(tx_hex))
    script_sig = repr(tx.vin[0].scriptSig)[9:]
    script_sig = eval("CScript([OP_1, OP_DROP, " + script_sig)
    tx.vin[0].scriptSig = script_sig
    return b2x(tx.serialize())
   
(4) I'd argue even 1 user effected would be bad since there's potentially no way to retrieve the money if  the other side discards the key.
(5) A simple solution is to sort the order book in descending order but that still doesn't guarantee optimal matching.
(6) Tier-Nolan came up with a solution to this that only requires non-standard transactions on one side of the trade. The details are available here: https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
(7) I really like cats.
( 8 ) The window of time for such attacks would be possible depending on how close the attacker was on the network to the broadcasting node. If we assume around 50 - 400ms latency between hops, then the arrival time for the initial transaction would still make a double-spend possible given the current network propagation delays: http://bitcoinstats.com/network/propagation/

And now I'm done editing.


Thanks, that's probably the best-written and most thoughtful feedback I have received yet.

1. Transaction malleability. I agree completely that malleability is a major concern and I am not satisfied with the attack only being costly to perform. However, it is at least a better situation than the experiments in the paper you linked since those researchers were in possession of the double-spend TX at the same time as the attack TX. In my case, the "deposit"/"bond" TX is not directly sent to the would-be attacker directly which makes it at least slightly more unlikely to get the transaction fast enough to perform the attack. Additionally, the Mercury trade server already helps out by being well-connected to miners and relaying the transactions (but this means traders are trusting the Mercury servers to not perform the malleability attack, which of course I am not planning on doing). These are only precautions for the time being, I don't plan on making a marketing effort for Mercury until the protocol is secure against malleability attacks.

Obviously OP_CHECKLOCKTIMEVERIFY is the real solution, and while it is a painful barrier that all coins will need to adopt it, I believe I can lobby coins to put in that patch (thankfully it only requires a soft fork, not a hard fork). Micropayment channels, cross-chain atomic swaps, and any other contract protocols that need to have refunds all rely on OP_CLTV so it has a good case for being merged in.

2. Partial matching. Interesting point, I had not thought of that. But I must be missing something, because I do not understand where your "8 confirmations" figure is coming from. Trades will be able to be made safely with far less than 8 confirmations (maybe even 0 for small-value trades), and outputs are not  tied up while contracts are confirming. As soon as the deposit transactions are spent, the change should be spendable (however, chaining too many unconfirmed transactions could cause problems). If I'm understanding your point correctly, it can be solved simply by breaking up outputs in the wallet into many smaller outputs (balanced at a good size that doesn't make transaction sizes prohibitively large).

3. Non-standard transactions. This is already a solved issue since I am using TierNolan's clever protocol that only requires one chain to support non-standard transactions. Bitcoin Core 0.10 relaxes the rules and has already been adopted by ~40% of the network, and empirically my non-standard transactions are getting confirmed into blocks in 20-30 minutes on average (and will get faster as more miners update over time).
vokain
Legendary
*
Offline Offline

Activity: 1736
Merit: 1000


View Profile
March 27, 2015, 02:31:42 AM
 #128

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.

I think the bigger deal is having a trustless protocol for people to exchange bitcoins for XMR (when seeking financial privacy) and XMR for BTC (to access more merchants).

         ▄█▄  ▄▄▄▄
          ▀ ▄██████▄
    ▄▄▄   ▄███▀▀███
  ▄█████▄ ▀█▀ ███▄ ▀▀
 ███▀  ▀██▄    ████▄   
 █▀ ▄██▄ ▀█▀ ▄██▀ ▀█▀ ▄██
  ▄██▀     ▄██▀     ▄██▀
 ██▀ ▄█▄ ▄██▀ ▄█▄  ██▀ ▄▄
      ▀███▀    ▀██▄  ▄██▀
     ▄▄ ▀██▄ ▄█▄ ▀█████▀
     ███▄▄██▀   ▀▀
      ▀██████▀
        ▀▀▀▀   ██▀

  █
  █
  █
████
  █
████
  █
████
  █
  █
  █


▄███▄    ▄███▄
███  ██▄ █▀▀▄
████████  ███▀
██▀ ▄███      
████████▄▄  ▄█▀
 ██████▀▀██▀▀
  ▀███▀▄▄   ▄
   ▀██▄██ ▄█▀
     ▀▀██▀▀
FULLY
ANONYMOUS

━━━━━
/

    ██▄▄              ▄▄██
   █▀  ▀█▄ ▄▄▄▄████▄██▀  ▀█
  █▀   ▄███▀▀▀       █▄   ▀█
 █▀   ▄███▄ ▄▄█▄▄     █▄   ▀█
██▄  ▄████████████▄▄  █▄  ▄██
  ▀▀██▀███████████████▄███▀▀
      ▀█▄█▀███████████▀▀
        ▀███▀███████▀
           ▀▀▀▀██▀▀
INSTANT
TRANSFER

━━━━
/

     ▄████▄
 ▄▄▄████████▄▄▄
▄██████████████▄
▀██▀ ▀█  ▀█ ███▀
 ██ ▀ █ ▀▄█ ███
▄██▄█▄█▄███▄███▄
▀██████████████▀
 ▀▀▀████████▀▀▀
     ▀████▀
API FOR YOUR
PROJECTS

━━━━

  █
  █
  █
████
  █
████
  █
████
  █
  █
  █
PARTNER PROGRAM
TOR MIRROR
MIX WALLET
.FAQ
ANN THREAD
TELEGRAM
iCEBREAKER
Legendary
*
Offline Offline

Activity: 2072
Merit: 1063


Crypto is the separation of Power and State.


View Profile WWW
March 27, 2015, 06:30:19 AM
 #129

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.

I think the bigger deal is having a trustless protocol for people to exchange bitcoins for XMR (when seeking financial privacy) and XMR for BTC (to access more merchants).

Distributed xmr.to and xmr.me!   Cool

Besides XMR (for volume) I vote VIA, XPM, and XCN as worthwhile inclusions, plus the standard/classic PPC and NMC, based on tech and PoW diversity.

VIA has CHECKLOCKTIMEVERIFY and a native Clearinghouse platform for IntellihashingTM.

XCN has custom transaction messages, unmalleable transactions, and withdrawal limits.


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
Is Dash a scam?
GingerAle
Legendary
*
Offline Offline

Activity: 1176
Merit: 1004


View Profile WWW
March 27, 2015, 11:40:26 AM
 #130

^^^ OP and another dude currently working on a similar project .....


any reason why you guys aren't teaming up?

I mean, I know I have no grounds to comment on how you're developing things, because I can't develop, but it would seem to me that if you are both creating the same thing, and its decentralized, and at least one of them is open source.... whats the benefit of developing solo?

Convergent evolution does have its advantages - you may come up with unique solutions to the same problem that can ultimately strengthen the general ecosystem via diversity. But collaboration also has its advantages.

< Track your bitcoins! > < Track them again! > <<< [url=https://www.reddit.com/r/Bitcoin/comments/1qomqt/what_a_landmark_legal_case_from_mid1700s_scotland/] What is fungibility? >>> 46P88uZ4edEgsk7iKQUGu2FUDYcdHm2HtLFiGLp1inG4e4f9PTb4mbHWYWFZGYUeQidJ8hFym2WUmWc p34X8HHmFS2LXJkf <<< Free subdomains at moneroworld.com!! >>> <<< If you don't want to run your own node, point your wallet to node.moneroworld.com, and get connected to a random node! @@@@ FUCK ALL THE PROFITEERS! PROOF OF WORK OR ITS A SCAM !!! @@@@
Uptrenda
Member
**
Offline Offline

Activity: 114
Merit: 10


View Profile
March 28, 2015, 04:26:41 AM
 #131

Thanks for replying to me mappum. It's good to see you have a plan for the malleability issues because once that's fixed your scheme will be quite an elegant and simple approach to the trust problem. I also wasn't aware you were already using TierNolan's more realistic approach to cross-chain trading. That should be fine and it shouldn't cause too much inconvenience because you probably don't want to support arbitrary currency pairs anyway since there's currently hundreds of currencies so maybe only having restricted pairs (pairs with at least 1 side supporting the non-standard TX) would be better for liquidity. For example you could have say: the major currencies like Bitcoin and Litecoin serving as proxies for the lesser known alt-coins.

I thought of another possible attack for your exchange, btw. Not sure if you've thought of this issue yet but the actual deposit of funds isn't done atomically so an attacker could just reply to a large number of trades, pretend that he's going to go through with them and then just never proceed with his deposit. Obviously there would be no loss of funds here because of the time-locked refund but I am suggesting the attack could be used to DoS the order book and cause people to waste a large amount of time. Not sure on the exact details of your matching system but from what I can tell it seems to be pretty trusting.

(Your account idea would be a simple way to solve this.)

Quote
^^^ OP and another dude currently working on a similar project .....


any reason why you guys aren't teaming up?

I mean, I know I have no grounds to comment on how you're developing things, because I can't develop, but it would seem to me that if you are both creating the same thing, and its decentralized, and at least one of them is open source.... whats the benefit of developing solo?

Convergent evolution does have its advantages - you may come up with unique solutions to the same problem that can ultimately strengthen the general ecosystem via diversity. But collaboration also has its advantages.

Yeah, and to make matters worse I was even working on the exact same contract concept as mappum 6 months ago. It was actually my questions to TierNolan that prompted him to improve his contract protocol but I ended up not using it because I thought of a different solution. Maybe if I knew mappum was interested in this we would have a working beta by now but I guess that ship has sailed...

We now both have created completely different systems with completely different technologies and I doubt either one of us would want to merge. It's a shame really. But who knows, maybe we could work together in some small way? I know we're certainly not the only guys working on a decentralized exchange ATM, but we may be the first to make a practical one for alt-coins.

becool
Legendary
*
Offline Offline

Activity: 1442
Merit: 1006


View Profile
March 31, 2015, 04:54:49 PM
 #132


Help us please.
It is not my picture. Other man screenshot it.
But I have some problem.
199 it is my too, but i sell this 199 dogs, and have some error.

"Canceled. Something went wrong, your funds where returned to you"

We want trade in mercury exchange.

mappum
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
March 31, 2015, 09:05:08 PM
 #133


Help us please.
It is not my picture. Other man screenshot it.
But I have some problem.
199 it is my too, but i sell this 199 dogs, and have some error.

"Canceled. Something went wrong, your funds where returned to you"

We want trade in mercury exchange.

Thanks for letting me know. Could you please PM me a link to your debug log so I can see what happened? It is located at ~/.mercury/logs/debug.log (on Windows, replace ~ with C:/Users/<username>).
watashi-kokoto
Sr. Member
****
Offline Offline

Activity: 336
Merit: 256



View Profile
April 03, 2015, 10:43:28 PM
 #134

Hi. What about the situation when miner create cheaper order and give to orderer for original price, claiming profit??
Jeremycoin
Legendary
*
Offline Offline

Activity: 980
Merit: 1003


𝓗𝓞𝓓𝓛


View Profile
April 04, 2015, 12:52:49 AM
 #135

Is there any "fee" for exchange?

Faucet used to be profitable
CryptInvest
Legendary
*
Offline Offline

Activity: 1680
Merit: 1053


http://www.daxico.com/


View Profile
April 04, 2015, 12:10:09 PM
 #136

Is there any "fee" for exchange?

Yes, comission bitcoin network for transaction 10.000 satoshi, DOGE = 1, LITE - unknown.

                  ██                 
                ▒████░               
            ░█████████  █░           
         ░████████  ██  ███▒         
       ▒███████░        ██████▒     
   ░▒███████░     ▒▒    █████████▒   
   ██████░     ░█████▒  ████ ██████ 
   ████     ░█████████  ████   ████ 
   ████   ███████▒  ██  ████   ████ 
   ████   ████▒         ████   ████ 
   ████   ████    ▒▒░   ████   ████ 
   ████   ████   ████   ████   ████ 
   ████   ████    ▒▒░   ████   ████ 
   ████   ████▒        █████   ████ 
   ████   ███████▒  ▒██████▒   ████ 
   ████     ░████████████░     ████ 
   ██████░     ░██████░     ░██████ 
    ▒███████░     ░░     ░███████▒   
       ▒███████░      ░███████▒     
          ▒███████  ███████▒         
            ░▒██████████▒           
                ░████░           
  DAXICO
        www.daxico.com
|
       ███████████████████████████████████████     
     ████████████████████████████████████████     
     ███                                   ███   
     ███                                █  ███   
     ███                           █   █   ███   
     ███    █                     █ █ █    ███   
     ███   █ █           █       █   █     ███   
     ███  █   █         █ █     █          ███   
     ███ █     █       █   █   █           ███   
     ███        █     █     █ █            ███   
     ███         █   █       █             ███   
     ███          █ █                      ███   
     ███           █                       ███   
     ███                                   ███   
     ███                                   ███   
     ████████████████████████████████████████     
     █████████████████████████████████████████   
    ███  █ █ █ █ █               █ █ █ █ █  ███   
  ████                                       ███ 
  █ ███████████████████████████████████████████ █
██                ███████████████                █
██████████████████████████████████████████████████
HASSLE FREE CRYPTOCURRENCY EXCHANGE
ANN BOUNTY REDDIT TELEGRAM TWITTER
|
  SIGN UP
NOW!
coinits
Legendary
*
Offline Offline

Activity: 1260
Merit: 1010


011110000110110101110010


View Profile
April 06, 2015, 02:20:01 AM
 #137

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/



Agreed but they are working on their own trustless exchange so it would seem that communication between communities will benefit everyone. I also suggest that Monero be added. A true private crypto and a bvery active community that would support a trustless exchange.

Jump you fuckers! | The thing about smart motherfuckers is they sound like crazy motherfuckers to dumb motherfuckers. | My sig space for rent for 25 btc per week.
Yaremi
Legendary
*
Offline Offline

Activity: 1484
Merit: 1047


igt-crypto.net - a legal crypto exchange with fiat


View Profile WWW
April 10, 2015, 01:38:47 AM
 #138

Hi dev, Please check CRAVE https://bitcointalk.org/index.php?topic=997356.5680

we would like to be sure you add us to

Thanks!

Cryptophile
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
April 10, 2015, 01:42:20 AM
 #139

Hi dev, Please check CRAVE https://bitcointalk.org/index.php?topic=997356.5680

we would like to be sure you add us to

Thanks!

+1
Jeremycoin
Legendary
*
Offline Offline

Activity: 980
Merit: 1003


𝓗𝓞𝓓𝓛


View Profile
April 10, 2015, 10:09:20 AM
 #140

What do you mean with "trustless"? Whether we can trus this cryptocurrency or what?

Faucet used to be profitable
Pages: « 1 2 3 4 5 6 [7] 8 9 10 »  All
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!