We are not aware of anyone else using the code or deploying a server.

The nature of blinded server means that we can't tell if it's being used for mainnet or testnet, but we run two public servers: One 'test' server that isn't secured and gets restarted regularly, and is free to use - we are clear in our docs that no-one should use this server for real money. This gets quite a bit of use.

We also run a 'production' server that is deployed using secured and replicated bare metal hardware - this currently requires a LN fee to use. We were considering this 'production ready' for an app that is being worked on, but it has not been advertised for public use.

So far, the only use of this server has been us testing it - so I believe we can be very confident that there were no user funds at risk.

Also, it seems we published the link to the report on twitter, before he linked it on his homepage in here.

Just to clarify - the report was shared with us via a link to a document which was public accessible, but I don't think was linked from his homepage.

Also this was only shared after an initial discussion where we stated there were no mainnet users, and so it was very unlikely any funds were at risk.

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.

Someone could do that (direct from fiat with the fee included). Not sure who could offer that without KYC though.

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

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.

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.

investors and income from previous projects.

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.

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

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.

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.

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

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.

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.

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

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.

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.