Mercury Wallet -> Mercury Layer - Privacy for Bitcoin

[o_e_l_e_o]

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

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.

Each time a statecoin is transferred, the backup transaction used in the event the SE becomes uncooperative has the nLockTime value decline by one.

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.

Additionally, the transfer can incorporate the cooperative signing of a new backup transaction paying to an address controlled by Owner 2 which can be confirmed after an nLocktime block height, which is shortened (by an accepted confirmation interval) from the previous owners backup transaction nLocktime.

[1715236154]

1715236154

[1715236154]

1715236154

[1715236154]

1715236154

[dkbit98]

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.

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

I suppose the next question is what fees are Mercury going to be taking for running this service?

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.

[Quickseller]

Each time a statecoin is transferred, the backup transaction used in the event the SE becomes uncooperative has the nLockTime value decline by one.

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.

Additionally, the transfer can incorporate the cooperative signing of a new backup transaction paying to an address controlled by Owner 2 which can be confirmed after an nLocktime block height, which is shortened (by an accepted confirmation interval) from the previous owners backup transaction nLocktime.

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 lower transaction costs and liquidity provided by third parties, but that benefits the service more than the users.

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.

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

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.

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.

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.

[suchmoon]

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.

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.

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:

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

No I am not associated with them in away way

You kept making shit up:

There is also the concern that dkbit98 is shilling for this wallet while falsely saying he is not.

Also this:

there does not appear to be any mechanism for Bob to prevent his wallet from using Alice's known dishonest server.

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.

[o_e_l_e_o]

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.

[dkbit98]

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.



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

[DireWolfM14]

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:

The internal transfer function lets you send funds between two Binance accounts. It will be immediately credited, and you don’t have to pay any transaction fees.

[SFR10]

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

[dkbit98]

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

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 

[o_e_l_e_o]

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:

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?

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.

[Quickseller]

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. 

[nicosey]

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.

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

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.

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.

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

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.

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.

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]

[tomt1664]

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.

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

[nicosey]

From my understanding, it is trivial to create an arbitrary number of Mercury servers, any of which could be acting evil.

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?

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.

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.

[tomt1664]

Each time a statecoin is transferred, the backup transaction used in the event the SE becomes uncooperative has the nLockTime value decline by one.

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.

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 server enforces this. You must trust it to do so.

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.

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.

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.

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.

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.

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.

[dkbit98]

but I am

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.

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.

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.

[tomt1664]

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:

The internal transfer function lets you send funds between two Binance accounts. It will be immediately credited, and you don’t have to pay any transaction fees.

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.

[nicosey]

but I am

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.

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.

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.

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

[tomt1664]

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.

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

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.

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.

[o_e_l_e_o]

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

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.