 Show Posts
|
|
Pages: [1]
|
The thing about Mercury is that it doesn't obfuscate the history of the coins you receive, but rather swaps your history for someone else's history, and leaves no traces on the blockchain that this has happened.
Now that makes sense. This is both good and bad. As witcher said, it would help to make Bitcoin's transparency a less reiable source of information. Ideally. But realistically, if I swap my 'clean' history for a 'tainted' one, I may now be falling under other kind of trouble I would not have previously expected. Just imagine you used Mercury and all of the sudden you own the coin of which history is a large hack like Bitfinex. Now that is a BIG red flag on your back you have to get rid of. To me, Coin Joining and Mixing is definitely superior. While swapping history helps turning transparency into a less reliable source of information, Mixing and Coin Joining does much more than that. With any type of coinswap (mercury included), the users themselves will always have proof they they have been involved in a swap - which can be selectively revealed in order to deny ownership of the history - e.g. to law enforcement. The problem is that as the technique is under the radar and not well used, the 'transaction graph heuristic' is still used by chainanalysis, and people want to avoid suspicion attached to any coin history not theirs. But in the current mercury, withdrawal transactions are actually identifiable as mercury withdrawals on-chain (due to the withdrawal fee output). Therefore the anonymity set (on-chain) is all mercury withdrawals of a specific amount. Off-chain, the mercury server will know which coins have been swapped, but will not be able to link the transfer of ownership within swaps due to the blinded zero-link style swap protocol. This blog explains some of this in more detail: https://blog.commerceblock.com/bitcoin-privacy-and-tainting-coinjoins-and-coinswaps-meet-statechains-b0d6c1146a24 |
|
|
|
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 lackout/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). |
|
|
|
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-b0d6c1146a24We 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. |
|
|
|
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/tomt1664There 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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.comThe 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-b0d6c1146a24I don't think dkbit98 is a shill, but I am  |
|
|
|
Hi nicosey. Can you give a quick summary of how this differs from Blockstream's Liquid? Liquid is a permissioned sidechain where you can move Bitcoins into and out of it via a 2-way federated peg. To do this you would send Bitcoins to a special output on the Bitcoin blockchain, and then 'Liquid Bitcoins' would be created and issued to you on the Liquid sidechain - which you can then transact with faster confirmations and more privacy than on the Bitcoin mainchain. You must trust the block-signing federation to not collude to double-spend against you on the sidechain by creating more than one version on the chain (this is prevented in Bitcoin with PoW mining). The mainstay concept is nothing to do with 2-way pegging, but is designed to remove the trust required in the block-signing federation - it transfers the trustless immutability of the Bitcoin blockchain to the sidechain. It secures the sidechain in a similar way to merge-mining, but without requiring the cooperation or permission of Bitcoin miners. There is nothing stopping Liquid, or any other sidechain, from using this method to secure the chain. |
|
|
|
This could be a really powerful feature for sidechains - the benefits of merge mining but without needing Bitcoin miners to do anything. But if I understood it right, someone or a group needs to keep paying the Bitcoin to keep it going. Who would pay if the sidechain is decentralised? (like with proof of work or proof of stake) If the sidechain is federated, then the block-signing federation is responsible for funding the Bitcoin staychain - and the Bitcoin staychain can be run with the same multisig script for signing sidechain blocks (we show in the paper how you can verify a pay-to-contract homomorphic commitment via a multisig redeem script). For a fully decentralised/permissionless sidechain, it would be possible to incorporate SPV proofs of Bitcoin staychain transactions into the block reward policy of the sidechain: in this way sidechain miners would be incentivised to fund the Bitcoin staychain in order to gain block rewards on the sidechain. The details of this would need to be worked out though. |
|
|
|
Also from the whitepaper it sounds a lot like a variant of merged mining. Basically, as far as I understand, you build a federated sidechain and use a commitment just like the one from merged mining to link the blocks back to Bitcoin's chain. What am I missing?
There are similarities with the merge mining, in that an alt chain can get the benefit from Bitcoin's proof-of-work, but the concept is quite different. This doesn't require the involvement of Bitcoin miners due to attestations (of the alt chain state) being made to a 'subchain' or 'staychain' of transactions on Bitcoin. By committing to this staychain from the genesis block of the alt chain, the alt chain cannot fork. Note that you cannot get this guarantee by just making unlinked timestamped commitments (in any transaction) to Bitcoin. You get the same properties from a merge mined sidechain, but miners don't have to cooperate. Also, by using a homomorphic commitment scheme, less burden is placed on the Bitcoin chain and attestations have greater privacy and censorship resistance. |
|
|
|
|
