SECURE THE BAG
Jeremy RubinWhy are wehere?

What isScaling?

Increasing
Transaction
Throughput

Scaling = Tradeoffs-Decentralization
Redundancy
Privacy
Censorship Resistance
Layerization Complexity
Latency
Cost
Peak/Trough Provisioning
Reliability
Interactivity-

Bandwidth Requirements
Storage Requirements
Fairness"Scanability"
Homogeneity of use
Collateralization
Smart Contract Complexity
Quantum Resistance
Reorg Safety
Orphan Rates
Etc...

Acceptable tradeoffs?

Block Size Increases

PROCON

Conceptually Simple

Reliability/DoS
Centralization
Hard-Fork
Storage Requirements
BandwidthOrphan Rate IncreaseLightning NetworkPROCON

Low Latency

Contract Complexity

Privacy

No Settlement Finality

Low On-Chain Usage

Collateralization
Interactivity
Intermediation/Middle Men
No Reorg Safety

??? ‫מַ ה זֶּה‬PROCON

Conceptually simple

Real time Bandwidth reduction

Low Latency

Soft ForkPrivacy

Reorg Safety

Immediate Settlement Finality etc...
No over-collateralization
Low contract complexity
Non InteractiveN.A.

Intuition BuildingIntuition Building:Committed UTXOs / "Certified Cheques"
NormalCommitted1?

A

2

B

3C

4Z

5A

2~A#11?

1

Intuition Building: Batched Payments
PaymentBatch Payment
456711A4238A

910112B

125131415Intuition Building: Two Phase Payments
Batch Payment

2-Phase Payment
445566712A

378192108A?

3119101112121313141415Pay Phase 1:Spend(3); Create(12);B

15Spend Phase 1:Spend(3); Create(1);Receive Phase 2:Spend(1); Create(12);Intuition Building: Multi Phase Payments
2-Phase Payment

12A3?

BChained Payment
4455667781921038A?

B?

111212131314141515

Receive Phase 2:Spend(1); Create(12);91011Spend Phase 1:Spend(3); Create(1);CSpend Phase 1:Spend(3); Create(1);Receive Phase 2:Spend(1); Create(6);Receive Phase 3:Spend(1); Create(7);Intuition Building: Tree Payments
Chained Payment

Tree Payment

44556B?

7167188923A?

B?

C9102A

103111112131415?

C12?

13D

1415

Intuition Building: Receiving Tree Payments
Spending Tree Payment

Receiving Tree Payment

44D?
?

D5B?

6?

E
127A
83F?

?

9?

10CG

115?

6B
E

12?

7A

3?

What's the magic?

?

Four Options-

👎"Covenants" (OP_COV)👎
👎Pubkey Recovery (CHECK.SIGFROM.STACK, ANY.PREVOUT/NO.INPUT)👎
👎Presigned Transactions👎- 🆕👍OP_SECURE.THE.BAG 👍🆕

Alternatives? 👎👎👎-OP_COV--

Presigned Tx Multisig--Too Powerful → Too Much Technical Risk
Covenant "viruses"Complex implementation rules
Specific outputs
Interactivity OR Trusted Third Party
Fancy ECDSA OR Schnorr protocols (fairness impossibility problems)
Can't prove receiving guarantee to third party
Key Deletion "Toxic waste"

Pubkey Recovery (CHECKSIGFROMSTACK, ANYPREVOUT/NOINPUT)-Possible recursion with OP_ECTWEAK
Abstraction violation "Keys should be Keys, Signatures, Signatures"
Incompatible with message digest including pubkey; related key attacks

