24
Schnorr and Taproot in Lightning 2018-09-01 Jonas Nick [email protected] https://nickler.ninja @n1ckler

Schnorr and Taproot in Lightning - GitHub Pages · OP_CHECKMULTISIG . Merkleized Abstract Syntax Trees (MAST) MAST usage is revealed to blockchain observers data overhead because

  • Upload
    others

  • View
    9

  • Download
    2

Embed Size (px)

Citation preview

Schnorr and Taproot in Lightning

2018-09-01 Jonas Nick [email protected] https://nickler.ninja @n1ckler

Objective: Increase Robustness● Privacy● Scalability● Consensus

Scriptless Scripts approach: different payment types (multisig, lightning channels, etc) should look like normal payments.

1. Participants communicate directly2. That results in a simple transaction (“Alice pays Bob”)

Introduction: bitcoins

2Alice & hash lockOR Bob after 144 blocks

1Alice

1Alice & Bob

Alices signature,Bob’s signature

Alice’s signatureAlices signature,Hash preimage

Bitcoin Scripts

Script Witness

<pubkey> OP_CHECKSIGVERIFY

<signature>

2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIGVERIFY

<signature1> <signature2>

Schnorr Signatures● Currently: Elliptic Curve Digital Signature Algorithm (ECDSA)● Schnorr signatures is a different signature scheme that could be used instead ● BIP recently was proposed to standardize them for Bitcoin● No new crypto assumptions, stronger security proof● Efficiently batch verifiable: multiple signature verifications at once are faster

than individually

Schnorr Signatures

Script Witness Meaning

<pubkey> OP_SCHNORR

<signature> ● Normal payment?● k-of-n multisig?● Lightning cooperative

close?● Hash lock?

Size: 32 bytes public key + 64 bytes signature

Add new consensus rule to add Schnorr signature validation to Script

Schnorr Signatures: 2-of-2 MuSig

Alice: Bob:

nonce commitment -> <- nonce commitment nonce -> <- nonce partial sig -> <- partial sig combine combine

1. Create combined public key P from Alice’s key A and Bob’s key BP = hash(A,B,0)*A + hash(A,B,1)*B

2. Interactively sign transaction

Payment Forwarding with Hash Locks

Bob

Charlie

Alice

hash(payment_preimage)

hash(payment_preimage)

Hash Locks

Script Witness Meaning

... <payment_hash> ... <pubkey> OP_CHECKSIG

<payment_preimage> <signature>

Forces spender to reveal the payment preimage which can be used to atomically swap payments.

Locks with Schnorr & Adaptor Signatures

Bob

Hash locks Discrete Log based locks

hash(payment_preimage) payment_preimage*G

“On-chain”: payment_preimage explicit in tx

“Off-chain”: Payment_preimage computable from normal tx signature & adaptor signature

Routing privacy

Allows proof of payment and buying discrete logarithms

CharlieAlicerandom*TT

Locks with Schnorr & Adaptor Signatures

Script Witness Meaning

<pubkey> OP_SCHNORR

<signature> ● Normal payment?● k-of-n multisig?● Lightning cooperative

close?● Hash lock?

Size: 32 bytes public key + 64 bytes signature

Locks with Schnorr & Adaptor Signatures

1Alice & Bob

● Bob knows some secret, Alice wants to know it● They have a 2-of-2 MuSig output● Alice signs a transaction only when it in turn

learns the secret

Main idea: Bob sends Alice adaptor signature before Alice sends partial signature.

secret = adaptor_sig + Alice_partial_sig - combined_sig

Locks with Schnorr & Adaptor Signatures● Bob knows some secret, Alice wants to know it● They have a 2-of-2 MuSig output

1Alice & Bob

Alice: Bob:… exchange nonces …

<- adaptor sig verify adaptor sig partial sig -> partial sign combine

Bob spends coin, Alice computes lock secret as secret = adaptor_sig + Alice_partial_sig - combined_sig

Example: eltoo updates

Script Meaning

OP_IF 2 <A> <B> 2 OP_CHECKMULTISIGOP_ELSE ... OP_CLTV ... 2 <Au> <Bu> 2 OP_CHECKMULTISIGOP_ENDIF

Can be spent either by 2-of-2 of pubkeys A and B or by attaching another update transaction

Merkleized Abstract Syntax Trees (MAST)

root= hash(left branch, right branch)

2 <A> <B> 2 OP_CHECKMULTISIG … OP_CLTV … 2

<Au> <Bu> 2 OP_CHECKMULTISIG

Merkleized Abstract Syntax Trees (MAST)

● MAST usage is revealed to blockchain observers● data overhead because there’s no default branch

Script Witness

root OP_MAST(?) <script> <merkle proof> <witness>

Pay-To-Contract (P2C)● Idea: put commitment to data into a public key● Original use case: allow sender to prove in private what purpose of payment

was○ F.e. address commits to data “this public key is used to buy a hat”

1. Generate normal public key P = x*G2. Create new public key Q from P and C as Q = P + hash(P,C)*G3. Commit to C by putting Q in the blockchain4. Now can

a. Sign for Q because know private key x + hash(P,C)b. Reveal P and C to prove that Q commits to C

Taproot & Schnorr

<public_key> OP_SCHNORR

… OP_CLTV … <update_public_key> OP_SCHNORR

(Commitment with P2C)

Taproot Assumption: Interesting scripts have almost always a logical top level branch that allows satisfaction of the contract with nothing other than a signature by all parties

Taproot & Schnorr

Taproot: Add a new consensus rule that additionally allows spending a coin by proving that the input public key committed to a script and providing the witness for that script.

Taproot & Schnorr

Script Witness Meaning

<pubkey> OP_SCHNORR

<signature> ● … (as before) …

<… OP_CLTV … <update_public_key> OP_SCHNORR> <P> <signature>

● Uncooperative close

Conclusion● Adding Schnorr Signatures to Bitcoin allows cheaper and more private

Lightning channels○ With adaptor signatures cheaper and more private uncooperative closings, routing privacy,

proof of payment

● Adding Taproot to Bitcoin allows cheaper and more private uncooperative channel closings

● Status○ Schnorr standardization BIP in review stage○ Schnorr softfork BIP work-in-progress○ Schnorr/taproot code WIP

References● Schnorr BIP

https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki● MuSig https://eprint.iacr.org/2018/068.pdf● Adaptor Sigs https://eprint.iacr.org/2018/472.pdf● Blind Signatures in Scriptless Scripts https://nickler.ninja/slides/2018-bob.pdf ● Eltoo https://blockstream.com/eltoo.pdf● Taproot

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-January/015614.html

Q&A● slides: https://nickler.ninja/slides/2018-hackday.pdf● questions?