Please tell me that Hg is not downloading all bitcoin core blockchain?
Don't worry, Mercury runs lite clients for each coin and only ~3 MB of storage is required.
Topic: Mercury - Fully trustless cryptocurrency exchange - Looking for testers! - page 7. (Read 35176 times)
March 03, 2015, 06:35:06 AM
Don't worry, Mercury runs lite clients for each coin and only ~3 MB of storage is required.
March 03, 2015, 06:11:16 AM
I'd like to keep an eye on this!
March 02, 2015, 10:14:27 PM
very interesting project watching and hopefully will help out with some testing
Fuzzybear
Fuzzybear
March 02, 2015, 09:59:24 PM
Please tell me that Hg is not downloading all bitcoin core blockchain?
March 02, 2015, 04:46:16 PM
This is really cool, just a heads up - the QR codes that are generated don't seem to be valid...
I'm really looking forward to Mercury, thanks for all of your hard work so far!
+1 for NuBits
I'm really looking forward to Mercury, thanks for all of your hard work so far!
+1 for NuBits
Thanks for letting me know, I've fixed the QR codes. (All I needed to do was give them a white border, apparently they don't work on black backgrounds).
March 02, 2015, 05:02:53 AM
Please add Primecoin, is'nt a "2.0 coin" but is important for the searching of largest primenumber.
The network primecoin has already several prime numbers discovered:
http://en.wikipedia.org/wiki/Cunningham_chain
http://en.wikipedia.org/wiki/Bi-twin_chain
The network primecoin has already several prime numbers discovered:
http://en.wikipedia.org/wiki/Cunningham_chain
http://en.wikipedia.org/wiki/Bi-twin_chain
March 01, 2015, 11:55:51 PM
Interesting project, we need more of this sort of blockchain application and less currency based apps.
March 01, 2015, 04:20:29 AM
Interesting new "concept" maybe in the next hours I will try it and write here my opinion. From the screenshot it appears "good" now I should test a few "exchange" between doge <> litecoin <> bitcoin.
Good work guys!
Good work guys!
February 28, 2015, 11:41:21 PM
This is really cool, just a heads up - the QR codes that are generated don't seem to be valid...
I'm really looking forward to Mercury, thanks for all of your hard work so far!
+1 for NuBits
I'm really looking forward to Mercury, thanks for all of your hard work so far!
+1 for NuBits
February 28, 2015, 08:40:44 PM
Now it should be much easier to run Mercury, there are releases for each platform:
Try it out and let us know what you think!
Try it out and let us know what you think!
February 25, 2015, 07:09:53 PM
With the current setup of Bitcoin, you would need to wait just above 100 confirmations to do secure ACCT (Atomic Cross Chain Trading). This would be 1 full round of all delegates for DPOS (about 15-20 minutes atm). These intervals don't make sense for trading. For ACCT to become viable for any chain (without waiting too much) you need a PBFT or PBFT-like real-time Consensus and Ordering Protocol (COP) on top of the main blockchain to make ACCT viable.
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
I'm not sure where that information is coming from, it is incorrect. There would be no reason for atomic swap transactions to require more confirmations than any other payment transaction, so something like 6 would be a safe upper bound for even very high-value trades (and less confirmations can be used for smaller value transactions).
And any contract protocol that relies on third-parties as escrow or delegates is really a hack and not a very clean way to work with cryptocurrency. Protocols like that are also weak as any third-party can be bribed or be a sybil node.
BlockStream's design for sidechains relies on atomic cross-chain swaps with a very similar protocol to what is being used in Mercury, and their judgement is probably the most trustworthy in the cryptocurrency space. (See http://www.blockstream.com/sidechains.pdf, page 21).
I think he meant to say Bitshares, not Bitcoin, thus all the talk about DPOS and the bitsharestalk.org...
February 25, 2015, 06:58:29 PM
With the current setup of Bitcoin, you would need to wait just above 100 confirmations to do secure ACCT (Atomic Cross Chain Trading). This would be 1 full round of all delegates for DPOS (about 15-20 minutes atm). These intervals don't make sense for trading. For ACCT to become viable for any chain (without waiting too much) you need a PBFT or PBFT-like real-time Consensus and Ordering Protocol (COP) on top of the main blockchain to make ACCT viable.
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
I'm not sure where that information is coming from, it is incorrect. There would be no reason for atomic swap transactions to require more confirmations than any other payment transaction, so something like 6 would be a safe upper bound for even very high-value trades (and less confirmations can be used for smaller value transactions).
And any contract protocol that relies on third-parties as escrow or delegates is really a hack and not a very clean way to work with cryptocurrency. Protocols like that are also weak as any third-party can be bribed or be a sybil node.
BlockStream's design for sidechains relies on atomic cross-chain swaps with a very similar protocol to what is being used in Mercury, and their judgement is probably the most trustworthy in the cryptocurrency space. (See http://www.blockstream.com/sidechains.pdf, page 21).
I think he meant to say Bitshares, not Bitcoin, thus all the talk about DPOS and the bitsharestalk.org...
February 25, 2015, 04:06:15 PM
With the current setup of Bitcoin, you would need to wait just above 100 confirmations to do secure ACCT (Atomic Cross Chain Trading). This would be 1 full round of all delegates for DPOS (about 15-20 minutes atm). These intervals don't make sense for trading. For ACCT to become viable for any chain (without waiting too much) you need a PBFT or PBFT-like real-time Consensus and Ordering Protocol (COP) on top of the main blockchain to make ACCT viable.
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
I'm not sure where that information is coming from, it is incorrect. There would be no reason for atomic swap transactions to require more confirmations than any other payment transaction, so something like 6 would be a safe upper bound for even very high-value trades (and less confirmations can be used for smaller value transactions).
And any contract protocol that relies on third-parties as escrow or delegates is really a hack and not a very clean way to work with cryptocurrency. Protocols like that are also weak as any third-party can be bribed or be a sybil node.
BlockStream's design for sidechains relies on atomic cross-chain swaps with a very similar protocol to what is being used in Mercury, and their judgement is probably the most trustworthy in the cryptocurrency space. (See http://www.blockstream.com/sidechains.pdf, page 21).
February 25, 2015, 12:17:14 PM
With the current setup of Bitcoin, you would need to wait just above 100 confirmations to do secure ACCT (Atomic Cross Chain Trading). This would be 1 full round of all delegates for DPOS (about 15-20 minutes atm). These intervals don't make sense for trading. For ACCT to become viable for any chain (without waiting too much) you need a PBFT or PBFT-like real-time Consensus and Ordering Protocol (COP) on top of the main blockchain to make ACCT viable.
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
That, or the light client trading server does Paypal-like fraud detection and compensates counterparty risk accordingly with pretty high trading fees (anywhere from 0.5-4% of each transaction).
Source: https://bitsharestalk.org/index.php?topic=14472.msg188878#msg188878
February 24, 2015, 05:47:29 PM
Regarding 2/3: ....Then the wallet would allow to automatically sign/broadcast atomic tx whenever my order is matched on a server?
Yes. The server will notify the wallet that it has found matches, and the wallet will verify they are valid then start the swaps with the other traders.
Sweeeeet!
Does that mean "instant transactions" like at the speed of Darkcoin (10 seconds)?
Or how long would the actual transaction take to verify?
Does that mean "instant transactions" like at the speed of Darkcoin (10 seconds)?
Or how long would the actual transaction take to verify?
No, you will still be limited by blockchain confirm time (but a green address model can be used to create instant transactions for trades). For small trades, it can be safe to use unconfirmed transactions, so the trades will be instant. For large trades, you will want to wait for confirms to make sure the other trader can't double-spend.
February 24, 2015, 09:11:16 AM
Nice ! I don't fully understand the internals how it work . But this sounds very promising . Keep up the work !
February 24, 2015, 07:06:41 AM
Great Project! Do you've considered to add BitShares BTS bitUSD, bitGOLD etc!?
I'll consider any cryptoassets that have lasting value. I'm going to take a neutral approach and add assets that have sufficient volume, so I don't have to pick sides on what currencies to use. Bitshares has significant volume right now so I'll look into adding them.
Thanks for this wallet! It looks very promising.
My questions are regarding the usability and how it works in practice:
1. AT would allow (in principle) Alice and Bob to exchange their coins across two different chains. But how do do the two find each other? Does your wallet include a order book and order matching?
2. What parts of the exchange process would be manual, what automated?
3. How would the user experience be different from a centralized exchange? (centralized exchange: cash in coin x -> place order on market for coin x and coin y and wait till order is matched OR take an order that has been placed -> cash out)
My questions are regarding the usability and how it works in practice:
1. AT would allow (in principle) Alice and Bob to exchange their coins across two different chains. But how do do the two find each other? Does your wallet include a order book and order matching?
2. What parts of the exchange process would be manual, what automated?
3. How would the user experience be different from a centralized exchange? (centralized exchange: cash in coin x -> place order on market for coin x and coin y and wait till order is matched OR take an order that has been placed -> cash out)
1. Mercury uses an order matching server. However, no trust is placed in that server (it does not deal with the actual exchange of funds), and use of the service in optional. Two parties can find each other and make a deal on their own (e.g. through forums or IRC), then they could still use Mercury to trustlessly swap the funds.
2. Everything is automated, the user experience should be just like any of the current exchanges (except that it is from a desktop wallet instead of a website).
3. It shouldn't be different, except instead of depositing into an account, you can trade using the balance in your wallet.
Regarding 2/3: ....Then the wallet would allow to automatically sign/broadcast atomic tx whenever my order is matched on a server?
February 23, 2015, 03:28:47 PM
Great Project! Do you've considered to add BitShares BTS bitUSD, bitGOLD etc!?
I'll consider any cryptoassets that have lasting value. I'm going to take a neutral approach and add assets that have sufficient volume, so I don't have to pick sides on what currencies to use. Bitshares has significant volume right now so I'll look into adding them.
Thanks for this wallet! It looks very promising.
My questions are regarding the usability and how it works in practice:
1. AT would allow (in principle) Alice and Bob to exchange their coins across two different chains. But how do do the two find each other? Does your wallet include a order book and order matching?
2. What parts of the exchange process would be manual, what automated?
3. How would the user experience be different from a centralized exchange? (centralized exchange: cash in coin x -> place order on market for coin x and coin y and wait till order is matched OR take an order that has been placed -> cash out)
My questions are regarding the usability and how it works in practice:
1. AT would allow (in principle) Alice and Bob to exchange their coins across two different chains. But how do do the two find each other? Does your wallet include a order book and order matching?
2. What parts of the exchange process would be manual, what automated?
3. How would the user experience be different from a centralized exchange? (centralized exchange: cash in coin x -> place order on market for coin x and coin y and wait till order is matched OR take an order that has been placed -> cash out)
1. Mercury uses an order matching server. However, no trust is placed in that server (it does not deal with the actual exchange of funds), and use of the service in optional. Two parties can find each other and make a deal on their own (e.g. through forums or IRC), then they could still use Mercury to trustlessly swap the funds.
2. Everything is automated, the user experience should be just like any of the current exchanges (except that it is from a desktop wallet instead of a website).
3. It shouldn't be different, except instead of depositing into an account, you can trade using the balance in your wallet.
February 23, 2015, 06:13:13 AM
...the OP...
Thanks for this wallet! It looks very promising. My questions are regarding the usability and how it works in practice:
1. AT would allow (in principle) Alice and Bob to exchange their coins across two different chains. But how do do the two find each other? Does your wallet include a order book and order matching?
2. What parts of the exchange process would be manual, what automated?
3. How would the user experience be different from a centralized exchange? (centralized exchange: cash in coin x -> place order on market for coin x and coin y and wait till order is matched OR take an order that has been placed -> cash out)
February 23, 2015, 02:57:50 AM
Great Project! Do you've considered to add BitShares BTS bitUSD, bitGOLD etc!?
I'm working for BitShares. If you've interest in principle please don't hesitate to contact me via PM!
Cheers
cass
edit: BTW i really like your github activity map^^ Nice idea
I'm working for BitShares. If you've interest in principle please don't hesitate to contact me via PM!
Cheers
cass
edit: BTW i really like your github activity map^^ Nice idea
Jump to: