Mass Adoption,
But Decentralized
Jonas Nick
nickler.ninja
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 Today
Alice
Bob
bc1q... address
bitcoin
Bitcoin after Taproot Upgrade
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 verfies 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
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
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 branches
- 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
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*
- needs less communication
- in particular useful in Lightning routing
- status: implementation & spec. in progress
- needs less communication
-
FROST: m-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?
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
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
Schnorr Half Aggregation
- with: 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
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
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
- nickler.ninja/slides/
- unclear what trade-offs are going to be made for mass-adoption
- staying resilient takes precedence
- surveillance resistance
- usability for payments
- wallet security
- indistinguishability
- key aggregation: aggregation in multisig wallet
- sig aggregation: aggregation across wallets
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 multisig | " | Implementation in progress |
Recursive Key Agg | Multisig of multisig | 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 |
Adopting: Bitcoin Ready For Mass Adoption
By iamjon
Adopting: Bitcoin Ready For Mass Adoption
- 297