Is there a way to see a rich list and who holds most coins? I would suggest everyone to use vpn for searching anything on explorer, and read Privacy policy... they can keep IP addresses and personal information as long as they need to. https://mercurywallet.com/privacy@nicosey After we all saw what recently happened with Wasabi wallet and zkSNACKs, my question is can something similar happen with Mercury wallet in future? Answer to you first question no, there is no way to link the coins Second question no. Our plan is to transition to lightning payments and then make the statecoins themselves blinded. Please read, https://github.com/commerceblock/mercury/blob/master/doc/fee_on_deposit.mdThat would make blacklisting not realistic, however can't predict what could happen. |
|
|
|
When someone will make any transaction here, is there need any off- chain signature for UTXO transfer?
Yes, the wallet works with the server to create the signature. |
|
|
|
If i want to transfer fund from centralize exchange like binance, FTX what's the process ?
Just create a deposit address from the app. |
|
|
|
IS there any modification or upcoming feature available to easily swap any chain like AVAX, Terra and other chain?
No sorry, bitcoin only |
|
|
|
|
Hello,
Bitcoin Wiki Username: 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. |
|
|
|
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). 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. |
|
|
|
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. |
|
|
|
|
Show Posts
