Bitcoin & Blockchain applied cryptography problems Adam Back - - PowerPoint PPT Presentation

Bitcoin & Blockchain applied cryptography problems

Adam Back <adam@blockstream.com>

Cryptography adoption criteria

• Conservative security assumptions

– Or graceful security degradation

• Reasonably compact serialisation
• Reasonably efficient validation cost
• Scalable (ideally no indefinitely growing data)
• Patent free
• However also side-chains

– Allow more experimental or bleeding edge – Opt-in and bitcoin interoperable

side-chains

• Maxwell, Back '13
• Move coins into a chain (provable destroy)
• Moving them back (provably suspend)
• Reanimate via proof of destroy on sidechain

– Proof, maturity period for counter-proof longer chain

• Compact proof of a chain of work
• Skip-list with extra 0 allowing depth 2, two extra

0s allowing depth 4.

– Work preserving – forgery requires as much work

Proofs vs Execution

• Bitcoin smart contract model is that proofs of

execution are checked for validity.

• Validation is not execution itself.
• Blockchain is a contract arbitration mechanism.
• Inefficient in space & execution to actually

execute.

• Longer term ZK-SNARKs are an example of

proof vs execution. Script not revealed, just proof that it was known and satisfied.

• Shorter term MAST model.

P2SH

• Delay reveal of script
• P2SH address = H(script)
• Validation requires:

– H(script') == H(script) – Providing <scriptSig> <script'> such that scriptSig

as an input to cause script' to be true

• Generalisable mechanism...

MAST or P2SH^2

• Merkelized Abstract Syntax Tree

– address=MerkleRoot(syntax tree)

• Short-circuit logic can be omitted from proof

– A or B … show more compact of A or B if both true

• Optional nonce for contract privacy

– node=H(nonce || <left>, nonce2 || <right>)

• General case: sig(A & B) or Merkle(syntax tree)

– 99% case sig(A & B) is all that is needed – No incentive for A or B to dispute as script is

deterministic known to both

Fungibility & Privacy

• Unlike previous systems (Chaum, Brands etc)

bitcoin is missing cryptographic unlinkability

– Ledger has full history of transactions

• Bitcoin suggests practice of one-use addresses

– Some ambiguity from change vs payment

• However results in backup problem

– Solution sequence of pub/pri keys Wuille '13 – x_i = MAC(code,i)*x mod n – Q_i = MAC(code,i)*Q – backup “chain code”, and seed/master pri x

Store & forward, key distribution

• Bitcoin payments store & forward over p2p

network

• Sender knows address/public key

– address=H(public key)

• everyone can see total received by address
• Share chain-code then sender & recipient can

send/scan for payment to sequence of unlinkable addresses

• But bootstrap problem – how to communicate

chain-code

Unlinkable “stealth” address

• Elgamal encrypt

– Sender derived Q'=y*Q where Q=xG – Send e = Elgamal( P, y )

• Receiver trial decrypts e and checks if it

matches Q'

• Problem: expensive download & decrypt all
• Privacy: delegate decryption gives server

visibility on entire history

Non-interactive key distribution

• set of pub/pri keys where private can be

selectively revealed without leaking others

• selective reveal x_i=MAC(code,i)*x fails

– assuming code is semi-public (untrusted sender)

• Weil-pairing / IBE schemes can meet this reqt
• User keeps identity master key

– x_i = keyGen( master-pri, i, identity=epoch ) – address = master-pub, one-use = epoch-id

• Allows delegation to link only within epoch

SPV bloom filter query

• Reduced b/w SPV mode, reduced trust model
• Bloom query model: send bloom filter with client

addresses to node.

– Size/privacy tradeoff: more false positives → better

privacy, but more blocks downloaded

• Current model deficient due to parameters

– Defacto links wallets almost immediately – tuned to low false positives; – Filter contains both Q and h(Q) triangulates

SPV bloom filter

• Block contains commitment to bloom filter

– Of addresses in block

• User downloads filters and offline queries
• User downloads selected blocks or transactions

Q: Better SPV model?

• Is there a better privacy SPV model?
• Supporting store and forward sending
• Encrypted search?
• Efficient PIR?

Cryptographic blinding

• Sander & Ta-Shma '99 auditable anon e-cash
• Green, Miers et al zerocoin '13

– ZK set-membership proofs – Cut & choose – Large 20-40kB – RSA accumulator trapdoor – One denomination (subsequently generalised to

multi?)

Cryptographic Blinding2

• Ben-Sassoon et al zerocash ZK-SNARK based

– Compact, efficient to verify – Relatively expensive to create proofs – Relatively large CRS (GB+) – Trapdoor with non-graceful failure

• Q: Alternative compact set-membership?

– No trapdoor – Efficient – Conservative crypto

SNARKs

• ZK contingent payment by Maxwell & Bowe '16

– Buyer does setup, proves E(k,verifier),x=H(k)

• Use SNARK contracts

– Contract & satisfying terms private between parties

• Make the chain validation code itself be SNARK

proven (large program, unclear if practical)

– Elevates SPV nodes to full-node security

• Q: better SNARKs?

– Efficient enough to validate chain – No trapdoor, conservative crypto assumptions

Additive security & SNARKs

• Additive uses without conservative crypto
• If efficient enough could have SPV model with

SNARKs chain validation but still fall-back to miner assertion in event of crypto break.

• Compact proof of chain of hashes
• Q: other additive models for SNARKs?

Signature aggregation

• Signatures are 60% of transaction space
• Schnorr being proposed for compact n of n
• Batch validation
• multisig across inputs (up to 33% smaller)
• With Coinjoin (up to 50% smaller transactions)
• Q: More compact sigs, privacy preserving

aggregation?

coinjoin

• Maxwell coinJoin '11
• Observation that transaction inputs can belong

to different users, can combine transaction paying same outputs but with payer ambiguity

• Blinding can be used to hide mapping from

server (prove signer is a participant)

• Various protocols to to prevent cheating

– Or stalling protocol

• Q: Compact ring signature

Confidential transactions

• Additive homomorphism of Pedersen

commitments, however mod n problem...

• ZK range-proof
• Maxwell '15 borromean ring sig
• 2.5kB proof number in range 0-2^32
• Maybe 2kB optimisation
• Q: compact range proof (related compact

ringsig)

Key tree compact threshold

• Key tree signatures Wuille & Maxwell '15
• Simple method to convert compact n of n

signature into log(n) sized k of n threshold

• Setup: merkle tree of k of n permutations
• Sig: merkle path plus n of n signature, to get

log(n) sized threshold sig

• must avoid Q=A+B+C where attacker knows DL
• f Q and chooses C st Q=A+B+C.
• eg Q=H(A)*A+H(A||B)*B+H(A||B||C)*C

Polysig dense threshold

• Polysig compact k ~ n threshold

– P={A+B+..+Z},Q={A+2B..

+26Z},R={A+2^2*B+...26^2*Z}

– 2P-Q omits B, 18P-9Q-C omits B & C – Supports k of n where n is too large to populate

merkle tree.

• Combine with merkle and more signers online,

lower threshold

• Q: more compact k of n threshold?