Bitcoin Forum

Few days ago member raw_avocado (https://bitcointalk.org/index.php?action=profile;u=3062430) made a post and youtube video (https://youtu.be/QYblYDg_awU?t=1031) with various solutions we can use for improving Bitcoin privacy and one of them was new wallet called Mercury.

I got interested about it and I started reading Mercury documentation to better understand how exactly it works, and I tested it for the first time with testnet Bitcoin that is only available option now.

It is using something called CoinSwaps on layer-2 statechain that enables safe transfers of private keys without any on-chain transactions or paying miner fees, but I think there is 0.4% fee for deposits and withdrawals.

Wallet is first asking you to create 12 mnemonic words, name your wallet and add passphrase with minimum 8 characters, then you can select Statecoin value and deposit coins to generated address.

https://i.imgur.com/77TIhWF.jpg

There is currently eight State coin values but liquidity is high for 0.0001 BTC so I choose that option for my testing and everything went just fine.

I am currently Awaiting Swap and Privacy Score to increase for my Statecoin, so I am calling other experienced members to join testing and report any bugs on their github page.

https://i.imgur.com/mkndnkp.jpg

Website:
https://mercurywallet.com/

Github page:
https://github.com/layer2tech/mercury-wallet

Documentation:
https://docs.mercurywallet.com/docs/

---

*This is unofficial thread, and I am not associated with Mercury wallet team in any way.

Mercury Wallet moved from testnet phase and it's now officially in Beta mode working with mainnet Bitcoin.
Latest released version is 0.4.39, they made a lot of improvements, added dark theme, and I think this will soon be very good alternative for CoinJoin and Wasabi wallet, and one more tool for making private Bitcoin transactions.
Most liquidity now is for 0.001 BTC but I expect it to grow for other values in future.

If you didn't test it yet, give it a try, and before that watch video instruction to see how Mercury Wallet works:
https://www.youtube.com/watch?v=9DSvNzTBePY

I read the documentation, and it appears there might be some missing information.

The second paragraph in the "overview" section starts talking about the "SE" but this term is never defined. It is unclear what this is.

At the end of the first paragraph of the "statechains" section, it says that any collusion between the "SE" and an old owner of a UTXO that results in theft of a UTXO can be trivially proven. This does not explain any consequences of this collusion. If someone were to buy up all the 0.0001 BTC UTXOs one at a time, and sell each UTXO before buying the next one, if they are colluding with the "SE" what would prevent them from being able to have a tx confirmed to an arbitrary address? I don't see anything in the documentation that would.

The "fraud proof" paragraph again says that it can be trivially proven if the "SE" is corrupt, and alludes that the ability to prove a "SE" is corrupt is an incentive to be "honest". Again, the documentation does not explain the actual consequences for the "SE" for being corrupt. The LN protocol for example, has concrete consequences for publishing an old channel state to close the channel -- the other party is able to recover the entire channel balance of both parties. There does not appear to be any financial consequences for a corrupt "SE" that I can see.

I am curious if you are in any way associated with this project.

https://mercurywallet.com/#faq

Thanks. The documentation at https://docs.mercurywallet.com/docs/ should be updated with their clarification.

I think the other issues are probably more important to be addressed before anyone should consider trusting their money with this type of service.

No I am not associated with them in away way, but I am following the project for a while, I was testing to see how it works in testnet, and I did notice some bugs in previous releases.
I didn't see many crypto projects that always have updated documentation, and Mercury was still in testing phase until recently so you can't expect miracles from them.
You could always ask them for feedback or write an issue on their github.

I don't have to trust them, but they are just one of the layer two solutions for Bitcoin, and I could also say that I don't fully trust Lightning Network or Liquid.
Idea in Mercury is that you have full custody of your coins at all times, and you could always withdraw coins to regular Bitcoin wallet.

Interesting article about Mercury statechains in Bitcoin Magazine:
https://bitcoinmagazine.com/technical/a-new-privacy-tool-for-bitcoin

Lightning Network protocol has measures in place that specifically prevent the theft of bitcoin by your channel partners. As far as I can tell, there are no similar measures in place with Mercury protocol.

I don't think it is accurate to say that you have full custody of your coins at all times, or at least this would not be true if you were to say "sole custody". This is according to my understanding of how Mercury works.

Every centralized service that holds custody of your bitcoin says that you can withdraw at any time. So did most ponzis before they imploded.

I don't think it is safe to entrust your money with Mercury until the issue of an malicious SE stealing your money is addressed.

I never asked anyone to send bitcoin to any service, there was testnet and you could test how it works, not just speak in theory after few minutes of reading docs.
You can do as you like, but I also don't trust anything you say and I have your reputation to back me up on that  :D

I also think that Catena XXX and other defi stuff that you are advertising is also centralized junk that only have decentralized label.
Hope you also checked their ''documentation'' as well... sounds almost like a very visionary scam thing to me.

These kinds of attacks against someone asking basic questions should set off red flags to anyone considering to use this wallet.

I also think it is strange that you are promoting something originally posted by a one-post newbie ::)
DeFi obviously has risks, and these risks are very well known. I don't think anyone is trying to hide these risks, or lying about these risks not actually existing.

