Mercury Wallet -> Mercury Layer - Privacy for Bitcoin

[nicosey]

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.

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

[tomt1664]

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.

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.

[dkbit98]

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.

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.

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?

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.

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

[nicosey]

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.

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.

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?

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.

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.

[Quickseller]

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.

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.

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.

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.

[tomt1664]

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

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

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.

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

[Quickseller]

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.

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 in the documentation, specifically under the "transfer" section, step 1:

The receiver (Owner 2) generates a backup private key b2 and a statechain (proof) private key c2 (separate keys are used for privacy). They then compute the corresponding public keys B2 = b2.G and C2 = c2.G.

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.

[nicosey]

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.

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 in the documentation, specifically under the "transfer" section, step 1:

The receiver (Owner 2) generates a backup private key b2 and a statechain (proof) private key c2 (separate keys are used for privacy). They then compute the corresponding public keys B2 = b2.G and C2 = c2.G.

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.

[Quickseller]

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.

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 in the documentation, specifically under the "transfer" section, step 1:

The receiver (Owner 2) generates a backup private key b2 and a statechain (proof) private key c2 (separate keys are used for privacy). They then compute the corresponding public keys B2 = b2.G and C2 = c2.G.

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.

[dkbit98]

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.

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

[nicosey]

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.

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

[nicosey]

Block Explorer now available

https://explorer.mercurywallet.com/

[firste]

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

[mtxvyvtpb]

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

[nicosey]

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

No sorry, bitcoin only

[SyedAbdul58]

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

[nicosey]

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

[GWFYU]

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

[SymphoniesBB]

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

[Sathi.rose8866]

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