Stanford BPASE 2018 Day One
2018 . 05 . 02

You can find the program for the conference and all slides and videos here.

I’ve written this as a companion to the talks, mainly as a tool for me to ensure i absorb the material, and to refer back to later. If it helps the broader community, and i hope it does, then awesome! Please direct any feedback to me on twitter.

Table of Contents:

Intro talk

by Byron Gibson

This conference deals with a few kinds of security:

Some themes that will be covered:

Talk 1: Game theory and network attacks: how to destroy bitcoin

Max Fang. blockchain at berkeley: CS+Econ at UC Berkeley. slides.

This talk is a survey of attacks. For an excellent overview of mining attacks with beautiful illustrations, see this pdf.

selfish mining

Variation: what happens if the network found a valid block, before this miner finds the second block?

stubborn mining model

formal model:

Stubborn strategies:

selfish mining defenses

Game Theory based censorship

want to prevent someone’s transactions. Let’s imagine we have GJ = gary johnson = a prototypical libertarian. and we have a Censor = e.g. China.

51% attacks and collusions

practical caveats:

Talk 2: State of the art attacks on secure hardware wallets

by Charles Guillemet, CSO at Ledger. video

I’d recommend just watching this talk. The speaker was slow and clear, and gave a great overview of the security threats. Recently, there was an interesting attack published on the Ledger wallet, whose details are a handy companion to this talk.


Ledgers have:

Reminder: Secure software is super hard


Talk 3: smart contracts for bribing miners

by Patrick McCorry: @paddyucl. Paper

useful background info:

future work:

Talk 4: Formal Barriers to Proof of Stake Protocols

By Jonah Brown-Cohen et al

Proof of Stake:

Talk outline:

  1. a model for analyzing incentives in pos
  2. properties such that every protocol in model satisfies one of these properties
  3. for each property, incentive driven attacks against the protocol that satisfies this property

disclaimer: attacks are well understood, but for a broad class of protocols these attacks work better than pow


Jonah proposes the following model

  1. use some method to pick coin
  2. use some method to pick existing block
    • TODO savil: won’t this always be the last “mined” block?
  3. owner of coin gets to add new block
  4. repeat

Formal notation:


  1. chain dependence: validity of B at t depends only on t and Pred(B)
  2. monotonicity: if B is valid at time t, then valid at all future times t’ > t
    • even if not on longest chain, block is still “valid” These assumptions hold for pow protocols like btc. These assumptions means we don’t consider “eclipse-attacks” as threats in this model (although they exist in real life).

POS, has two functions:

  1. validating function V
    • efficiently computable by every protocol participant
    • B with A = Pred(B) is valid at t if and only if
    1. V(B) = 1
    2. Miner(B) = Owner(c(B)) at A
    3. t(A) <= t(B) <= t
  2. mining function M: inputs are B, coin c, timestamp t => outputs new block
    • M(A, c, tv) is efficiently computable by owner
    • if there is a valid block, then mining function should actually mine something

Longest-chain protocol

Attack: predictable selfish mining:

Attack: predictable double spending

Attacks: undetectable nothing-at-stake


q by ken huang: for casper

q: alternatives to pos

q: ?

q: smaller the D, may affect entropy of seed that is used to randomly select miners?

q: asynchrony plays a role. the more synchronicity you assume, the more you can eliminate selfish mining

q: check out Dfinity (not a question!)

Talk 5: programming incentives: an intro to cryptonomics

by Karl Floersch, Ethereum Foundation

On casper protocol

pow: has incentive to mine on the longest chain => casper needs to solve this


  1. waste of energy
  2. vuln to asic and centralization
    • makes chain reversion relatively low cost
    • no inprotocol penalty for reversion
  3. no “finality”
    • UASF exploited this vuln
  4. no clear validator set
    • useful for: sharding, main chain consensus (casper), cryptoeconomic light clients (e.g. want to sync chain, get block from validator who signs that if block is not in main chain then loses deposit)

hybrid casper:

why deposits?


slashing conditions

designing casper FFG by Vlad and Vitalik

“parameterizing casper: decentralization/finality tradeoff”

Q: ken huang problems:

  1. ddos against validation pool
  2. collusion in validation pool (67% attack) Answer:
    • slashing means minority loses deposit. There is some paper about this.
    • to mitigate: can fork off censoring chain (???)

q. is there a complete final write up of the protocol? for academic contributions

q. planning to swap out consensus mechanism for $100B currency, does it worry you?

q (DHVC): path from hybrid to full?

q: smart contracts, have access to block info, and will there be access to epic/finalization info?

q: what is the simulation environment or research process?

Talk 6: ThunderToken: blockchains with optimistic instant confirmation

By Elaine Shi, Cornell and Thundertoken

This talk was interesting because it bridges the world of traditional distributed consensus systems, and finds a way to use a blockchain to improve it. A neat idea that could be useful in smaller, permissioned networks.

So, why is this not a solved problem? why roll one’s own?


  1. when things are good: single round of voting when things are good
  2. when things are bad: use blockchain to “view change” when things go bad

