Stanford BPASE 2018 Day Three
2018 . 05 . 10

You can find the program for the conference and all slides and videos here. Notes for day-one are here, and day-two here.

Table of Contents

Talk 1: Bulletproofs

Benedikt Buenz

initially designed to help with confidential txs, but can be applied to arbit computations

validity of btc tx:

  1. sig is correct
  2. inputs are unspent
  3. sum of inputs > sum of outputs. Difference -> miner fees.

But is neither confidential (tx amounts not hidden) nor anonymous (can see addresses coming from and to). Confidentiality is important e.g. for businesses to not reveal suppliers and customers.

Confidential Transactions idea:

Confidential txs [Maxwell 2016]

To verify tx validity:

NIZK: non-interactive zero-knowledge proof of knowledge

Concrete range-proof using bit-commitments

Linear range proofs:

Preprocessing SNARKs with Trusted Setup (GGPR ‘13)

STARKS: CS Proofs (computationally sound) [Ben-Sasson ‘17]

Bootle et al ‘16: log-sized proofs for Arithmetic Circuits

Bulletproofs (also applies to MimbleWimble):

Multi-Party Protocol for Bulletproofs

Bulletproofs for CT or MimbleWimble

…insert image for comparing proof systems…


Talk 2: Chainweb: a Braided Parallel-Chain PoW architecture for massive throughput

Will Martino, Stuart Popejoy: Kadena


Key Features:

  1. peer chains cross reference each other’s previous merkle roots
  2. trustless, destructive cross-chain coin transfers through SPV at the smart-contract level

Prior Art:

two-step trustless cross-chain destructive coin transfers:

  1. delete coins on chain A. Specify:
    • delete account on chain 1 and amount
    • create chain and create acct
  2. “Create” requires a merkle proof of deletion
    • smart contract runs spv, gets amount and acct from proof
    • consume delete’s tx id

Talk 3: Mobius: privacy layer for ethereum

Rebekah Mercer

unlinkability: have many inputs which can give plausible deniability into who the sender was

approach 1: new currency ZCash: Dash: litecoin uses master node to do mixing in some way monero: ring confidential txs

approach 2: privacy overlay for an existing currency

Talk 4: Trustchain: micro economy for bandwidth tokens

John Pouwelse, Quintin Stokkink: Ledger Scientist

“TRIBLER: a social based peer to peer system”


currently trust is locked-in, where there is a reputation system owned by airbnb or uber in the future, we’ll have a generic trust system

Talk 5: Dfinity: Threshold Relay

Timo Hanke, Dfinity Whitepaper for consensus

goal for PoStake:

Challenge 1: consensus and scalability

Challenge: randomness 1.derive randomness from chain? * chain is manipulatable * assumes everyone agrees on chain (but forkable!) * hence: * must not depend on chain, since it is “grindable” * must not fork

  1. “last actor” bias: * last actor has info advantage, can see randomness that may be output and could abort. e.g. one actor, and she needs to roll dice in cup, but could peek under it and see 6 and reject it.
    • any fallback mechanism (after abort) introduces bias
      • e.g.: miner discards block, commit-reveal schemes (moved problem to when reveal happens that actor could be bad)

Challenge: Security - PoS attacks:

Fundamental Observations:

q. how does one recover if a majority of validators is offline?

q. what are the tunable parameters? this could be important when bootstrapping the network, or managing it over time as more participants join or leave.

  1. committee size
  2. block time: rank block-makers, because we want to give them a higher chance of submitting their block to the notaries.

q. fork choice rule?

  1. block maker needs to pick fork on which to build next block (can have various algos to weigh diff forks)
  2. notaries need to decide which of the two proposed blocks to confirm.

Second part, by Mahnush

Open Participation

to join a group is hard:

  1. randomness of the chain defines new groups
  2. the group members run distributed key generation
  3. they join by providing their group public key

Challenge: how to agree on the group public key solution: use the consensus mechanism of the dfinity chain at the current epoch to change the behavior of the system itself at future epochs

system contracts:

DKG contract:

DKG phases:

take away:

  1. system contracts are useful. Can be used to manage future behavior of the change
  2. carefully design so that heavy part of the code is client-side and only consensus-parts are onchain
  3. only the data that need agreement over will pass to the contract
    • contracts are event-driven, instead of phase-driven

RapidFire Talks

Talk 6: Power Fault Tolerance: a new framing for consensus protocols

Juan Benet


  1. context:
  2. engineering protocol
  3. open problems

types of nodes: malicious, rational (need incentive), altruistic/honest (always follow protocol) btc works even in presence of malicious nodes. Introduce notion of proofs that data is stored. current cloud is based entirely on replication. currently users can lose data if the startup/company closes down.

what if: user owned data but could control who had access. moreover: can we use incentives that enable renting space on hard-drives.