I am not fucking representative for Mercury so I don't have to answer anything to you, and those imaginary ''attacks'' against you are just facts that nobody in this forum trusts you anymore.
Deal with it defi boy.

That newbie raw_avocado (https://bitcointalk.org/index.php?action=profile;u=3062430) is a real person, bitcoin og and you can easily find him on youtube and other social media.
He obviously cares about privacy for Bitcoin, not about some shitcoins or scamming people.

That seems to be the case. The fraud can be trivially proven, which would obviously result in the wallet being labelled a scam and the developers being investigated, but there is no on-chain punishment (at least, not at the moment). So from that point of view it works the same as any centralized exchange or service, any mixer, or any non-open source wallet or piece of software - reputation. Not ideal, but I'd still be willing to trust them with small amounts of coins at a time to use their service in due course, once they've proven themselves.

If they fix the lack of security measures then possibly, it might be good. But as of now this really looks like an answer in search of a question.
Or an answer to a question that has already been answered.
The coding I saw on gitgub, was not great. But, I really can't say I am any better since a lot of times when I do stuff the first few dozen commits are so bad when I go back and look later I wonder if I was slipped some LSD in my morning coffee when I started the project.

I use a services like Whirlpool / Wasabi / JoinMarket. But, that's just me since I run my own nodes / servers for them.



Some of the things he said in the video were not 100% accurate. I had it on late last night while doing some other things, will watch it again, before commenting more.
As for OG? Only 1 post here, the youtube channel that the video he posted here is only 10 months old mostly filled with meh videos IMO and his twitter account although 5 years old is filled with a lot of crap, yet again  IMO

At 1st glance looks like someone who wants to be an 'influencer' will go dig deeper later.

-Dave

As I understand Mercury wallet is something between centralized mixer service and coinjoins, you can always restore your coins from seed words even if Mercury server is down, and nobody can seize them if something goes wrong.
Private key is split shared so nobody knows full private key including Mercury server, but I would still be careful with Mercury while it is in beta phase.
One issue I noticed is that sometimes wallet does not sync or connects to server and i watched a longer video from last month that showed some other issues are possible:
https://www.youtube.com/watch?v=pL3gQ3C-qPg

So now we are measuring and judging people by number of posts in this forum and trash talking the newbie are we?  :)
Yeah one post from that account, and who knows if he has other accounts like many of people have in this forum.
I think he first heard about Bitcoin on 4chan forum and you would see him in most Bitcoin conferences and meetings, he is not hiding his face anymore behind computer like most people.
Not defending him at all, but guy is obviously interested in privacy, and that is not meh subject for me Dave, maybe it is for you idk.
Anyway if you guys want to continue talking about Alex aka raw_avocado you can open new topic about him and go full force.

Not quite.

From my understanding, it is trivial to create an arbitrary number of Mercury servers, any of which could be acting evil. So Alice could create 10 Mercury servers, initially all of them honestly, then one steals all of the bitcoin it is holding, so users stop using it, but Bob has no way to know that Alice is running 9 other servers, and there does not appear to be any way to decline to use any particular Mercury server, so even if it was known that a Mercury server was dishonest, there does not appear to be any mechanism for Bob to prevent his wallet from using Alice's known dishonest server.

With CM for example, if they were to scam their customers, this would quickly become well known, and people could simply not use their services. Granted those behind CM could create a new service after they scammed under their CM name, however they would need to build up a reputation before being able to attract a lot of business.

