Topic: Mercury Wallet -> Mercury Layer - Privacy for Bitcoin - page 2. (Read 1453 times)
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 !!!!
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.
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?
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 b
Quote
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.
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 b
Quote
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.
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 b
Quote
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. 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 b
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.
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.
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.
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.
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?
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.
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.
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?
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?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.
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.
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.
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.
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.
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.
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.
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...
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:
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.
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.
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.
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 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.
Jump to: