Mass Adoption,

But Decentralized

Is this Bitcoin?

What is Bitcoin?

Resists powerful actors through decentralization

I hope it's obvious it was only the centrally controlled nature of those systems that doomed them. I think this is the first time we're trying a decentralized, non-trust-based system.

- Satoshi

Case Study: Blocksize Increase

  • Bitcoin governance emerges through the software users run on their computers
  • hence, could increase size limit of blocks
  • but this increases cost to run full node

 

After an astounding victory, the small block narrative, that end users had to agree to protocol rule changes, was finally seen as compelling.

 

- Jonathan Bier, The Blocksize War

Instead, make most of existing constraints:

The Taproot Upgrade

Bitcoin Pre-Taproot

Alice

Bob

bc1q... address

bitcoin

Bitcoin Today

Alice

Bob

bc1p... address

bitcoin

with Taproot

Schnorr Sigs in Taproot 

Authorization of Transactions:

In blockchain: ECDSA Schnorr signature of Alice's public key

Alice

Charlie

bitcoin

Schnorr Batch Verification

  • without: full node must verify every signature in blockchain individually
  • with: full node verifies batch of signatures at once
  • example batch = 10,000: verification is twice as fast
  • therefore, full node cost reduced
    • key requirement for principle of resistance
  • status: proof-of-concept implementation exists, Summer of Bitcoin student

Still, on-chain transactions don't scale

Taproot

½ Sig Agg

Sig Agg

Batch Verify

Key Agg

Adaptor Sig

on-chain

off-chain primitives

Layer 2

(Multiparty-) Payment Channels

Sidechains

Federated E-Cash

ROAST

Principles

usability for payments

(on-chain and layer 2)

surveillance resistance

security of wallets

resilience

Indistinguishability

  • transactions that are part of complex protocols look the same as simple payments to an observer
  • makes spying with blockchain more difficult
  • layer 2 (L2) and multisig cheaper

Transaction

Multisig?

Normal Payment?

Sidechain?

Lightning?