modelled filecoin v2 paper after zerocash paper (zerocash was v2 of zerocoin) filecoin is built on top of IPFS


Filecoin properties:

Novel parts:

three characters:

  1. clients: store files, pay filecoin
  2. miners: store data for network collect filecoin
  3. network: organizes miners and clients

Network should constantly be requiring proofs of storage.

protocol needs blockchain for:

miner’s power is proportional to useful-storage they provide network

markets for puts and gets can happen offchain, but for now is onchain to assist price-discovery

type DSN interface { Put(Data) Key Get(Key) Data Manage() }

DSN properties:

  1. complete,
  2. secure if
    • assures data-integrity
    • assures retrievability,
    • tolerates management faults ((f, n)-tolerant if f nodes accept n faults),
    • tolerates storage-faults (f,m)-tolerant if Put stores in m independent storages can tolerate f faults, where m «< n
  3. publicly verifiable
  4. auditable, via trace of operations
  5. incentive-compatible

Proofs-of-Replication & Proofs-of-Spacetime

Proofs-of-Space comprises Proofs-of-Storage, which comprises (PoRep, PoRet, Proof-of-Data-Possession)

Security game for Proofs-of-Storage are of the form:

  1. Verifier sends to Prover: Setup(data)
  2. Verifier sends Challenge()
  3. Prover does proof <- Prove(challenge, data); and sends proof
  4. Verifier: {0,1} <- Verify(challenge, proof) This is PDP (proof of data possession). if proof can return data, then it is PoRet.


  1. What if we want P to store 2 copies of data?: * P could pretend to store 2 copies and only store one. * simple fix: verifier pre-encrypts different copies * but these preclude prover from repairing copies…
  2. What if we want P1…Pn to store 1 copy of data each? (Sybil attack): * P1….Pn may be sybil identities or a coalition * They could pretend to store 1 copy each, but deduplicate to store only 1.
  3. What if P could choose or determine the data?Generation Attack): * concrete description: P could choose data such that P can generate the data on-demand. P then pretends to store the data, but re-generates it just-in-time to Prove challenges. * hard to defend, but in DSN settings its very easy to do by aligning incentives. * hard to avoid participation rewards to ensure Generation Attack would be irrational



See slides for:


  1. IPFS is live
  2. dApps
  3. participants with large datasets: machine learning or scientific

Talk 7: Proof of Replication using Depth Robust Graphs

Ben Fisch

Data Generation Attack:

Crypto Definition

  1. Leads to an Extractor, proving proof-of-retrievability
  2. proof-of-space: any snapshot (at time t) of the prover’s space must be of an appropriate size
  3. replication: can partition this snapshot into parts so that one can independently derive a replica of the original data.
    • unfortunately, this is very hard to achieve in a cryptographic sense, because whatever strategy an honest-prover uses to verify their snapshot, can be mimic’d be an adversary who stores the data+key and then generates the snapshot such that it has two partitions.
    • so: assume a rational adversary. “Good” strategy satisfies strong-replication. For any adversary strategy, there is an efficient way to switch to a “good” strategy. Hence there is no real incentive to act bad.

Proofs of Replication:

Basic PoRep:

What about large files?

CBC-stream encoding

Solution: use Depth Robust Chaining

Talk 8: TLS-N: Non-repudiation over TLS enabling Ubiquitous Content Signing

Hubert Ritzdorf

in TLS:

may want to do so for e.g. for archiving. better use case is: blockchain oracles

with smart contract on blockchain want to do something that requires on real-world data, and needs an external data source (called oracle) to help out.

requester/client <– TLS conversation (http session or else) –> generator/server <…..CA verifies identity of server to client to verify server identity

possible problems:

  1. request-response can suffer from content reordering issues. e.g. what is price of btc? and response can come in other order.
  2. privacy: usually send GET request to server. use access_token. added in plain-text with encryption. but now, this will be exposed.
    • need redactable proofs!
  3. denial of service: if have 1 signature over everything. this may mean server gets very large state => DOS attack.
  4. redactability of proofs: if server has to decide what parts to redact. Means computational overhead on server => DOS attack.


  1. small server side state and overhead
  2. client-side privacy protection (client decides what parts to redact and which to keep after getting response form server)
  3. clear context -> total order on requests

TLS-N overview:

  1. start with TLS handshake.
  2. generate evidence: process small tls records with small state (on server). on client, needs to store all tls records and TLS-N parameters from handshake
  3. client “returns evidence” to server
  4. server “signs: evidence-generated + tls private key” + client’s evidence -> sends evidence to client.
  5. client uses privacy settings to generate its proof, after any redactions it has done.

Talk 9: NuCypher KMS: Decentralized Key management system

MacLane Wilkison et al



Solution: proxy re-encyption + decentralization

PRE (proxy re-encryption)

Use threshold split-key re-encryption (Umbral)

used by: