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 of 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?
Recommend
More recommend
