pull down to refresh
355 sats \ 4 replies \ @Scoresby 1 Feb \ on: Mercury layer AMA bitcoin
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:
- Updates their key share (i.e. deletes the old one) there is no way they a previous owner share can be used, even if they hack the server.
- Correctly reports the number of co-signings it has done. Then it is completely non-custodial and secure.
The transfer has then completed off-chain and completely privately.
reply
Here's how I understand it right now:
I make an onchain transaction to a new address that has the following properties:
- The private key of this new address is broken into two chunks.
- I only get to see one of the chunks.
- A coordinator knows the other chunk.
- Neither of us can spend the utxo without both chunks...
- Except, if we collaborate, we can create a new set of key-chunks that have the property that I now don't know any of the chunks of the key and Bob (my intended payee) knows one chunk (while the coordinator still knows one chunk). This is how we have transferred the utxo from me to Bob without an onchain transaction.
Is this how it works?
reply
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.
reply
Fantastic breakdown
reply