Hello,
I am CTO of Commerceblock, and have been designing and building mercury layer statechains last couple of years.
Ask me anything about the tech, cryptography, use cases etc. or anything else.
pull down to refresh
pull down to refresh
Hello,
I am CTO of Commerceblock, and have been designing and building mercury layer statechains last couple of years.
Ask me anything about the tech, cryptography, use cases etc. or anything else.
How can state chain operators like mercury defend themselves from a nation state attack. What stops the government from just shutting down the server.
One of the main motivations for the development of mercury layer (from the original mercury statechains) is the fact that the operator is blinded: they don't and cannot know anything about the coins (or even if they are coins) - it just stores key shares and updates them in accordance with the protocol.
This does put the operator in a very good legal position as opposed to say, a custodian. But ultimately there is nothing stopping a government from doing whatever they want - and could make such a thing illegal (but IMO this would be like making cloud providers and KMS illegal).
But crucially, even if the operator gets shut down, all owners get their coins after a timelock with the backup transaction.
This is the same as any statechain, right? And what differentiates it from a sidechain?
Mercury is the only statechain implimentation as far as I am aware.
The difference with a sidechain (like Liquid or RSK) is that you only verify the chain of signatures for the one coin (instead of all coins), it is not custodial and there is a unilateral exit (backup tx).
Can you go over how we can use state chains to help people onboard to lightning in a smoother way? How can an LSP use it to make their services better etc.
ELI5
There are several possibilities. One is that you could use a statechain to send someone a pre-funded channel off-chain (so instantly usable). Another possibility is that different LSPs could use it to rebalance channels to manage liquidity better, without having to go on-chain.
So in the first case, the statechain would act as a Layer 2, with Lightning as more of a Layer 3; And the second case, Lightning and the statechain are sort-of inter-operable Layer 2s?
Yes, king of. LN would still be as it is, but a channel would be opened on top of a statechain. Second case, yes - it is just part of the process of rebalancing without needing to go on-chain.
I've read thru the website and although much of the math / crypto goes over my head, I understand the principle of it and appreciate it.
A few questions:
The backup transactions have an absolute timelock - so there is no way a previous owner can broadcast before the timelock. If the operator is shut down, the owner needs to be online when the timelock becomes valid.
Thanks for the reply:
So appox how many blocks is the timelock?
It is up to the user (the server can't enforce or see) but clients will use a default value.
For a long lifetime coin, this should be months.
For the DIFFERENCE on transfer:
It needs to be long enough to get the backup confirmed in that time. Assuming a CPFP to bump fees to the required fast confirmation level, this can be a short as a few hours.
However this becomes less secure for low value coins (where fees might be high in the future).
I've had a look at mercurylayer.com but have to admit that I don't have the technical chops to grasp the overview. Do you know where I can find a less technical overview of the protocol?
Or can you give us the ELI5?
This is quite good: https://bitcoinmagazine.com/technical/mercury-layer-a-massive-improvement-on-statechains
But as a quick ELI5-ish:
An address (public key) is created from two private key shares - one from the server/operator and one from the owner. Bitcoin deposited to this address is the 'statecoin' - it can only be spent with a signature generated from both the server and owner cooperating.
The server and owner cooperate to sign a 'backup transaction' spending the BTC to an address of the owner, which will become valid after a future timelock. So if the server disappears, the owner will still get their money back.
To send the statecoin to a new owner (receiver), the current owner gets the public key of the new owner (this is the mercury address). They then sign a new backup transaction paying to the new owners pubkey, but with a timelock that expires some time sooner than the first one (so it becomes valid sooner). They then get an encrypted random number from the server, and add their private key to it. They send this and data about all previous signatures and backup txs to the receiver (they don't have to send directly, can relay via the server an encrypted blob).
The receiver then verifies all previous signatures and backup txs, and check this matches the number of signatures the server reports it has previously co-signed for this shared key. They add their private key to the encrypted key value and send back to the server.
The server then updates it's private key share with this blinded key value. The server private key share now only combines with the new owner private key share to be able to co-sign for the statecoin pubkey (which doesn't change). The old owners private key share isn't valid any more - and no-one has learnt the full private key at any point.
So long as the server:
The transfer has then completed off-chain and completely privately.
Here's how I understand it right now:
I make an onchain transaction to a new address that has the following properties:
Is this how it works?
Yes - pretty much. With the addition that at each point, the current owner has a backup to go back on chain of the coordinator (server) is shut down.
Fantastic breakdown
Former mercury wallet use here. This was my favorite way to gain some privacy on my KYC coins.
I was excited to see mercury layer launch but it was only CLI. If I had all the time in the world I would use the CLI tool but unfortunately I don’t. Will the team develop GUI to make it easy for normies to swap and improve our privacy?
Thanks! Love the team and the product
Cool - thanks.
We are working on a GUI wallet for desktop and android (and then later on ios) - should be ready for in a month or two. Swapping will work a bit differently and be peer-to-peer. With the blinded server only a single swap is required for complete privacy.
Cool!
From a practical standpoint: How quickly can transactions be done? Instant?
Effectively instant. Each send requires 3 rounds (3 server calls by the client) and negligible computation. This is a few hundred milliseconds over clearnet, a couple seconds over Tor.
Receive is only 2 calls, but you have to verify the full chain of signatures, but still less than a second.
How far are you willing to go calling mercury a non custodial solution? We just have to trust:
Is that accurate? Does that still fit your definition of non custodial?
I will say it is definitely 'not' custodial, IF the server is honest. I recognise that in the world of bitcoin the word 'non-custodial' has a specific meaning - so that why we usually use 'proactively non-custodial' - if the server has been proactive (i.e. honest in the past) it has no ability to steal in the present.
It is certainly non-custodial from a legal/regulatory perspective.
But we are very explicit about the trust model. Regarding SGX, this is layered below that fundamental trust. There are many protocols that rely entirely on SGX (i.e. it is the only line of defence) - this is risky IMO: we know it can be compromised (with difficulty).
We are using it as an additional layer to secure our deployed service, like how any company (e.g. Liquid) uses HSMs.
Is this accurate? can you not push updates to the code that runs on SGX once it's deployed?
By being 'proactive' I mean that the present owner cannot be stolen from if the server deleted the (all) previous owners keys (in the past).
Even if we updated the code (in the present), there is no way to get old key shares (from the past).
This does not protect against a 'proactive' theft/collusion, where the operator and a previous owner conspire to steal from you (a new owner). This requires trust.
However, the blinded nature of the server make this collusion more difficult.
I'm sure it's outside the scope of this project, but is it possible to "prove" a particular version of a software is being run (if you know)?
The principle (in theory) of SGX remote attestation is that you can verify that a specific value (e.g. a cryptographic key) has been produced in an enclave running a specified code. The attestation that this code is running in the enclave is called a 'quote' and is signed with a key unique to that CPU. You can then use Intel's attestation service to verify its a genuine enclave.
There are lots of caveats to this though, and you must trust intel (and also there are privacy issues using intel's service).
Is there any upgrade to Bitcoin that could make it possible to do this without centralized permissioned servers and the single point of "failure"? Can multiparty computation, sharding, federation, or any other technique be used to split up the private key, remove the need for a single trusted server, and remove the need for the special chip?
To be honest, this is AMAZING work, but without that, I see this as just another in a growing number of "tools in the toolbox," without really being the end-all way to scale.
For SGX related issues you may want to check out https://github.com/inclavare-containers/inclavare-containers
Its basically ability to run protected containers in hardware-assisted Trusted Execution Environment (TEE).
dbrbebdbsvgcexhdhehhhrbd
What is the revenue model for Commerceblock, as the operator of the Mercury Layer service?
For mainnet there will be a fee to create a shared key (i.e. deposit a coin) which can be paid via LN. After that all transfers are free. This is similar to an opendime, where you buy the device initially and then all other use is free.
So presumably a marketplace or wallet would offer the ability to get into the Mercury layer directly from fiat, with a fee or spread? (From the user point of view)
If so, this essentially allows people to buy non-KYC and then transfer to their on-chain wallet...
Someone could do that (direct from fiat with the fee included). Not sure who could offer that without KYC though.
What do you think about using mercury layer to "consolodate" UTXO'S? What I mean is for example a swap between 5x 1m sat for a 1x 5m sat UTXO
I hope he comes back to answer, because I'm very interested.
One thing though-- the "safety" mechanism for unilateral exit (you to get your Bitcoin back if you don't trust the statechain) is an HTLC that would create a transaction on the blockchain. So it may be that your exit destroys the dust you were trying to consolidate (or rather, it all goes to fees).
deleted by author
How were you able to fund mercury layer? Grants? Your own investments? Investors?
investors and income from previous projects.
Any opinion on spiderchain?
Can you compare to Ark? Even just a broad mechanistic comparison.
Ark is in principle trustless, while mercury layer is not.
Both operate with fixed value coins, and have timelock based lifetimes.
Arc requires capitalisation for each transfer, so if a 1 BTC coin is going to be transferred 100 times, the ASP needs to lock up 100 BTC.
Will any OPcodes enhance it? covenants/vault/OP_CAT etc
APO and CTV (with LN stuff) could
In your opinion what are the best resources to learn about the mercury layer?
Looking for something that isn't too technical, but also something that isn't so abstract that turns out to be meaningless.
this is good resource https://bitcoinmagazine.com/technical/mercury-layer-a-massive-improvement-on-statechains
Otherwise come chat in telegram group: https://t.me/mercury_layer
What use cases do you forsee? Will it support lighting? Because for what I understand in Mercury we can only send full utxos.
This is the major limitation (only sending full UTXOs) which makes it not a great solution for general, or retail, payments. You could imagine a change/swapping feature (like paying for things in cash, using different denomination coins and getting change) - but the UTXO model doesn't work well for small amounts in a high fee environment.
The whole UTXO model does lend itself to some use cases though - the first was coinswaps for privacy. Others are things like gift cards, casino chips (for online gambling maybe). Also (bit controversial) NFTs and ordinals - at least these could be transferred off-chain (reducing on-chain bloat).
Unlike LN, there are no inbound or routing liquidity issues and large amounts can be sent to anyone instantly. So one possibility is wallets that handle both LN and mercury - payments could automatically be made in a combination with the bulk that that's too big for LN sent via mercury fixed values and the remainder with LN.
What about sending a single large UTXO to multiple Mercury statechain addresses, broken down into denominations, e.g.:
1.2M sat UTXO (or whatever > 1.2 M if also including a change address) sent to multiple addresses with the following amounts (in sats)
10,000 20,000 40,000 80,000 160,000 320,000 640,000 ------- 1.27M sat totalOr some other combination totaling
<whatever>
Then you have multiple denominations on the statechain to spend in a more retail-like setting that together can add up to any desired amount (within the nearest<smallest denomination>
). If enough people have done this, we don't need small UTXOs that exist 1:1 with small UTXOs on main chain.Question: does the protocol allow for initial injection of a single UTXO on main chain into multiple statecoins?
In order to be able to transfer the key and provide the backup, currently the whole UTXO must be transferred.
You could split a utxo into a backup with more than one output, but then if each one gets transferred separately, you have to start creating a chain of backup transactions that would get bigger and bigger.