|
| 1 | +Non-interactive Threshold Escrow (NITE) |
| 2 | +--- |
| 3 | + |
| 4 | +Threshold Schnorr signatures are [complicated](https://www.youtube.com/watch?v=Wy5jpgmmqAg). |
| 5 | +Although taproot allows creating threshold policies using the script tree, threshold signatures are very useful because they can be key-spent and are therefore cheaper and more fungible. |
| 6 | +One of the main practical challenges of threshold Schnorr signatures is that they require multiple rounds of secure broadcast (for example [FROST](https://eprint.iacr.org/2020/852)). |
| 7 | +Moreover, often you do not want to contact the parties unless there is a dispute. |
| 8 | +One such scenario is escrow, where there are three parties, buyer, seller and the escrow. |
| 9 | +They can set up a scriptless script 2-of-3 spending policy using threshold Schnorr signatures, but that requires communicating with the escrow at setup time. |
| 10 | + |
| 11 | +This document discusses Non-interactive Threshold Escrow (NITE), which allows instantiating a subset of threshold spending policies without an interactive setup. |
| 12 | +This subset consists of policies that have two types of participants: those who are involved in the setup and those who are not. |
| 13 | +We call the latter *escrows* because they can not sign arbitrary messages but instead are only allowed to release a secret to the party they ruled in favor of. |
| 14 | +By using _verifiable encryption_, buyer and seller are guaranteed that the policy is in place without having to contact the escrows first. |
| 15 | + |
| 16 | +This secret release mechanism is the reason why NITE is not as expressive as regular threshold signatures, because the escrows can only pick among a couple of fixed settlement transactions and are not able to sign a new transaction with one of the other parties. |
| 17 | +On the other hand this allows using NITE to non-interactively set up Lightning Network payments which are conditional on the approval of a threshold (this also requires [multi-hop locks](multi-hop-locks.md)). |
| 18 | + |
| 19 | +The general idea for the escrow setup in Lightning was described by ZmnSCPxj on the [lightning-dev mailing list](https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002028.html). |
| 20 | +This document answers the question of "whether it's possible to make such a proof" and generalizes from a single escrow to a multiple escrows. |
| 21 | + |
| 22 | +Escrow Protocol with Adaptor Signatures |
| 23 | +--- |
| 24 | +Let's have a look at the following example. |
| 25 | +Assume Alice and Bob want to create an output with a scriptless 2-of-3 policy that includes an escrow. |
| 26 | +Depending on some condition `c`, either Alice or Bob are allowed to spend the output. |
| 27 | +If they disagree, the escrow will decide whether Alice or Bob gets the coin. |
| 28 | + |
| 29 | +1. An unsigned funding transaction is created, sending coins to a 2-of-2 MuSig output between Alice and Bob. |
| 30 | +2. Alice draws a scalar `t_A` uniformly at random, sends Bob an adaptor signature with adaptor `t_A*G` of a transaction sending the funding output to Bob. Alice also sends Bob a ciphertext which contains `t_A` encrypted to the escrows public key `E` pay-to-contract-tweaked as `E_c = E + hash(E, c)G`. |
| 31 | +3. Bob does step 2 vice versa with adaptor secret `t_B`. |
| 32 | +4. Both Alice and Bob send the ciphertext and the contract `c` to the escrow and ask if it decrypts to the DLog of `T_A = t_A*G` and `T_B = t_B*G` respectively. |
| 33 | +5. If so, the funding tx is signed and broadcasted. |
| 34 | + |
| 35 | +Now if there's no dispute they can spend their 2-of-2 output however they want. |
| 36 | +If they can't agree on an outcome, either party can contact the escrow and ask for the adaptor secret, which would allow either of them to complete the adaptor signature and broadcast the settlement transaction. |
| 37 | + |
| 38 | +Non-interactive Setup |
| 39 | +--- |
| 40 | + |
| 41 | +The problem with above protocol is step 4. |
| 42 | +Not only does it require interaction with the escrow even if there's no dispute, but it also requires revealing the contract (It may be possible to avoid the latter issue but note that the protocol must ensure that the escrow is not tricked into decrypting under anything but Alice and Bob's shared contract conditions). |
| 43 | +In order to get rid of step 4, Alice and Bob use *verifiable encryption*, i.e., they create a non-interactive zero-knowledge proof to convince the other party that the ciphertext really is their adaptor secret encrypted to the tweaked escrow key. |
| 44 | +Only if there is a dispute, Alice or Bob send their received ciphertext and the contract `c` to the escrow, who derives `E_c`, decrypts and returns the adaptor secret under the contracts conditions. |
| 45 | + |
| 46 | +Verifiable Encryption |
| 47 | +--- |
| 48 | +The [classic scheme](https://link.springer.com/content/pdf/10.1007/978-3-540-45146-4_8.pdf) for verifiable encryption of discrete logarithms can not be applied to secp256k1 adaptors because it only allows verification of specially constructed groups. |
| 49 | +As of 2020-09 there are two promising ways to verifiably encrypt secp256k1 discrete logarithms: Purify and Juggling. |
| 50 | + |
| 51 | +[Purify](https://eprint.iacr.org/2020/1057) was originally invented to create a MuSig protocol with deterministic nonces (DN). |
| 52 | +This requires each signer to prove in zero knowledge that its own nonce contribution is the result of correctly applying a pseudo-random function (PRF) to the public keys and the message. |
| 53 | +The Purify PRF can be efficiently implemented in an arithmetic circuit for the [Bulletproof](https://eprint.iacr.org/2017/1066.pdf) zero knowledge protocol. |
| 54 | +As shown in the ["Further Applications"](https://eprint.iacr.org/2020/1057) section, the same techniques can be used to create a verifiable encryption scheme for discrete logarithms on secp256k1. |
| 55 | +There are [python scripts](https://github.com/sipa/purify) to generate Purify arithmetic circuits as well as an [experimental branch of libsecp256k1-zkp](https://github.com/jonasnick/secp256k1-zkp/tree/bulletproof-musig-dn-benches) that uses Bulletproofs to prove and verify these arithmetic circuits in zero-knowledge. |
| 56 | + |
| 57 | +Roughly speaking, encryption with [Juggling](https://arxiv.org/pdf/2007.14423v1.pdf) works by first splitting up the discrete logarithm `x` into multiple segments `x_k` of length `l` such that `x = sum_k 2^(kl) x_k`, then ElGamal-encrypt `x_k * G` to `Y` as `{ D_k, E_k } = { x_k*G + r_k*Y, r_k*G }`. |
| 58 | +For every segment the encryptor creates a rangeproof showing that `D_k` is a Pedersen commitment and that the value is smaller than `2^l`. |
| 59 | +Then the encryptor runs a sigma protocol showing that `{ sum D_k, sum E_k }` is a correct encryption of `x*G`. |
| 60 | +Decryption happens by ElGamal-decrypting every `x_k * G` from `{ D_k, E_k }` and then determining `x_k` (which is in `[0, 2^l)`) by brute force. |
| 61 | +Juggling is [implemented](https://github.com/ZenGo-X/JugglingSwap) as part of JugglingSwap which allows cross-chain and cross-curve atomic swaps. |
| 62 | + |
| 63 | +Juggling is conceptually simpler than executing a PRF inside a bulletproof as in Purify. |
| 64 | +Other than that, there are minor differences in proof size, proving and verification time. |
| 65 | + |
| 66 | + |
| 67 | +Threshold Escrow |
| 68 | +--- |
| 69 | + |
| 70 | +It is straightforward to replace the single escrows in Alice and Bob's setup with multiple escrows. |
| 71 | +For example, they can have a policy such as |
| 72 | + |
| 73 | +``` |
| 74 | +(Alice AND Bob) or ((Alice or Bob) and (2 of escrow1, escrow2, escrow3)) |
| 75 | +``` |
| 76 | + |
| 77 | +We can write `(2 of escrow1, escrow2, escrow3))` in disjunctive normal form as `(escrow1 AND escrow2) OR (escrow2 AND escrow3) OR (escrow1 AND escrow3)`. |
| 78 | +Now Alice generates three random scalars `l_1`, `l_2` and `l_3` and uses her adaptor secret `t_A` to compute `r_1 = t_A - l_1`, `r_2 = t_A - l_2`, `r_3 = t_A - l_3`. |
| 79 | +Then she verifiably encrypts `l_1` and `l_3` to escrow1, `r_1` and `l_2` to escrow2, `r_2` and `r_3` to escrow3 and sends the ciphertexts along with `l_1*G, r_1*G, l_2*G, r_2*G, l_3*G, r_3*G` to Bob. |
| 80 | +Bob checks that `l_i*G + r_i*G = t_A*G` and verifies that the ciphertexts really decrypt to `l_i` and `r_i`. |
| 81 | +We can extend this method of sharing the adaptor secret to any monotone boolean function of escrows. |
| 82 | + |
| 83 | +NITE can also be used for more active parties than just Alice and Bob. |
| 84 | +For a policy like `(Alice AND Bob AND Carol) OR (Alice AND escrow) OR (Bob AND escrow) OR (Carol AND escrow)`, Alice, Bob and Carol would set up a funding transaction with a 3-of-3 MuSig output. |
| 85 | +Then they would send one adaptor signature and the adaptor secret encrypted to the escrow to everyone else. |
| 86 | + |
| 87 | +Non-binary outcomes |
| 88 | +--- |
| 89 | + |
| 90 | +Above we considered the case where after setup Alice and Bob each have a single settlement transaction with an adaptor signature from the other party. |
| 91 | +It's easy to extend this to more outcomes, but a limitation of NITE is that the number of possible outcomes must not be too big, because they must be determined and adaptor signatures exchanged before the dispute can happen. |
| 92 | +This means for example that NITE can not be applied to every [Smart Contract Unchained](https://zmnscpxj.github.io/bitcoin/unchained.html). |
0 commit comments