Insights gained:

  1. claim a new theoretical paradigm.
    • In the old consensus, we have an asynchronous world, where the “bad path” makes solving this problem hard.
    • with blockchain, we use a synchronous protocol.
  2. “block interval must be constant time (O(1)) larger than max network delay”
    • “permissionless consensus has to be synchronous”

q. what happens when underlying blockchain gets forked in the grace period?

a. grace-period should contain enough blocks (k should be sufficiently large). blockchain protocol is such that if you wait long enough then this is okay.

Talk 7: smart signatures, experiments in authorization

By Christopher Allen, formerly blockstream. slides. video.

smart signatures: core use - authorization

Main difference from traditional signatures:



Language requirements:

System requirements:

What about privacy as a requirement?

experiment: Bitcoin Script

experiment: Ivy, by

experiment: Dex

experiment: Simplicity, by Russell O’Conor

experiment: Sigma-State

experiment: Michelson

experiment: crypto conditions

watching: bamboo on evm

open questions:

moar open questions:

“Smart signatures” paper

Language geeks: go to #RebootingWebOfTrust event march 6-8 in Santa Barbara

q. (ken huang) can one extend X.501 to have these scripts? a. there has been some talk about this. more interested in “verifiable credentials or claims” community, using JSON that can be signed as a graph-signature.

q. (ken huang)…? a. idea behind “self sovereign” identity. something something.

q. confused, you said “a smart signature is a predicate language” but Simplicity is more than that? a. not turing complete, it unwinds all loops etc. and people want to use it for provable predicate scripts, but clearly can be used for more. still suffers from re-entrancy

q. what was your role in “sovereign foundation”? you’d mentioned it and i missed it. “sovereign foundation” are part of RebootingWebOfTrust community and working with W3C who have given permissions to move it forward as a “work item”.

Talk 8: Hardening Lightning

Olaoluwa Osuntokun, Lightning Labs. video. If you are like me, then you’ll watch this video at 0.75x speed.

To see the mechanism behind the Lightning Network, see this excellent Bitcoin Magazine article. TLDR; payment channels, connect them, route transactions across them.

This article gives an overview of many other LN sub-topics.

This talk is the only one dealing with a production system, and goes into many improvements that could be done to many aspects of the LN. Its dense: each improvement has an underlying concept and current implementation that one needs to understand first.

Talk Outline:

  1. Overview of Lightning’s Security Model
  2. Hardening Contract Breach Defense - what to do in the face of a big backlog of transactions?
  3. Reducing Client Side History Storage A. a new channel design! It makes channels more succint, storing less history, makes outsourcing more efficient.
  4. Scaling Outsourcing (WatchTower++)
  5. On-chain Succintness A. Better Fee control

Think of Lightning as four layers:

  1. Blockchain Layer: bitcoin!
  2. Channel Link Layer: opening and updating some channel between me and Bob
  3. End-to-End Routing Layer: HTLCs (Hash Time Lock Contracts)
  4. Application Layer: exchanges, etc. i.e. LApps

Security Model:

Hardening Contract Breach Defense (Strategy):

Reducing ClientSide History Storage

Overview of Commitment invalidation:

History of Prior Succint Commitment Invalidation

  1. decrementing sequence-locks (using BIP 68).
    • how: use relative time-locks such that the latest state can go in before prior states
    • downside: this design limits the number of possible updates
  2. Commitment invalidation tree.
    • used in Duplex Payment Channels
    • how: commitments are structured in a tree such that the parent must be broadcast before the leaf.
      • in this design, the Roots have decrementing time-lock with a “kick off” that allows for indefinite lifetime
    • downside: has a big on-chain footprint
  3. Commitment Revocations: hash or key-based, is the current channel design
    • how: every state has a public-key, and to move on to the next state, one must reveal the secret-key of the prior state.
      • they’ve figured out a way to generate this public-key in a deterministic way: can walk down the client’s constant-size state to generate secrets, and the receiver can collapse these down. (gah, need more details here!!)
    • downside: must critically store O(log n) secrets of the remote party. More complex key derivation.
      • Also, has asymmetric state between the two channel parties. This is because of the way “blame” can be ascribed to avoid cheating. This is bad because if there is a network with N participants, then keeping track of state for N grows combinatorially. * GOAL:
        1. symmetric state
        2. constant storage for prior states

Commitment invalidation in Lightning 1.0 (current Lightning Network):


Signed Sequence Commitments:

Scaling Outsourcing: a review of state outsourcing

Scaling Outsourcing: lighter outsourcers

Scaling Outsourcing: outsourcer incentivization

Scaling outsourcing: outsourcer static backups

Onchain Succintness: 2-stage HTLCs

Onchain succintness: multi-party channels

Onchain succintness: Fee control

Talk 9: Enter the Hydra: towards principled bug bounties and exploit-resistant smart contracts

Florian Tramer et al: making a ethereum contract development framework

bug bounties leverage crowd to find issues, rather than rely on small internal team of engineers to do so. problems:

perfect bug bounty should satisfy:


Bug witholding and commit-reveal:

submarine sends (post-metropolis version)


  1. only allow committed-users to send a transaction to C
  2. being eternally committed is expensive
  3. attacker can’t know if someone has committed
  4. money is not wasted

submarine sends:

Phase 2: reveal addr to contract