Adaptor signature on Schnorr -Lightning Network-
Adaptor signature series
1.Adaptor signature -Schnorr signature and ECDSA-
2.Adaptor signature on Schnorr -Cross chain atomic swap-
3.Adaptor signature on Schnorr -Lightning Network-
4.Adaptor signature on ECDSA
5.Adaptor signature in Discreet Log Contracts on ECDSA
As part of the series on Adaptor signature, the previous chapter explained how Schnorr Adaptor signatures work in cross chain atomic swaps. In this chapter, we will talk about how Schnorr Adaptor signatures can be used in the Lightning Network.
- Lightning Network using secret hashes
In the above example, Alice pays 1.0 BTC to Daniel via Bob and Carol. Alice first receives the hash of a secret value from Daniel and locks the payment + fee (1.2 BTC in this example) to the adjacent hop (Bob in this example). The hash received from Daniel is used for locking so that Bob is only able to obtain the 1.2BTC by revealing the secret value that was used by Daniel to generate the hash. Intermediate hops lock each payment in a similar way. Once Carol has locked the 1BTC using the hash, Daniel can reveal the secret value and receive the 1BTC. Carol can do the same with Bob and Bob with Alice.
The downside of this approach is that secrets may appear on the blockchain if a channel is closed unilaterally, in which case a third party will be able to link payments between Alice and Daniel.
2.Wormhole attack with secret hashes
Another potential issue with LN payment using secret hash values is the so-called “wormhole attack”. Consider the case where Alice pays Ellen through Bob, Carol and Denise, but Bob and Daniel collude by exchanging the secret “out-of-band” to steal the fees from Carol:
Ellen receives 1.0 BTC by revealing the secret to Daniel after all the funds have been locked
- Daniel does not reveal the secret to Carol, and after a certain period of time, Carol’s payment to Daniel will fail
- Bob’s payment to Carol will also eventually fail because Carol cannot reveal the secret
- Bob knows the secret because he is colluding with Daniel, and gets 1.3 BTC by revealing the secret to Alice.
This allows Bob and Daniel to receive the fees that were intended for Carol. Note that neither Alice nor Ellen is aware of the attack because both payments succeed.
3.Lightning Network using Adaptor signatures
We learned that payments on the current Lightning Network using a common secret can lead to privacy issues, and that fees can be stolen through the collusion of intermediate hops. These problems can be solved using Schnorr Adaptor signatures.
For this application, we will use Schnorr adaptor signatures constructed using “Public key tweaking” as described in the first chapter. (See Adaptor signature -Schnorr signature and ECDSA- for more information)
We will first talk about simple payments from Alice to Bob without middle hop, and then discuss paying from Alice to Carol over an intermediate hop.
3–1.Payment between Alice and Bob using adaptor signature (no middle hop)
Both Alice and Bob exchange public points for which they know the secret value, and create a common public key (using the MuSig protocol). Alice locks 1BTC in a transaction that can be unlocked using the private key associated with that common public key. Alice then creates an adaptor signature for the transaction input which is valid for her part of the common public key. Bob verifies it, creates a similar adaptor signature using his part and adds the two adaptor signatures and gives that to Alice. Alice verifies it and gives her secret value to Bob which can now decrypt the signature and unlock the 1BTC. Of course as we are in the Lightning Network, in practice the two parties just agree to create a new commitment transaction and revoke the previously built transaction. After this, Bob can give Alice his secret as a proof of payment. Below is a more detailed description of the steps involved in this protocol:
- Alice receives TB from Bob (included in the invoice) and shares TA with Bob.
2.Alice creates parameters R, P (P is created using Mu-sig) with Bob and locks her 1BTC in a P2WPKH output using P
3.Alice creates an Adaptor Schnorr signature SA’ and passes it to Bob
4.Bob verifies the Adaptor Schnorr signature from Alice, creates another adaptor signature using his private key and sends back the sum of the two adaptor signatures to Alice.
5.Alice verifies the summed Adaptor Schnorr signature and gives tA to Bob
6.Bob decrypts the summed Adaptor Schnorr signature and unlock Alice’s payment
7.Alice can obtain tB from sAB and sAB’ , which serves as a proof of payment.
3–2.Payment via a middle hop
The payment protocol from Alice to Carol via a middle hop is similar to the one described above. Alice, Bob, and Carol each hold a secret value, and they work together to create and add up their respective Adaptor signatures. The Adaptor signature is decrypted by adding the secret values that each holds.
When Carol publishes with a secret value and gets a payment from Bob, Bob gets the secret value and gets a payment from Alice.
1.(A⇔B⇔C) Alice receives TC from Carol (included in her invoice) and each party generates and shares secret values as follows.
2–1.(A⇔B) Alice creates parameters P, R (P is created using Mu-sig) with Bob and locks her 1.1BTC in a P2WPKH output using PAB
2–2.(B⇔C) Bob creates parameters P, R (P is created using Mu-sig) with Carol and locks his 1BTC in a P2WPKH output using PBC
-omited-
3–1.(A⇔B) Alice creates an Adaptor Schnorr signature and pass it to Bob
3–2.(A⇔B) Bob verifies the Adaptor Schnorr signature from Alice, creates another adaptor signature using his private key and sends back the sum of the two adaptor signatures to Alice.
4–1.(B⇔C) Bob creates an Adaptor Schnorr signature and pass it to Carol
-omited-
4–2.(B⇔C) Carol verifies the Adaptor Schnorr signature from Bob, creates another adaptor signature using her private key and sends back the sum of the two adaptor signatures to Bob
-omited-
5–1.(A⇔B) Alice verifies the Adaptor Schnorr signature from Bob and sends an ACK to Bob
5–2.(B⇔C) Bob verifies Adaptor Schnorr multi signature from Carol and sends an ACK to Carol
-omited-
6.(A⇔C) Carol sends an ACK to Alice, and then Alice sends tA+tB to Carol
7–1.(B⇔C) Carol decrypts the Adaptor Schnorr signature and unlock Bob’s payment
7–2.(A⇔B) Bob got tA+tC from sBC and sBC’ , which decrypts Adaptor Schnorr signature sBC’ (thus unlock Alice’s payment)
9.Alice got tC from sAB and sAB’ , which serves as a proof of payment.
In this way, Lightning Network on Schnorr signature uses an Adaptor signature based on elliptic curve points instead of secret hashes to enable payments that cannot be linked between hops. It also prevents the wormhole attack.
This concludes the chapter on Lightning Network using Schnorr Adaptor signatures. Next time, we will talk about Adaptor signatures on ECDSA.
Reference:
Scriptless Scripts(May. 2017,Andrew Poelstra)
Simple Schnorr Multi-Signatures with Applications to Bitcoin (2018,Gregory Maxwell, Andrew Poelstra, Yannick Seurin2,Pieter Wuille)
Anonymous Multi-Hop Locks(Apr. 2018,Pedro Moreno-Sanchez, Aniket Kate)
