Skip to main content

Mercury Layer Protocol

Preliminaries​

The server and each owner are required to generate private keys securely. Owners are required to verify ownership of UTXOs (this can be achieved via a client interface, and requires connection to an Electrum server or fully verifying Bitcoin node). Elliptic curve points (public keys) are depicted as upper case letters, and private keys as lower case letters. Elliptic curve point multiplication (i.e. generation of public keys from private keys) is denoted using the . symbol. The generator point of the elliptic curve standard used (e.g. secp256k1) is denoted as G. All arithmetic operations on secret values (in Zp) are modulo the field the EC standard.

In addition, a public key encryption scheme is required for blinded private key information sent between parties. This should be compatible with the EC keys used for signatures, and ECIES is used. The notation for the use of ECIES operations is as follows: Enc(m,K) denotes the encryption of message m with public key K = k.G and Dec(m,k) denotes the decryption of message m using private key k.

All transactions are created and signed using segregated witness, which enables input transaction IDs to be determined before signing.

Initiation​

A user wants to create a statechain for a specific amount of bitcoin, and they request that the server initialize the process. To begin, the user must provide a valid token_id (UUID), which will be listed in the the server token database. This token_id may be generated by the server on payment of a fee (via a separate lighning or bitcoin payment).

  1. The initiator (Owner 1) generates a private key: o1 (the UTXO private key share) and auth_privkey and auth_pubkey.
  2. Owner 1 then calculates the corresponding public key of the share O1: O1 = o1.G
  3. Owner 1 requests a key share generation from the server with a valid token_id and provides auth_pubkey (which is used to authenticate subsquent communication with the server).
  4. The server then generates a private key: s1, calculates the corresponding public key and sends it to Owner 1: S1 = s1.G along with a statechain_id (UUID). The server then stores s1 indexed with statechain_id.
  5. Owner 1 then adds the public key they receive to their own public key to obtain the shared (aggregated) public key P (which corresponds to a shared private key of p = o1 + s1): P = O1 + S1
  6. Owner 1 creates and broadcasts a funding transaction (Tx0) to pay an amount A to the address corresponding to P. This defines the UTXO TxID:vout (the outpoint).
  7. Owner 1 creates an unsigned backup transaction (Tx1) that pays the P output of Tx0 to address of O1, and sets the nLocktime to the initial future block height h0 (where h0 = cheight + hinit, cheight is the current Bitcoin block height and hinit is the initial locktime specified by the server). The nSequence number is set to zero.
  8. Owner 1 the utilises the server to generate a valid signature on Tx1 as follows:

Signature generation​

To generate a signature on Tx1, the owner first computes the sighash m1. Owner 1 then generates a random ephemeral nonce r2_1 and blinding nonce b1 and computes R2_1 = r2_1.G Owner 1 then requests a partial signature from the server which generates a random r1_1 and computes R1_1 = r1_1.G. R1_1 is returned to Owner 1. Owner 1 then computes R_1 = R1_1 + r2_1.G + b1.P, e1 = SHA256(P||R_1||m1) and c1 = e1 + b1 and sends c1 to the server. The server then computes the partial signature sig1_1 = r1_1 + c1.s1 and sends to Owner 1. Owner 1 computes sig2_1 = r2_1 + c1.o1 and sig_1 = sig1_1 + sig2_1. The full signature (sig_1,R_1) is then added to Tx1.

  1. Tx1 is verified and stored by Owner 1.
  2. The server then adds the public key S1 to the list of current statechain server key shares and publishes.

Key Reassignment​

Owner 1 wishes to transfer the value of the coin A to a new owner (Owner 2). The protocol then proceeds as follows:

Sender​

  1. The receiver (Owner 2) generates a statechain private key share o2. They then compute the corresponding public key O2 = o2.G along with a new auth_pubkey.
  2. O2||auth_pubkey then represents the Owner 2 'address' and is communicated to Owner 1 (or published) in order for them to 'send' the ownership.
  3. Owner 1 then creates a new unsigned backup transaction Tx2 paying the output of Tx0 to address of O2, and sets the nLocktime to h0 - (n-1)*c where c is the confirmation interval and n is the owner number (i.e. 2). The nSequence number is set to zero.
  4. Owner 1 cooperates with server to generate a blind partial signature on Tx2 as follows:

Signature generation​

To generate a signature on Tx2, the owner first computes the sighash m2. Owner 1 then generates a random ephemeral nonce r2_2 and blinding nonce b2 and computes R2_2 = r2_2.G Owner 1 then requests a partial signature from the server which generates a random r1_2 and computes R1_2 = r1_2.G. R1_2 is returned to Owner 1. Owner 1 then computes R_2 = R1_2 + r2_2.G + b2.P, e2 = SHA256(P||R_1||m1) and c2 = e2 + b2 and sends c2 to the server. The server then computes sig1_2 = r1_2 + c2.s1 and sends to Owner 1. Owner 1 computes sig2_2 = r2_2 + c2.o1 and sig_2 = sig1_2 + sig2_2. The full signature (sig_2,R_2) is then added to Tx2.

  1. The server generates a random key x1 and sends it to Owner 1.
  2. Owner 1 then computes the blinded transfer value t1 = o1 + x1.
  3. Owner 1 then concatinates the Tx0 outpoint with the Owner 2 public key (O2) and signs it with their key o1 to generate SC_sig_1.
  4. Owner 1 then create a transfer message containing five objects: a. All previous signed backup transactions: Tx1 and Tx2 b. SC_sig_1 c. t2 d. statechain_id
  5. Owner 1 then encrypts the message with the reciver auth_pubkey and sends to the receiver (can be via server relay).

At this point the Owner 1 has sent all the information required to complete the reassignment to Owner 2 and is no longer involved in the protocol. Owner 2 then verifies the correctness and validity of the objects.

Receiver​

  1. Receiver (owner 2) decrypts the transfer message with their auth_privkey.
  2. Owner 2 verifies that the latest backup transaction pays to O2 and that the input (Tx0) is unspent and pays to P.
  3. Owner 2 takes the list of previous K backup transactions (Txi i=1,...,K) and for each one i verifies: a. The signature is valid. b. The nLocktimes are decremented correctly (i.e. the latest TxK is the lowest). c. The transaction has been constructed exactly according to the sender implimentation. d. That the latest nLocktime is not expired accordning to the current block height.
  4. Owner 2 queries server for 1) The total number of signatures generated for statechain_id: N and 2) Current server public key share: S1.
  5. Owner 2 then verifies that K = N and then O1 + S1 = P

The server key share update then proceeds as follows:

  1. Owner 2 then computes t2 = t1 - o2.
  2. Owner 2 then sends t2 to the server.
  3. The server then updates the private key share s2 = s1 + t2 - x1 = s1 + x1 + o1 - o2 - x1 = s1 + o1 - o2

s2 and o2 are now key the private key shares of P = (s2 + o2).G which remains unchanged (i.e. s2 + o2 = s1 + o1), without anyone having learnt the full private key. Provided the server deletes s1, then there is no way anyone but the current owner (with o2) can spend the output.

  1. The server then adds the public key S2 to the list of active key shares and publishes.

Orderly Closure​

The current owner of a coin can at any time spend the statechain by simply creating a transaction paying to any specified address. The server cannot identify a closure, but the coin can no longer be transferred to a new owner because the server will have produced an additional signature that cannot be verified as a valid backup by a receiver.

Closure proceeds as follows:

  1. The current owner (e.g. Owner 2) creates an unsigned transaction TxW that spends Tx0 to a closure address W.
  2. The owner then co-signs this transaction with the server (as above). TxW is broadcast.
  3. The owner then sends the server a closure notification (with their current statechain_id) that the coin is withdrawn so the server can remove the coin public from the published key share list.

Backup closure​

In the case that the server disappears or does not cooperate with the current owner, the current owner can reclaim their funds to an address they control by submitting their backup transaction when the nLocktime is reached.