Non Custodial Sidechains for
Bitcoin utilizing Plasma Cashand Covenants(research in progress)
Georgios Konstantopoulos
Independent Consultant & Researcher
Twitter: @gakonst / me@gakonst.com
Slides available: gakonst.com/scalingbitcoin2019.pdf

Related Work
Plasma: Autonomous Scalable Smart Contracts, Poon, Buterin
Plasma Ethresearch, too many contributors
NOCUST – A Securely Scalable Commit-Chain, Khalil, Gervais, Felley
CoinCovenants using SCIP signatures, an amusingly bad idea, Maxwell
Preventing Consensus Fraud with Commitments and Single-Use-Seals, Todd
Minimal Viable Merged Consensus, Adler...How do we scale?
1. Increase semantic density of transactions(Segwit / MAST / Schnorr / Taproot / … / Layer 2)

2. Bigger blocks

Sidechains considered harmful
Unlock BTC

Lock BTC in escrow

Mint LBTC

peg-out

ng-ipeLBTC transfer

Burn LBTC

Sidechains considered harmful
Lock BTC in escrow

ng-ipeNo peg-out?!
LBTC transfer

Mint LBTC

Burn LBTC
transaction gets
censored!

Statechains considered harmful
Lock BTC in escrow

ng-ipe???
“Statechainentity”

Mint SBTC

Any previous holder of theUTXO key can collude withthe entity and steal funds

Plasma Cash Tradeoffs
1.
2.
3.
4.
5.

Operator cannot steal“Finalize” arbitrary number of txs
in one on-chain transaction
No overcollateralization
requirements
No need to sign to receive apayment
Can receive funds without
on-chain transaction (no notionof inbound liquidity)
https://docs.google.com/spreadsheets/d/1vHw3Rr7aFH1FXlyMjnhC0Wvro_lZ4S8hozpaWgMR1bc/

Plasma Cash Tradeoffs
1.
2.
3.
4.
5.

Operator cannot steal“Finalize” arbitrary number of txs
in one on-chain transaction
No overcollateralization
requirements
No need to sign to receive apayment
Can receive funds without
on-chain transaction (nonotion of inbound liquidity)
https://docs.google.com/spreadsheets/d/1vHw3Rr7aFH1FXlyMjnhC0Wvro_lZ4S8hozpaWgMR1bc/

Plasma Cash Tradeoffs
1.
2.
3.
4.
5.

Operator cannot steal“Finalize” arbitrary number of txs
in one on-chain transaction
No overcollateralization
requirements
No need to sign to receive apayment
Can receive funds without
on-chain transaction (no notionof inbound liquidity)

1.
2.

3.

Fixed denomination transfers
Safe only under livenessassumption (O(1) stale state
fraud proof)
Requires high base chain quality(so that disputes can reliably getincluded)

https://docs.google.com/spreadsheets/d/1vHw3Rr7aFH1FXlyMjnhC0Wvro_lZ4S8hozpaWgMR1bc/

Plasma Cash Tradeoffs
1.
2.
3.
4.
5.

Operator cannot steal“Finalize” arbitrary number of txs
in one on-chain transaction
No overcollateralization
requirements
No need to sign to receive apayment
Can receive funds without
on-chain transaction (no notionof inbound liquidity)

1.
2.

3.

Fixed denomination transfers
Safe only under livenessassumption (O(1) stale state
fraud proof)
Requires high base chain
quality (so that disputes canreliably get included)

https://docs.google.com/spreadsheets/d/1vHw3Rr7aFH1FXlyMjnhC0Wvro_lZ4S8hozpaWgMR1bc/

“Operator” commits* each block root to “parent chain”

Operator (similar toStatechain Entity)commit(0x...)*uses accumulator that supports
non-membership proofs e.g. ordered merkle tree

Users prove coin history per transfer (off-chain)Proveexclusion

Proveinclusion

Users prove coin history per transfer (off-chain)...

...
Proveexclusion

Proveinclusion

Proveexclusion

Proveinclusion

Coin history grows linearly with number of blocks
TXO Commitments? RSA Accumulators?

Exit Game: Delayed Withdrawals
DepositscriptSpend tofraud-proof script:“exit”

Wait T

Spend w/olimitations
from exit
script after T

Exit Game: Delayed Withdrawals
DepositscriptSpend tofraud-proof script:“exit”

CHALLENGE:
Spend back todeposit scriptTransaction Format: 1 input 1 output UTXO(UTXO_ID, PARENT_BLOCK, NEW_OWNER, PREV_OWNER_SIG)( 0x123, 1, Bob, Alice_sig)

UTXO ID: 0x123

1Alice234Bob

https://ethresear.ch/t/plasma-cash-was-a-transaction-format/4261