Taproot, in short

  • example: coin that can be spent by

    • or(Alice,and(Bob, older(1000))
    • "Alice immediately or Bob  after 1000 blocks"
  • taproot allows hiding unexecuted spending paths
  • if Alice spends the coin, it looks like an ordinary payment

Taproot

½ Sig Agg

Sig Agg

Batch Verify

Key Agg

Adaptor Sig

on-chain

off-chain primitives

Layer 2

(Multiparty-) Payment Channels

Sidechains

Federated E-Cash

ROAST

Multi Sig + Key Aggregation

  • example: Alice, Bob and Charlie have a 2-of-3 multisig wallet
  • without: All three keys and two signatures must be written to the chain
  • with:
    • ​​​one aggregate key
    • cooperatively create single signature
  • therefore, indistinguishable from normal transactions

A

B

C

ABC

MuSig vs MuSig2 vs FROST

  • MuSig: n-of-n multisignatures*
    • status: replaced by MuSig2
  • MuSig2: n-of-n multisignatures*
  • FROST: t-of-n threshold signatures
    • example:  -75% cost of 11-of-15 federation 
    • interactive setup: key shares of other parties need to be backed up securely
    • status: implementation of prototype in progress

*t-of-n with taproot in best case

MuSig2:
2-of-2 example

\( R_1', R_1''\)

\( R_2', R_2''\)

\(s_1\)

\(s_2\)

Need to keep state between rounds. How does that work in hardware wallets?

Nested MuSig2/FROST

"One other cool topic that came up [at the LN dev summit] is the concept of leveraging recursive musig2 (so musig2 within musig2) to make [LN] channels even _more_ multi-sigy."

KeyAgg(
    Alice,
    KeyAgg(2-of-3, Bob1, Bob2, Bob3)
)

A

B1

B2

B3

B

AB

Taproot

½ Sig Agg

Sig Agg

Batch Verify

Key Agg

Adaptor Sig

on-chain

off-chain primitives

Layer 2

(Multiparty-) Payment Channels

Sidechains

Federated E-Cash

ROAST

ROAST

  • RObust Asynchronous Schnorr Threshold Signatures

11-of-15 Liquid federation

Schnorr Threshold Signature

Signing Process

  • FROST: If network is poor, signer is offline or disruptive then restart of signing process is required.
  • ROAST: wrapper around FROST. If 11 signers willing to sign then guaranteed signature.

Taproot

½ Sig Agg

Sig Agg

Batch Verify

Key Agg

Adaptor Sig

on-chain

off-chain primitives

Layer 2

(Multiparty-) Payment Channels

Sidechains

Federated E-Cash

ROAST

Adaptor Signatures

  • example: atomic swaps like Lightning payment, DLCs, peerswap
  • without:  requires on-chain hash
  • with: instead, off-chain adaptor signature
  • HTLC: Hash Timelocked Contract, visible on-chain, same on every hop of route
  • PTLC: Point Timelocked Contract

Lightning:

HTLC PTLC

HTLC PTLC

Taproot

½ Sig Agg

Sig Agg

Batch Verify

Key Agg

Adaptor Sig

on-chain

off-chain primitives

Layer 2

(Multiparty-) Payment Channels

Sidechains

Federated E-Cash

ROAST

Schnorr Half Aggregation

  • without: blocks contain (at least) one signature per spent coin
  • with: contain a "half"-aggregate signature, that is half as big as the sum of individual sigs
    •  
    • non-interactive
  • example: 10 half-aggregate signatures take same space as 6 ordinary sigs

  • therefore, more transactions per block

  • status: spec in progress, requires softfork

\mathsf{Aggregate}(\mathsf{sig}_1, \ldots, \mathsf{sig}_n) \rightarrow \mathsf{sig}

Taproot

½ Sig Agg

Sig Agg

Batch Verify

Key Agg

Adaptor Sig

on-chain

off-chain primitives

Layer 2

(Multiparty-) Payment Channels

Sidechains

Federated E-Cash

ROAST

Schnorr Full Aggregation

  • without: transactions contain (at least) one signature per spent coin
  • with: transactions contain exactly one, aggregate sig
  • size same as ordinary Schnorr signature
  • signing is interactive
  • smaller transactions, incentive for CoinJoin
  • status: research, requires softfork

Aggregate Size

Aggregate Weight

Conclusion

  • unclear what trade-offs are going to be made for mass-adoption
  • staying resilient takes precedence
    • surveillance resistance
    • usability for payments
    • wallet security
  • indistinguishability

Conclusion

Summary

Protocol Application Benefits Status
Batch verify Faster verification Full node ressources Prototype implementation
TR Merkle tree Hidden script paths Smaller txs, surveillance resistance -
MuSig2 n-of-n multisig Smaller txs, surveillence resistance Specification in progress
FROST t-of-n thresholdsig " Implementation in progress
Nested MuSig/FROST Recursive Thresold/Multisig Split LN node, L2 tricks Research 
Adaptor Sig Swaps, HTLCs Useful for L2, surveillance resistance Specification in progress
Blind Sigs Blind swap Surveillance resistance Applications where?
Thresh.BlindSigs Federated E-cash L2, Surveillance resistance Implementation in progress
Half Agg All txs Smaller txs Research, requires softfork
Full Agg All txs Smaller txs Research, requires softfork
ROAST thresholdsig Makes signing robust Research done

Copy of Adopting: Bitcoin Ready For Mass Adoption

By iamjon

Copy of Adopting: Bitcoin Ready For Mass Adoption

  • 222

More from iamjon

  • Academic: Bitcoin Ready For Mass Adoption
    iamjon
    274
  • EXTRA: Bitcoin Ready For Mass Adoption
    iamjon
    274
  • Adopting: Bitcoin Ready For Mass Adoption
    iamjon
    295