It is no secret that CM is a centralized service, and that there is the risk that CM will scam their customers. CM does not try to hide this. With Mercury Wallet on the other hand, their documentation is misleading in that it is saying that funds in their wallet are not at risk of loss. There is also the concern that dkbit98 is shilling for this wallet while falsely saying he is not.

If that's the case, then I have misunderstood their operating model. I was under the impression that everyone would be using the same centralized server being operated and maintained by the Mercury team themselves, just as you do when you use a centralized exchange or a mixer. Therefore if there was a provable scam accusation against them, then the entire project would be moot, and it is relatively easy for them to build up a good reputation over time.

If, as you say, anyone can host one or more servers and act as a statechain entity, then I agree, the security model is poor at best. With no way of punishing someone other than reporting that server to be a scam, at which time the user in question can just spin up a new server, then I would not be depositing any coins to this wallet.

dkbit - do you know the answer to this?

That's my understanding too. It seems to be open source so you can technically download Alice's version and use Alice's server, or maybe even configure the "original" wallet to connect to a different SE, but that's no different from using scammychipmixerclone.com.

https://github.com/layer2tech/mercury-wallet

https://meem.link/i/jutb52a4.png

If this is a centralized service using a protocol they designed, it would resolve most of my concerns. Although one concern that would remain would be the fact that I was attacked by a shill when I tried to ask questions.

If I was incorrect, I would ask how they are different than CM? AFAICT, they are basically the same as CM, except for the amount of time that bitcoin can be held at the mixer. Obviously CM can handle larger amounts due to their reputation.

Swapping your coins with another user does not result in an on-chain transaction, so technically it would be invisible to blockchain analysis, provided the withdrawal transactions don't leave any unique fingerprints such as by using unusual nlocktimes or similar (I've not examined the code closely enough to know if this is the case). This could be a good or a bad thing, depending on your specific use case. If you need to hide the fact you are using ChipMixer or a coinjoin, then this wallet could do that. However, this also means that unlike ChipMixer or a coinjoin, the coins you receive are not unlinked from their history. From a blockchain analysis point of view, any coins you receive from this wallet will still have their full history attached, and will simply have gone through a single intermediary address before arriving at your wallet or the final destination you are sending the coins to.

You made up the nonsense about the wallet connecting to random fraudulent nodes, and the shill accusation. Don't expect everyone to just roll over and not talk back when you do shit like that.


A (potential) advantage would be the ability to withdraw your funds using the backup locktime TX even if the centralized service goes down, is seized by the FBI etc.

Also lower transaction costs and liquidity provided by third parties, but that benefits the service more than the users.

From my perspective, this is doing the same thing that CM does.

The process flow with CM is as follows from my perspective as a customer/user:
Bob deposits bitcoin to CM
CM splits Bob's deposit into various "chips" in amounts that are similarly available via Mercury
QS deposits bitcoin to CM
QS deposit is electronically credited to CM's database, rounded down to an amount that can be split up into various "chip" sizes
QS withdraws "chips" from CM session by obtaining various private keys of "chips" and spends the bitcoin to addresses whose private keys I generated

The process flow with Mercury is as follows from my perspective as a customer/user:
Alice deposits bitcoin to a Mercury "SE" in an amount that is the same as a "chip" used by CM
QS deposits bitcoin to a Mercury "SE" in an amount that is the same as a "chip" used by CM
Alice and QS swap "statecoins" via the Mercury wallet
QS "withdraw" from my Mercury wallet by spending the statecoin

The only difference between CM and Mercury is that CM allows the flexibility of allowing multiple "chips" to be purchased in one transaction. Mercury statecoins must be spent within a certain number of blocks because the nLockTime of the transaction given to the user in the event the SE becomes uncooperative expiring means that the statecoin is at risk of theft by prior owners. There will be two distinct fingerprints of Mercury transactions, 1) outputs of the funding transactions are in exact amounts available on the Mercury platform, and 2) that UTXOs are always spent within however many blocks Mercury requires users to spend the UTXO by.

---

There is another issue with Mercury that will potentially result in the loss of money:
Each time a statecoin is transferred, the backup transaction used in the event the SE becomes uncooperative has the nLockTime value decline by one. A malicious user could potentially send statecoins to himself multiple times to get the nLockTime value to be very low (after waiting for required transaction fees to be high). The malicious user, Bob could swap statecoins with Alice, and unless Alice nearly immidiately spends the statecoin with a transaction with a next block confirmation transaction fee, Bob can spend the UTXO with his most recent "backup" withdrawal transactions. 