Merkle Tree: TxHash at each UTXO_ID index
Current Block: 2UID
1
47leaf[i] = txs[i] ?
sha256(txs[i]) : sha256(0)Merkle Tree: TxHash at each UTXO_ID index
Current Block: 2UID
1
47leaf[i] = txs[i] ?
sha256(txs[i]) : sha256(0)Merkle Tree: TxHash at each UTXO_ID index
Current Block: 3UID
147leaf[i] = txs[i] ?
sha256(txs[i]) : sha256(0)

Exit

12

Exit:
Parent Block, Block3

“Exit Spent Coin”

12

Exit:
Parent Block, Block

34

Challenge:
Tx spent at
Block’ > Block

“Exit Double Spend”

123

Exit:
Parent Block, Block
Challenge:
Parent Tx spent at
Parent Block < Block’ < Block

“Invalid History Challenge”

1Challenge:
Claim ownership at
Block’ < Parent Block

2

Exit:
Parent Block, Block34

Response to Invalid History Challenge

1Challenge:
Claim ownership at
Block’ < Parent Block

23

4

Exit:
Parent Block, Block

Response:Reveal spend from 1 at
Block’ < Block’’ <= Parent BlockBackground literature on covenants

What is a covenant?
Restriction on the outputs spending a UTXO.
O’Connor @ Bitcoin Workshop 2017:● Digital signatures: WHO can spend Bitcoin● Timelocks: WHEN Bitcoin can be spent

Alice

Bob???

What is a covenant?
Restriction on the outputs spending a UTXO.
O’Connor @ Bitcoin Workshop 2017:● Digital signatures: WHO can spend Bitcoin● Timelocks: WHEN Bitcoin can be spent● Covenants: HOW and WHERE Bitcoin can be spent
Alice+covenant

BobEFF

Use Cases●●●●●Vaults
Paralysis Proofs
Colored Coins (non-fungible tokens)
Congestion Control
Fraud proofs → Sidechains with trust-minimizedreverse peg● ...more in the mailing list

Covenant Designs● OP_CHECKOUTPUT (MES’16)● OP_CAT + OP_CHECKSIGFROMSTACK (O’Connor,Piekarska ‘17)
● OP_CHECKOUTPUTSHASHVERIFY /OP_SECURETHEBAG (Rubin ‘19)
● OP_PUSHTXDATA (Lau ‘17)
● Presigned Transactions (..? mailing list spec)Implementing
Plasma Cash on Bitcoin

UTXO State MachineMerkle Proof Verification
VerifyIncluded(UTXO_ID, ROOT, TX_HASH, PROOF):ROOT
TX_HASHPROOF
UTXO_IDMERKLEBRANCHVERIFY

Verify block root was signed by Operator
VerifySignedByOperator(BLOCK_NUM, ROOT, SIG):
BLOCK_NUM
ROOT
CAT
SIG
<OPERATOR_ADDRESS>CHECKSIGFROMSTACKVERIFY

Verify transaction was signed by previous owner
VerifyTxSigned(TX)
UTXO_ID
PARENT_BLOCK_NUM
NEW_OWNER
CAT CAT SHA256
SIG<PREV_OWNER_PUBKEY>CHECKSIGFROMSTACKVERIFY

Enforce UTXO is spent to next state
EnforceSpentTo(ARGS, NEXT_STATE_PATTERN):
ARGS
NEXT_STATE_PATTERNCHECKOUTPUTVERIFY(use PICK to dynamically construct the covenant with scriptSig args)

Deposit = Spend to covenant
Spend to EnforceSpentTo(EXIT)

Exit = Spend from Deposit to Exit Script

Spend toEXIT(parentIncludedTx, includedTx)

Challenge Spent Coin / Double Spend = Spend back toDeposit

Spend to DEPOSIT, show includedTx
according to exit gameChallenge Invalid History = Increment Counter,Response = Decrement Counter

Spend to EXIT’, show includedTx according
to exit game. New EXIT state = previous state with1 extra IF condition for the Response.

Withdraw = Spend anywhere after T if counter = 0

CSV 1000 BENEFICIARY_ADDRESS CHECKSIG

Finalize Challenge = Spend to Deposit after T ifcounter > 0

Summary●●
●
●
●
●
●

Off-chain fixed-denomination payments
Safe under liveness assumption“Compression” mechanism (more txs settle per block)No on-chain transaction to join
Can receive payments when keys are cold
Capital efficient
Implementation WIP (done on Ethereum since last year)
Complex & secure scripts are hard

Thank you for your attention
Q&A?
@gakonst / me@gakonst.com
gakonst.com/scalingbitcoin2019.pdf
gakonst.com/plasmacash.pdf

Appendix

More general State Transitions?
Data unavailability breaks safety…

NOCUST - Data unavailability challenge

https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding

“Optimistic Rollup” - Put all the data on-chaincommit(0x...) + encoding of txs