OP_SECURETHEBAG-Multibyte OpCode: `OP_SECURETHEBAG 0x20 <arg>`
STB(tx) = H(tag || ver || locktime || H(outs) || H(seqs) || # inps || scriptSigs)
STB(tx) commits info which mutates TXID except input COutpoints
OP_STB verifies STB(tx) matches what can be computed from tx
Multibyte Op structure ensures the desired TX is known at spend time-

Disallows all recursive covenants
Future safe w.r.t. Above: There is no set of pure extensions* to script E such that enabling E and OP_SECURETHEBAG
as proposed enables recursive covenants, but E alone does not enable recursive covenants?

-Multiple inputs allowed--Generally not safe to use #inps > 1! -- "half spend problem"

Deployment: inside of Tapscript or standaloneImplementation Progress-Draft BIP
Proof of Concept Code for Opcode Available
Experimental core wallet support in progress
Minor BIP options in flux (pushless multibyte opcode v.s. taint tracking v.s. …)
Deployment Strategy T.B.D.

Impact

⚠WARNING⚠
Simulated Results
May Not Match Reality⚠WARNING⚠
This message brought to you by respect for the scientific process;results reproducible from https://github.com/JeremyRubin/bips/blob/op-secure-the-bag/bip-secure-the-bag/simulation.py�

�More Time; Less Adoption

10 xMore Time; Less Adoption

10xSummary: OP_STB is a Txn Bypass Capacitor-Smooths out the Backlog
Soaks up excess txs, releases them later
Private benefit large even with small adoption
Private use benefits entire public (mempool decongestion)
Healthier backlog of low-priority transactions
Reorg Safety:
3?

1241

What's the catch?

First: Multi-Radix Congestion Controlled Transactions
Block N

Block NIF STB A
ELSE STB B

Block N+1Option B

Block N+1 A

Block N+1 BOption A

Option B

Block N+1

Block N+1Confirmed in Block N
Spendable Block N+1

Block N+2

Block N+2

Block N+100

Confirmed in Block N
Spendable Block N+2

Block N+100

Confirmed in Block N
Spendable Block N+2
Confirmed in Block N
Spendable Block N+100

Confirmed in Block N
Spendable Block N+100

Probably True Claim; Fancy Way of Saying No-Cons
Given:-O(1) overhead amortized per input & O(n) overall, where w/o STB cost is O(n) also
Multi-radix setups (OP_IF, OP_MBV, or Taproot) (Huffman Encoded)-- Simple radix-2 and radix-N expansion IF P(radix-2 used) = O(1/n) is E[O(c)] overhead
Ability to defer and wait for 'asymptotically cheaper' blockspace (fees discounted O(1/n))
Smaller Size/verification of interior node txns compared to normal txns (no signatures)
Prunability of interior nodes (recomputable from leafs)
Optimal Tree Structure (leafs at different depths)
Subtree application of the above principles

The overhead of OP_STB is E[O(c)], where the actual overhead c is a small constant.

Quickfire:
Advanced Topics inSecure The Bag

Inter Business TrafficOP_STB withdraw from Exchange A can be immediately credited to Exchange B
Funds are effectively in "cold storage"
Businesses can manage their liquidity
Let users receive goods/trade once confirmed.

Ball Lightning
BIG OP_STB TREE

B:E

C:D

A:B

D:E

A:D

B:C

N participants; O(N log N) channels
Setup: O(1)Closing 1 Channel: O(log(N log N)) = O(log(N) + log log N) = O(log(N))
Closing all of a User's Channels: O(N log N / N) = O(log N)
Closing Channels Amortized Per Channel: O(N log N / N log N) = O(1)BE
N participants; O(N^2) channels
Setup: O(1)Closing 1 Channel: O(log(N^2 )) = O(log(N))
Closing all of a User's Channels: O(N^2 / N) = O(N)
Closing Channels Amortized Per Channel: O(N^2 / N^2) = O(1)ADC

Smart Contracts

OP_STB unroll looped programs into finite steps
Pick large RUN_LIMIT
Pick acceptable default action
Original Program Intentfor int i = 0; i < RUN_LIMIT; ++:iwhile (true):if (sign key A):

Control UTXO 0:or( and(sign(A), STB(TX 0)),and(sign(B), sign(C)))

TXN 0
1 Input
Create UTXO 1

Arbitrary
TXN B+C
Authorized

if (sign key A):
wait(100 blocks)
wait(100 blocks)
else if (sign key B & C):
else if (sign key B & C):
return ALLOW_SPEND

Control UTXO 1:
and( wait(100 blocks),or( and(sign(A), STB(TX 1)),and(sign(B), sign(C)))

return ALLOW_SPEND
wait(sign key B & C)

TXN 1
1 Input
Create UTXO 2

Arbitrary
TXN B+C
AuthorizedSmart Vaults: Using Control Programs
Control UTXO 0: STB(TXN A)
TXN F:Create UTXO D0Deep Cold UTXO D0nesaighsohn

TXN A:+1 Hour
2 Inputs
Create UTXO 1Control UTXO 1: STB(TXN B)

TXN W:+1 Hour
Spend Arbitrary

Cold UTXO C0
Cold UTXO C1TXN B:+ 1 Hour2 Inputs
Create UTXO 2

Cold UTXO C2Control UTXO 2: STB(TXN C)Hot UTXO H0+1 Hour Arbitrary OR
STB(F)Hot UTXO H1Hot UTXO H2

TXN C:+1 Hour
2 Inputs
Create UTXO 3Non Interactive Channels (works w/ Ball Lightning)Arbitrary UTXOTXN A:Create UTXO
1Main Channel UTXO:
2 of 2 Cooperative or STB(TXN B)

TXN Coop[i+1]:
Create UTXO i+1(Half Signed)

UTXO i+1:
Close State i+1
TXN Uncoop[i+1]:
TXN Uncoop[i+1]:
Createi+1
TXN UTXO
Uncoop[i+1]:
Createi+1
TXN UTXO
Uncoop[i+1]:(HalfCreateSigned)
UTXO
i+1
TXN
Uncoop[i+1]:(HalfCreateSigned)
UTXO
i+1
TXN
Uncoop[i+1]:(HalfCreateSigned)
UTXO
i+1
TXN
Uncoop[i+1]:
CreateUTXO i+1(HalfSigned)
CreateUTXO i+1(HalfSigned)(Half Signed)(Half Signed)

TXN B:Create UTXO
2

Uncooperative Close Initiated UTXO:
2 of 2 Cooperative or STB(TXN C)UTXO i+1:
Close State i+1

TXN C:+2 WeeksCreateUTXO 3UTXO 3:
Close State 0

Coordination Free Decentralized Mining Pool Payouts

Summary:
OP_STB "‫"סבבה‬Deployment

Do we needthis feature?

Yes

How Urgently?
Later

NOW

Fees are low right now.

Why wait for the sickness?

Other exciting changes on the way.

Changes are slow, better to push when notsuffering.

Limited engineering resources.
Exchanges spend millions per year on BTC
fees; invest more eng time in reducing feeburden.
Healthy backlog of low priority important ashalving approaches.

Options
Tapscript Extension

Standalone OP NOP Upgrade

ProProMerkle Branch Lookups

Available broadly

Easier to change opcode semantics

Don't need to wait for Taproot

ConConDelay

Can't use Tapscript OP_SUCCESS

Can't use with legacy scripts

Less "forced" Taproot privacy benefit
Messier OpCode semantics

FIN
How to Get Involved:
Review the BIP.
Sponsor me: I'm a starving independent researcher.
Work on the implementation.
Work on integrating OP_STB in your products.
Chime in on the mailing lists.
Follow @JeremyRubin / Tweet your support!

Work partially supported