I suppose the next question is what fees are Mercury going to be taking for running this service? They don't actually have any transaction costs as far as I can see, since the person depositing the coins to the split key address pays the transaction fee there, and the person ultimately withdrawing the coins will pay the transaction fee on that end. But they will obviously need to pay for running and maintenance of there servers. And when is that fee taken? There's a privacy implication there too if a deposit or withdrawal transaction also has to pay a small amount to an address which can be identified as belonging to Mercury.

There is nothing saying the nLockTime value must decrease by 1, and indeed, doing so leaves it open for previous owners to steal transactions which are RBF enabled.

I guess he needed to write some lies like that for his signature campaign so I forgive him, and nobody is taking him seriously anymore in this forum except maybe some circus show in his local area.
I don't feel the need to explain anything to clowns, and I am not an expert with a big mouth, but I noticed bunch of nonsense and mistakes in his previous posts, so if anyone want to get reply to this false accusations will have to contact Mercury devs or in github that can also be used for bugs and issues:
https://github.com/layer2tech/mercury-wallet

It was 0.4% for deposits and withdrawals last time I checked, but I can't confirm that for mainnet and I think that internal transactions are free and without fee.

You're right.

It does appear that the nLockTime interval is done on the server level, not protocol level. I have never coded in rust, so I am having a little difficultly following what is happening, however there is a config file (https://github.com/commerceblock/mercury/blob/a78f57c24cd4a8d80d760ad0040f1fcf09c039ec/server/src/config.rs) that appears to set the nLockTime interval as an integer, and according to the settings file (https://github.com/commerceblock/mercury/blob/a78f57c24cd4a8d80d760ad0040f1fcf09c039ec/server/Settings.toml) it is prefilled to 10 blocks, but is set to 100 by default if it is not in the settings file.

I am not sure if there is anything in the protocol that ensures the SE gave every user a "backup" closing transaction with the correct nLockTime.

The Transfer section of the protocol docs (https://docs.mercurywallet.com/docs/01protocol.html) says in step 7 that the old owner will create a new "backup" closing transaction, whose nLockTime is set to the next confirmation interval, and step 8 says that the new closing transaction is sent to the SE to confirm the nLockTime field is correct.

Step 1 says that the private key used for the backup transaction is different than the statechain private key, so if a backup transaction was broadcast and sent to the wrong address, I don't know if it could be proven the SE was acting maliciously.

Also in the settings file is a fixed address for "fees" to be received at. It is unclear how the fees are paid.

I'm sorry, but asking questions is not making up nonsense.

I do think it is strange that dkbit98 starts attacking me when I ask questions about a project asking to be trusted with people's money. If you disagree, then you are blinded by your bias.

Your question was answered:


You kept making shit up:


Also this:


is not a question at all.

But sure it's my bias. About some random wallet I've never heard of before. Wait, maybe I'm a shill too? ::)

Take care of yourself. You seem to be declining rapidly.

So I downloaded it to have a poke about and figure out the fee situation. According to the Terms of Use, it seems that fees are charged only on withdrawal of a statechain UTXO to an external address, at a rate of 0.5% of the value of the UTXO, regardless of the number of swaps which have taken place. There is no fee for depositing or for swapping. It says the fee will be automatically deducted from withdrawal transactions and transmitted to the bitcoin network, which I can only assume means in a separate output, which has privacy implications as I discussed above.

That's as far as I got, however, since the wallet seems to hang forever trying to establish a connection, with just permanently trying to sync under each heading "Connecting to Server", "Connecting to Swaps", "Connecting to Bitcoin". According to my network analysis it is neither sending nor receiving any data, but I also don't see anything on my system which is blocking it from doing so. ???

Yeah, I had the exact same issue like you with wallet never connecting to Server, Swap and Bitcoin, and I have no idea how to fix it.
I just tried it now again and it only connected to Bitcoin but not to Swap or Server, so it could be something related with Tor or other settings like ports.

https://i.imgur.com/Lj3qM07.jpg

EDIT: Maybe it just needs more time waiting, just got connected to Server, only Swap left.

The premise is alluring, that's for sure, but I'm still confused about the implementation of the technology.  The technical aspect are bit over my head, but I'm more curious about functionality and how it would differ from any other custodial wallet.  Would "statechain" be a proprietary technology only available if using Mercury wallet, or would its licensing allow any wallet developer to implement it?

If it's the latter, I can see how it would be beneficial to bitcoin in general, but if its the former, I don't see how that would be any more attractive than other trusted custodial wallet providers who also offer internal transfers:

I'm a bit confused when it comes to choosing a custom value for the statecoin ^{[deposit page]}. Let's assume for a second that I want to swap a specific amount ^{[e.g. 0.4987BTC]}... Is it going to also show a pending swap group for that amount, on the swap page?
^{- From what I've understood, when you try to swap 1BTC, you automatically join a 1BTC swap group, as opposed to a bunch of smaller ones [hence why I asked the above question].}

Difference is that you can't generate 12 seed words in Binance and other centralized services and have control over your Bitcoin.
In this case coins can't be confiscated or seized because private key is split-shared between several parties, but since this is beta version I do expect to see bunch of bugs so I don't recommend using real BTC yet.
Even if you want to do it, you can't because there is no liquidity yet except for 0.0001 BTC maybe  ;)

Okay, I managed to get the wallet to sync so I've been able to have a good look around now.

Here is the basic screen when you first load it up after creating a new wallet and backing up the seed phrase:

https://i.imgur.com/hNhmQpv.jpg (https://i.imgur.com/hNhmQpv.jpg)

If you hit the deposit button, you get a screen which offers 6 suggested denominations and their current liquidity, or the option to choose your own amount:

https://i.imgur.com/W9OLKEv.jpg (https://i.imgur.com/W9OLKEv.jpg)

If you hit the swap button, you get the option to join a swap pool for some of the pre-set denominations:

https://i.imgur.com/Mn4bZ8Q.jpg (https://i.imgur.com/Mn4bZ8Q.jpg)

And you can also choose to send or receive statecoins using specific statecoin addresses:

https://i.imgur.com/f2WQ2Sa.jpg (https://i.imgur.com/f2WQ2Sa.jpg)

It seems not, or at least, not at the moment. Perhaps if there are dozens of users with 0.025 BTC they may implement custom swap groups, but it seems unlikely for values as specific as 0.4987 as you suggested. If you have an odd value like this, then you can still send it to someone else, but it looks like you'd need to come to a trade arrangement externally.

If the Mercury team wants to solve the problem with the closing transaction potentially being issued to someone colluding with the SE, they should make the closing transaction something that is part of the statechain.

Otherwise, a corrupt SE could produce a closing transaction with a number_of_transfers of 10 and subsequently transfer a statecoin with a value of 9 (along with an associated closing transaction). This would allow the SE to spend the UTXO before the legitimate owner of the statecoin can spend the UTXO. There would be no way of the legitimate owner to prove they didn’t send the statecoin to someone else. 

The "SE" stands for statechain entity.  In the context of Mercury, its the mercury server.

---

First all mercury uses an HSM on the back end:

https://github.com/commerceblock/lockbox

The HSM deletes all the key shares for each transaction.  So the HSM would have to be broken for the scenario you mention. 
The latest user always has an updated "blackout transaction", therefore this is proof on who should be the current owner.

---

With MercuryWallet you have a blackout transaction, therefore at all times you can remove your funded.
The SE can't steal the funds, per se.

[moderator's note: consecutive posts merged]

Yes, it is a centralised service - with a server (the 'SE') run by https://mercurywallet.com

The server (which consists of the main http server: https://github.com/commerceblock/mercury and the Lockbox, which uses hardware security to generate and securely delete key shares: https://github.com/commerceblock/lockbox ) is all open source (as is the wallet) so anyone could also run their own service.

There are several differences with CM, as I understand it. Mercury is 'proactively non-custodial', which means that if you trust that they have not acted maliciously in the past, there is no way that it can steal user deposits. The only way the server can steal funds is to 1) Not delete previous owner key shares (as claimed) and then 2) Collude with a previous owner of the coin to reconstruct the full private key. If server key shares for previous owners are deleted after transfer, there is no way the current owner can be stolen from. This still requires trust in the server not to act maliciously from the start, but prevents the operator from being able to seize of freeze coins arbitrarily or being compelled to do so (by e.g. authorities). I believe that CM is fully custodial.

Also, with regards to privacy. I think with CM, you must fully trust CM itself not to retain or leak information linking inputs and outputs (or for CM to be a honeypot). The assumption with mercury is that everything the server knows is also public (we are building an explorer). Here the privacy is trustless - coins are swapped in groups via a blinded token scheme that is similar to Zerolink (that Wasabi uses) - that are effectively off-chain coinjoins (with atomicity enforced by the server). https://blog.commerceblock.com/bitcoin-privacy-and-tainting-coinjoins-and-coinswaps-meet-statechains-b0d6c1146a24

I don't think dkbit98 is a shill, but I am :)

Mercury does not have custody like a CM.  There is not reason why Mercury can't handle large amounts and with Mercury you can do unlimited swaps.

The interval is set by the server. Currently it is 6 blocks (1 hour). The backup tx is not RBF enabled, and the wallet allows the user to create a CPFP tx to be broadcast at expiry simultaneously.


The server enforces this. You must trust it to do so.


The user has a private key (new one for each coin/transfer, from a BIP32 seed) that is used for:

1) their share of the 'full' private key (of the UTXO) that no-one ever knows
2) their 'proof' key, that they use to sign the statechain to authorise a transfer/withdrawal,
3) The address of the backup transaction.

