Topic: Mercury Wallet -> Mercury Layer - Privacy for Bitcoin - page 3. (Read 1390 times)

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

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]

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. 

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:



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:



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



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



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.

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 

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].}

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:

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.



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

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.

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.

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 that appears to set the nLockTime interval as an integer, and according to the settings file 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 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.

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.

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.

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. 

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.

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.

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.

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

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?

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.