Use the Layer 1 as a data availability and dispute layer. Do not
perform any computations on the txs themselves.

Security & Incentive Compatibilityof Layer 2 games requirements*:- liveness (somebody must challenge)- expected reward of attacker <=0*L2 games are implemented as deferred optimists:
https://medium.com/@decanus/optimistic-contracts-fb75efa7ca84

Secure iff challenge included before t0 + T
t1 + D < t0 + T → attack cancelled

t0

t1

t1 + D

Malicious
Exit

Challenge
broadcast

Challenge
includedt0 + T

Secure iff challenge included before t0 + T
t1 + D < t0 + T → attack cancelled

t0

t1

t1 + D

Malicious
Exit

Challenge
broadcast

Challenge
includedt0 + T

Insecure iff no challenge included before t0 + T
t1 + D > t0 + T → attack succeeds

t0t1

Malicious
Exit

Challenge
broadcastt0 + Tt1 + D

Challenge
includedInsecure iff no challenge included before t0 + T
t1 + D > t0 + T → attack succeeds

t0t1

t0 + T

Malicious
Exit

Challenge
broadcast

Safety condition: D <= T + t0 - t1

t1 + D

Challenge
includedLiveness ofobservers

Attacker Decision Flow
Malicious Exit
llednge

Cha

Attack Failed

Pay fee + bondNo challenge

Attack Succeeds++-Full bond refunded
Coin valueobtained
Exit feeAttacker Decision Flow
Malicious Exitdngelle

Cha

Attack Failednuntr
or

FrontrLosses cut-

a% of bond refunded
Exit fee
Challenge fee

unfaiBig losses-No challenge

Attack Succeeds

lsF

Pay fee + bond

100% of bond lost
Exit fee
Challenge fee++-

Full bond refunded
Coin value
obtained
Exit feeIncentive Compatibility of the Exit GameNo challenges = success:● ↑ onchain congestion / censorship● ↑ block withholding● ↓ liveness of participants● ↓ challenge period T

Large T = Secure but bad UX!

Incentive Compatibility of the Exit GameNo challenges = success:● ↑ onchain congestion / censorship● ↑ block withholding● ↓ liveness of participants● ↓ challenge period TLarge T = Secure but bad UX!

Cost to Attack =● Tx fees (constant)● Fidelity Bond(goes to challenger)

Incentive Compatibility of the Exit GameNo challenges = success:● ↑ onchain congestion / censorship● ↑ block withholding● ↓ liveness of participants● ↓ challenge period T

Cost to Attack =● Tx fees (constant)● Fidelity Bond(goes to challenger)

Large T = Secure but bad UX!
Attacker won’t frontrun
if nobody challenged

Frontrunning removes bondfrom cost if successfulIncentive Compatibility of the Exit GameNo challenges = success:● ↑ onchain congestion / censorship● ↑ block withholding● ↓ liveness of participants● ↓ challenge period T

Cost to Attack =● Tx fees (constant)● Fidelity Bond(goes to challenger)

Frontrunning removes bondfrom cost if successful

Burn part of the bond.
Large T = Secure but bad UX!
Attacker won’t frontrun
if nobody challenged

Plasma Cash → Fixed-denomination.
Arbitrary denomination payments?

Plasma Cash + Channels = Plasma Debit● Each coin is a channel with the operator
Example:A has a 5/5 coin. B has a 0/5 coin. A can pay B by atomically decreasing
her coin by 1 and increasing B’s coin by 1. Capped liquidity. Also receiverneeds to sign the state update.

https://ethresear.ch/t/plasma-debit-arbitrary-denomination-payments-in-plasma-cash/2198

Plasma Cash + Fragmentation = Plasma Cashflow

1 EuroPlasma Cash + Fragmentation = Plasma Cashflow

1 Eurorange of 10 x 10 cent fragments

A non-interrupted range can be transferred in 1 tx
Bob
Alice

0255075

Alice transfers range [0,75) to Bob!

100

A non-interrupted range can be exited in 1 tx
Bob
Alice

02550

Alice exits range [0,75)!

75

100

Any 1 coin inside the range is a valid challenge!
Bob
Alice

0Challenge with 26!

25

50

Alice exits range [0,75)!

75

100

Defragmentation of ranges
Bob owns 1 range
Bob
Alice

02550

75

100

Alice owns 2 ranges

https://twitter.com/_sgtn/status/1100357379760091137

Defragmentation of ranges
Bob owns 1 range
BobAlice0255075100

Alice owns 1 range!

https://ethresear.ch/t/plasma-cash-defragmentation/3410
https://ethresear.ch/t/plasma-cash-minimal-atomic-swap/3409

Merkle Interval Tree
Inclusion / exclusion proofs for ranges w/ light client support!

https://www.youtube.com/watch?v=-8Jp7VjspQE