The owner must sign the statechain (to the public key of the new owner) in a transfer, before the server will co-sign the backup tx and complete the key share update process. Also, in the case of a withdrawal, the owner signs with their proof key that they are withdrawing and their withdrawal address, before the server will co-sign the withdrawal tx. If there is a valid transaction that spends the UTXO, then the server should be able to produce a signature authorising that specific transaction by the owner. If they cannot, in the case that they are accused of theft/collusion, then this is indication of guilt.


Fees are paid on withdrawal (either cooperatively or via backup tx). Currently 0.5% of the coin value. We think this is competitive with other privacy/coinjoin/mixing services.



The trust needs to be earned. Certainly at the moment, it is in beta, and we wouldn't recommend large amounts be deposited as we work out bugs.

Are you part of Mercury developer team or associated with their team in any way?
Some people here are allergic to Newbie members, so I think that some small explanation would be nice from you.

There are mixing services that don't charge any fees, and I think that you should consider lowering your fees during beta phase and increase them later.
I would also like to see some code audit and reviews from other security experts.

Hey nicosey, one suggestion for future, please try to write your answers in one post, not in multiple consecutive posts (that is against forum rules).
Thanks in advance.

Mercury is a centralised service - but it's all open source (wallet and server).

Using a trusted custodian has very poor privacy, and your funds can be seized or frozen at any point. Also, you are likely to be required to submit to KYC.

Understood, sorry not used Bitcointalk for a while.  tomt1664 and I are both part of the team.
We have had informal architectural reviews, however nothing official.

I don't know organization qualified to code this type of code, and my experience of code audits in the past has not been positive.

Regards...

Yes, I am part of the team. https://github.com/tomt1664


We have to charge some fees (we are a business). We are certainly not planning on generating significant income during beta testing, but there is a minimum amount that can be charged. Anything less than 0.4% of 0.001 BTC hits the dust limit.

Once beta is passed with the current design, we plan on adding a feature to allow users to pay the fee via Lightning. This could be made lower.

Professional code audits are expensive, and I think we would need to see some success before paying someone to do this. More likely we will have a bug bounty. Hopefully the code will get more attention as it becomes more widely known - all development is being done out in the open, and has been from the start.

How is the fee paid at the moment? Is it simply as an additional output from the withdrawal transactions? If so, this raises significant privacy concerns as not only will the fees be of common values since both the fee rate and the standard statecoin sizes are static, but you will then have to consolidate all these fees together in to your own wallets, which again will aid in identifying them as coming from Mercury, and therefore identify the coins which were withdrawn as having come from Mercury.

What about a way for a user to pre-pay 10/20/50 whatever withdrawals in advance, much like TrustedCoin do for 2FA Electrum wallets? Both a privacy benefit for the user and a financial benefit for you for not having to consolidate so many small outputs.

We have been thinking about something like that.  More taking a lightning payment upfront. 
Would take a while to develop.

The fee is paid as an output in the withdrawal transaction (i.e. the tx that spends the statecoin UTXO). This will be easily identifiable, and we are not trying to hide these transactions, in the same way coinjoin transactions are easily identifiable. Our model is that users should assume that everything the mercury server knows is public, and that privacy doesn't rely on a trusted third party keeping secrets. The privacy in our model comes from the swap protocol, which uses a zerolink-style blinded token system to prevent the server from knowing how ownership has changed in a swap group https://github.com/commerceblock/mercury/blob/master/doc/swaps.md. This privacy model is discussed in more detail here: https://blog.commerceblock.com/bitcoin-privacy-and-tainting-coinjoins-and-coinswaps-meet-statechains-b0d6c1146a24

We initially considered a fully blinded statechain server, where the server is not even aware of the UTXO's involved in deposits and transfers, however this would have been much more complex and involved a much worse UX. This could be a future project though.

I noticed some issues with Mercury wallet not shutting down properly and it keeps running in background, then after I shut it down it down manually I am unable to start it back again (server, swap and bitcoin are not connecting) until I restart my computer.
Other small bugs I noticed with dark theme not showing any text on some buttons, or each time I start wallet again it turns back to light mode.

I understand that but like I said Mercury is still beta phase and currently there isn't any volume for swaps except medium amount for smallest statecoin value.
Maybe you could introduce voluntary fee donation and create some campaign to increase liquidity.
If I understand correctly, you are also making a web explorer for statecoins and all transactions will be public for anyone to see, is that correct?

This future project would be unrelated with Mercury wallet or what?

Thanks, will look into the bugs.

Blockexplorer should be out in two weeks.

At the moment we are not looking at making Mercury fully blinded, looking at lightning integration in medium term.

Thank you for responding. A lot of what I had posted had already been addressed/discussed by others in this thread, so there is no need to rehash those issues.

Yes, I found that repo, however I am not confident it is possible to "prove" your server is using that specific code.

Except for the issue of "blackout transactions" (below), I don't think deleting an old key or using specific code is a big deal, because as your documentation says, the statechain is signed in a way that proves if the SE is colluding with an old owner of a statecoin.

So my concern would be a scenario as below:

Alice currently owns a 1BTC statecoin issued by a Mercury server
When Alice obtain her 1BTC statecoin, she also received a "blackout transaction" with an nLockTime expiration of block 710,000.
Alice and the Mercury server agree to collude with eachother to steal the statecoin, so they create a new "blackout transaction" with an nLockTime expiration of 709,050
Alice "sells" her 1BTC statecoin to Bob for 1BTC that is transferred on-chain.
As part of the above transfer, Alice uses her private key to sign the Statechain with Bob's public key, and with the help of the Mercury server, creates a "blackout transaction" payable to Bob's "blackout" address that is different and distinct from the public key she just signed. The "blackout transaction" payable to Bob has a nLockTime expiration of block 709,994 (710,000 minus 6).
Now Alice has a "blackout transaction" with a nLockTime expiration of 709,050 and Bob has a "blackout transaction" with a nLockTime expiration of 709,994.

If Alice were to broadcast her "blackout transaction" at block 709,065, based on the current protocol, there is no way for Bob to prove he had been scammed.

Using the same public key for both the "blackout transaction" output, and as documentation to be the "owner" of the statecoin would be one way to address the above issue. This issue could also be addressed by having the output address of the "blackout transaction" and the nLockTime expiration be "signed" and be part of the statechain.

It is possible (with assumptions) using remote attestation and Intel's attestation service. Trust would still be required - but in Intel and their claims about their hardware - instead of the entity running the mercury server. Note that the current version of the wallet does not verify lockbox attestations (but it could do).


The wallet does currently use the same public key for both the blackout/backup transaction output and the statechain signature - and this is the intended rule - so that there should always be a statechain signature from the current owner corresponding to the address of every backout transaction that is co-signed (withdrawal txs require that the destination address is signed by the current owner for this exact reason).

Perhaps I am misunderstanding something. I found this (https://docs.mercurywallet.com/docs/01protocol.html) in the documentation, specifically under the "transfer" section, step 1:
My reading of the above makes me believe the statechain will be signed with one key and the "blackout" transaction will be sent to another key.

Apologies the documentation is out of date.  We realised there were no privacy issue here so are fine with the statechain using the same key as the blackout TX.

Great! That is the last of my concerns. Obviously you will need to earn trust in order for people to be willing to use your service. With that change, I don't believe it would be possible for you to steal money without the end user being able to prove the theft.

It would be a good idea if you could keep documentation up to date (or add date of last update), but like I said before many crypto projects have bad documentation, except maybe Bitcoin.
If we are talking about code updates, I am honestly impressed how often new updates are coming out for Mercury, latest version 0.4.52 (https://github.com/layer2tech/mercury-wallet/releases) was released yesterday.

Now my question for developers @nicosey @tomt1664, and I didn't see anyone asking this before:
- Are there any plans for services/exchanges to support and accept statechains directly, in similar way like LN payments are accepted?

We should have a couple of releases this week. 

We have not spoken to any exchanges, but are open to it.  We have had casual conversations with people in the mining industry about moving BTC around off-chain via a Statechain and also people looking at clearing between entities around statechains.  This was all very exploratory. 

Block Explorer now available

https://explorer.mercurywallet.com/

I checked on YouTube, mercury wallet is very secure for coming days because here is many useful feature which can protect transactions wallet & have lower swap fees !!!!

IS there any modification or upcoming feature available to easily swap any chain like AVAX, Terra and other chain?

No sorry, bitcoin only

Can i get an example about how to use this mercury so that i can use it properly !!!!

https://www.youtube.com/watch?v=9DSvNzTBePY

When someone will make any transaction here, is there need any off- chain signature for UTXO transfer?

If i want to transfer fund from centralize exchange like binance, FTX what's the process ? 

May i hold btc or only can use for swap & transaction ????

Just create a deposit address from the app.

Yes, the wallet works with the server to create the signature.

What is going on here? Has the Mercury Wallet team hired cheap shills to post their fake conversations here or do they have some other agenda? All those questions and answers are fake and the accounts might be controlled by the same person.

firste
mtxvyvtpb
SyedAbdul58
GWFYU
SymphoniesBB
Sathi.rose8866

All the above accounts are registered on January 16, 2020 a few minutes apart. I wouldn't trust anything that comes out of their mouths.   

Looks like many of those accounts are connected and it's easy to see this in their post history showing them post in same topics asking stupid questions.
Mercury wallet have nothing to offer or sell so I am not sure why would they pay for something like this, unless they want to bump up this topic.
If this continues I will report all their post for spam and tag this accounts.

Is there a way to see a rich list and who holds most coins?
I would suggest everyone to use vpn for searching anything on explorer, and read Privacy policy... they can keep IP addresses and personal information as long as they need to.
https://mercurywallet.com/privacy

@nicosey
After we all saw what recently happened with Wasabi wallet and zkSNACKs, my question is can something similar happen with Mercury wallet in future?

Answer to you first question no, there is no way to link the coins

Second question no. 

Our plan is to transition to lightning payments and then make the statecoins themselves blinded.
Please read, https://github.com/commerceblock/mercury/blob/master/doc/fee_on_deposit.md

That would make blacklisting not realistic, however can't predict what could happen.

Having carried the torch I found the wallet pretty easygoing and certainly better looking than some other wallets. Keen to test out the swaps feature in the future ::)

Swaps have been happening.

Check out the explorer

https://explorer.mercurywallet.com/

New approach for improving privacy

https://github.com/commerceblock/mercury/blob/master/doc/merc_blind.md

This will make the server run blind.

Appreciate any feedback

For those interested we now have a telegram group

https://t.me/mercurywallet

Would love to hear from you on this as an article to be published in Bitcoin Magazine send to austin@btcmedia.org if interested.

Hey Austin, I am not actually creator or developer of Mercury wallet, nor I am affiliated with Mercury in any way, so I am not sure what more I could add to Bitcoin Magazine about this topic.
I just love and investigate any Bitcoin related tools that improves privacy, that is how I found about Mercury wallet.
I am not expert in any way and you can find all my mercury related posts in this topic.

Interesting news coming from Mercury wallet, they released Lightweight Bitcoin Lightning Node implementation, called Mercury-Node.
I don't want to be to technical, but they used TypeScript bindings from lightningdevkit, this will make it easier for mobile wallets to run a light non-custodial Lightning node.
They are still working on this implemetation and it's not 100% finished, but this will be a big boost of rMercury wallet LN support.
Everything is released as open source and posted on Mercury github page:
https://github.com/layer2tech/mercury-node

Big unexpected changes for me regarding Mercury wallet.
They are going to discontinue support for Mercury wallet services, and there is 3 months period for that, so you better withdraw and convert statecoins if you still have them.
Good news is that development continues as Bitcoin MPC offchain layer 2 protocol, that is Bitcoin MPN offchain layer.
I am waiting to see new release of Mercury Layer, but anyone interested in Bitcoin privacy can find more information on their website:
https://mercurylayer.com/