Decentralized Anonymous Micropayments

72 Pages·2016·0.8 MB·English

Decentralized Anonymous Micropayments
AlessandroChiesa MatthewGreen JingchengLiu
[email protected] [email protected] [email protected]
UCBerkeley JohnsHopkinsUniversity UCBerkeley
PeihanMiao IanMiers PratyushMishra
[email protected] [email protected] [email protected]
UCBerkeley JohnsHopkinsUniversity UCBerkeley
October31,2016
Abstract
Micropayments(paymentsworthafewpennies)havenumerouspotentialapplications.Achallengeinachieving
themisthatpaymentnetworkschargefeesthatarehighcomparedto“micro”sumsofmoney.
Wheeler(1996)andRivest(1997)proposedprobabilisticpaymentsasatechniquetoachievemicropayments:a
merchantreceivesamacro-valuepaymentwithagivenprobabilitysothat,inexpectation,hereceivesamicro-value
payment.Despitemuchresearchandtrialdeployment,micropaymentschemeshavenotseenadoption,partlybecause
atrustedpartyisrequiredtoprocesspaymentsandresolvedisputes.
ThewidespreadadoptionofdecentralizedcurrenciessuchasBitcoin(2009)suggeststhatdecentralizedmicropay-
mentschemesareeasiertodeploy.PassandShelat(2015)proposedseveralmicropaymentschemesforBitcoin,but
theirschemesprovidenomoreprivacyguaranteesthanBitcoinitself,whosetransactionsarerecordedinplaintextina
publicledger.
Weformulateandconstructdecentralizedanonymousmicropayment(DAM)schemes,whichenablepartieswith
accesstoaledgertoconductofflineprobabilisticpaymentswithoneanother,directlyandprivately.Ourtechniques
extend those of Zerocash (2014) with a new privacy-preserving probabilistic payment protocol. One of the key
ingredientsofourconstructionisfractionalmessagetransfer(FMT),aprimitivethatenablesprobabilisticmessage
transmissionbetweentwoparties,andforwhichwegiveanefficientinstantiation.
Doublespendinginoursettingcannotbeprevented.Oursecondcontributionisaneconomicanalysisthatbounds
theadditionalutilitygainofanycheatingstrategy,andappliestovirtuallyanyprobabilisticpaymentschemewith
offlinevalidation.Inourconstruction,thisboundallowsustodeterdoublespendingbywayofadvancedepositsthat
arerevokedwhencheatingisdetected.
Keywords:decentralizedcurrencies;micropayments;probabilisticpayments;anonymity;Bitcoin
1
Contents
1 Introduction 3
1.1 Ourcontributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Priorworkonmicropaymentchannels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 Roadmap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Techniques 9
2.1 Constructingdecentralizedanonymouspayments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Intuitionforoureconomicanalysisofdoublespending . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Economicanalysisofdoublespendingforofflineprobabilisticpayments 13
3.1 Informaldescriptionofpaymentdynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Thegameanditsanalysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Interpretingthepaymentvaluerates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Efficientfractionalmessagetransfer 20
5 Recallingdecentralizedanonymouspayments 22
5.1 Datastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3 Merkletreesonallcoincommitmentsandallserialnumbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4 ExtensionoftheDAPinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6 Definitionofadecentralizedanonymousmicropaymentscheme 26
6.1 Datastructures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3 Guidelinesforusage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
7 Constructionofadecentralizedanonymousmicropaymentscheme 35
7.1 Informaldescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.2 Buildingblocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.3 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.4 Securityoftheconstruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A Fractionalmessagetransfer 47
A.1 Definitionofafractionalmessagetransferscheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.2 Constructionofafractionalmessagetransferscheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
A.3 Definitionofafractionalmessagetransferprotocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.4 Constructionofafractionalmessagetransferprotocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
B Securityofdecentralizedanonymouspaymentsystems 57
B.1 Auxiliaryalgorithmsandnotions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
B.2 Securitydefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
B.3 SecurityofexistingDAPconstructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C SecurityofourDAMconstruction 61
C.1 Ideal-worldadversaryS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.2 Proofofsecuritybyhybridargument . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
References 70
2
1 Introduction
Weformulateandconstructdecentralizedanonymousmicropayments,bywayofprobabilisticpayments.
Micropayments. A micropayment is a payment of a small amount, e.g., a fraction of a penny [Whe96, Riv97].
Micropayments have many potential applications, including advertisement-free content delivery, spam protection,
rewardingnodesofP2Pnetworks,andothers. Achievingmicropaymentsinvolvesatleasttwomainchallenges. First,
paymentprocessingfeesdwarf“micro”paymentvalues.Second,micropaymentapplicationsoftenrequirefastmerchant
responses,which,inmanysettings,areachievedviaofflinepayments,whicharevulnerabletodoublespending.
Probabilisticpayments. Atechniquetoreduceprocessingfeesistoamortizethemovermultiplepaymentsbyway
ofprobabilisticpayments[Whe96,Riv97].1 TheseareprotocolsthatenableacustomertopayV unitsofcurrency
toamerchantwithprobabilityp: withprobability1−pthemerchantreceivesanullpaymentthatisnotprocessed,
andwithprobabilitypthemerchantreceivesamacropaymentthatisprocessed. Inexpectation,themerchantreceives
pV unitspermicropayment,buttheoverheadandprocessingfeesofthese“lotterytickets”isptimessmallerasonly
theinfrequentlygeneratedmacropaymentsareactuallyhandledbythepaymentnetwork. Constructingprobabilistic
paymentsisanareaofongoinginterestincryptography.
Centralizedvs.decentralizedsystems. Despiteextensiveresearchandtrialdeployments[Whe96,Riv97,LO98,
MR02,Riv04,Mic14],micropaymentschemeshavenotseenwidespreadusage. Thisisperhapsduetothembeing
centralizedsystems: atrustedthirdpartyistaskedwithprocessingpaymentsandpunishingcheaters. Appointingsucha
partyraisesdeploymentcosts,requiresestablishingcomplexbusinessrelationshipsbetweenallinvolved(thetrusted
party,merchants,andcustomers),andmakesparticipationconditionaloncertainrequirementsbeingmet[vOR+03].
Recentworkindigitalcurrencieshasfocusedondecentralizedsystems,asthecostofentryanddeploymentappears
tobelower. ThemostnotablesuchcurrencyisBitcoin[Nak09],awidelyadoptedpeer-to-peerpaymentsystem. Unlike
traditionalbankingande-cashschemes[Cha82,CHL05,ST99]wheretransactionsareprocessedbyatrustedparty,
Bitcoinutilizesadistributedpublicledgerknownastheblockchaintostorealltransactions; thesetransactionsare
verifiedbynetworknodesinapeer-to-peerfashion.
Decentralizedsystemsarethuspotentiallyattractiveformicropayments,becausetheoverheadinvolvingtrusted
partiesisnolongerafactor. However, Bitcoinprocessingfeesarestillrelativelyhigh(asofMay2016thefeefor
a1kB-transactionis≈ $0.20), withpresentfeesbelievedtobewellbelowthecostofperformingatransactionon
theBitcoinnetwork[MB15]. Thus,feeamortizationisstillnecessary. Caldwell[Cal12]firstsketchedprobabilistic
paymentsforBitcoin. Recently,PassandShelat[PS15,PS16]alsoproposedthreeprobabilisticpaymentschemesfor
Bitcoin,where,informally,thecustomerfirstputsV bitcoinsinescrow,andthenthecustomerandmerchantengagein
acoin-flippingprotocolthatallowsthemerchanttoretrievetheescrowwithprobabilityp. Theirthreeschemesdifferin
howpaymentsareprocessedandhowdisputesareresolved.
Ourprivacygoalandlimitationsofpriorwork. Westudythequestionofhowtoconstructdecentralizedanonymous
micropaymentsviathetechniqueof(offline)probabilisticpayments. Theaforementionedpriorwork[PS15,PS16]
providesnomoreprivacythantheunderlyingBitcoinprotocol. AndBitcoinitselfprovideslittletonoprivacybecause
everytransactionispubliclybroadcastandcontainsapayment’sorigin,destination,andamount;auser’spayment
history is thus readily available to any passive observer who can can link pseudonyms together or to real world
identities.2 Thislackofprivacyisparticularlydangerousformicropaymentapplicationsbecausetheytypicallyinvolve
high-volumepattern-richpayments(e.g.,per-clickpaymentswhilesurfingtheweb),andsometimesnecessitateuser
anonymity(e.g.,bandwidthpaymentsforTorrelays[BP15]).
Privacyisnotmerelyanissueofindividualusers: ifeachcoin’shistoryispublic,acustomermaynotbeableto
spendacoinatits‘declared’valueduetoitspast. Forexample,amerchantmaynotacceptcoinswhosepastowners
includecertainpoliticalorganizations. Privacythusensuresafundamentalpropertyofthecurrency: fungibility,which
meansthatanytwosetsofcoinswiththesame‘declared’totalvalueareinterchangeable,regardlessoftheirprovenance.
Priorworkonprivacy-preservinganaloguesofBitcoin[MGGR13,DFKP13,BCG+14]doesnotachieveprobabilis-
ticpayments,andmerely“plugging”theseschemesinto[PS15,PS16]’sapproachresultsinsubtleproblems. Consider
thefollowingnaturalmodificationtoPassandShelat’scoin-flippingprotocol: insteadofaBitcointransaction,the
1Anothertechniqueismicropaymentchannels,whichwediscussinSection1.2.
2Thisisnotmerelyatheoreticalconcern:extractinginformationfromBitcointransactionsisthesubjectofappliedresearch[RH11,BBSU12,
RS13,MPJ+13]andcommercialventures[Ell13,Blo14,Cha15].
3
senderprobabilisticallytransmitstothemerchantaZerocashtransaction[BCG+14]. Despitethestronganonymity
guaranteesprovidedbyZerocash,merchantsstilllearninformationabouttheircustomers’spendinghabits,because
eachZerocashtransactionincludesauniqueserialnumbercorrespondingtothespent“coin”. Sincethecustomersends
tothemerchantinformationabouttheescrow,thisserialnumberisrevealedineachmicropayment. Sincethesame
escrow is used across multiple probabilistic payments (to amortize fees), privacy of the customer is compromised
becausethemerchantlearns (1)which(macroornull)paymentstohimweremadewiththesameescrow;and(2)which
macropaymentstoothermerchantsweremadewithanescrowusedforpaymentstohim.Thisbreachofprivacyworsens
ifmerchantsshareinformationwithoneanother. Insum,whiletheabovenaturalapproachachieves“macropayment
unlinkability”,micropaymentsarestilllinkable,andthuscustomershavelittleprivacy.
Doublespendinginofflineprobabilisticpayments. Micropaymentapplicationsoftenrequirefastresponses. In
manysettings,theseinturnrequireofflinevalidation: amerchantrespondstoapaymentafteronlyalocal“offline”
check,becausehecannotwaitforthepaymentnetworktovalidatethepayment(thisvalidationinsteadcompletesafter
themerchant’sresponse). Forexample,validationtakesafewminutesinBitcoin,whilerespondingtounconfirmed
zero-conftransactionstakesonlyafewseconds. Wethusfocusonofflineprobabilisticpayments.
However,suchpaymentsarevulnerabletodoublespending,aswenowexplain. First,doublespendingcannotbe
preventedforofflinepayments,because,topreventit,amerchantwouldhavetorefrainfromrespondingtoanypayment
beforeallpaymentsupto,andincluding,thispaymenthavebeenvalidated. Onefallbackistodetectandpunishall
double-spendingcustomers. However,forofflineprobabilisticpayments,notalldoublespendingcanevenbedetected.
Indeed,therearetwotypesofdoublespendingwhenusingthesamelotteryticketintwoprobabilisticpayments:
(1)bothpaymentsresultinmacropayments;or(2)thefirstpaymentresultsinamacropayment(thereby‘consuming’the
ticket)whilethesecondpaymentresultsinanullpayment. Whiledetectingthefirsttypeiseasy,detectingthesecond
typerequiresthepaymentnetworkto‘know’thetemporalorderofallpayments,becausewhetherthenullpaymentorthe
macropaymentoccurredfirstdetermineswhetherthetwopaymentscorrespondtohonestbehavior(nullpaymentfirst)or
not(macropaymentfirst).Butknowingtheglobalorderofallpayments(withhighprecision)isastrongsynchronization
propertythatisunrealisticinmanydecentralizedsettings, includingthatofBitcoin, becauseinformationdoesnot
instantlyreacheveryoneinthenetwork.
Given that not all double spending can be detected, the “detect-and-punish” approach is effective only if the
disadvantagesofbeingpunished(upondetection)outweightheadvantagesofdoublespending. Thismaybeplausible
inthecentralizedsetting,wherecustomershaveregisteredwithatrustedpartythatcanpermanentlybanandlegally
prosecutethem. Inthedecentralizedsetting,however,banninghasfewconsequences,ifany: anyonecanabandonold
identitiesandusefreshnewidentitiesintheirplace.
Ruffing,Kate,andSchro¨der[RKS15]introduce“accountableassertions”,whichenabletimelockeddepositsin
Bitcointhatarerevokeduponevidenceofdoublespending. PassandShelat[PS16]alsosuggestaBitcoin-specific
penaltymechanismtodeterrationalcustomersandmerchantsfromcheating.3 Unfortunately,bothoftheseworksdo
notprovideaneconomicanalysistoindicatehowlargeapenaltyshouldbetodeterdoublespending. Suchananalysis
iscrucial: howcoulddetect-and-punishbeadeterrentifdoublespendingweretoyieldunboundedadditionalutility?
1.1 Ourcontributions
Weovercometheaforementionedlimitationsviaacombinationofcryptographicandeconomictechniques. Weadopta
“detect-and-punish”approachinwhichcryptographyisusedtoretroactivelydetectandeconomicallypunishdouble
spendingand,separately,aneconomicanalysisclarifieshowmuchtopunishsoastodeterdoublespendinginthefirst
place. Moreprecisely,wepresentthefollowingthreecontributions.
1.1.1 Economicanalysisofdoublespendingforofflineprobabilisticpayments
Wecharacterizetheadditionalutilitythatcanbegainedbydoublespendingviaofflineprobabilisticpayments. We
supposethat: (i)everyprobabilisticpaymentisbackedbyanadvancedeposit;4(ii)allmacropaymentdoublespends
3Wealsonotethattwoofthethreeschemesin[PS15]donotsupportofflinepayments,andtheremainingoneonlyprovides“fastonlinepayments”
whereanonline(publiclyverifiable)trustedpartyassiststheledgerbyprocessingmacropaymentsfaster.
4Onedepositmaybackmultiplepayments;inparticular,anhonestcustomermayuseasingledeposittobackallofhispayments.
4
canbedetected;and(iii)ifamerchantdetectsadoublespendthenhereportsit,anddoingsoresultsintherevocation
ofthecheatingcustomer’sdeposit. (Ourcryptographicconstructionswillprovidesuitablemechanismsforthesetasks.)
Wethenask: howlargemustthedepositbeinordertodeterdoublespending?
Weprovideasimpleyetpowerfulanalysisthatanswersthisquestionunderreasonablenetworkbehavior. Namely,
let T denote the time it takes to catch a macropayment double spend (e.g., in Bitcoin one could take T to be the
network’sbroadcasttime). WithinanyperiodoftimeT,letAdenotethemaximumcumulativevalueofprobabilistic
paymentsandW themaximumcumulativevalueofmacropayments;ouranalysiswillshowthatimposingbounds
onthesequantitiesisnecessary. Tosimplifydiscussions,wemaketheassumptionthatonlymacropayment(andnot
nullpayment)doublespendsaredetectable;ouranalysisextendstothecasewherenullpaymentdoublespendsmayalso
bedetectedeventually(seeRemark3.5).
Belowweinformallystateourtheorem,forsimplicityinthespecialcasewherethemacropaymentvalueV andthe
paymentprobabilityparefixedacrossallprobabilisticpayments,andallmerchantssharethesamedetectiontimeT.
Theformalstatementthatweproveisinfactmoregeneral,becauseitappliesevenwhenthesequantitiesarechosen
dynamicallyandarbitrarilyacrossdifferentpayments.
Theorem1.1(informalstatementofThm.3.4).
(a) IfthedepositisatleastW,thenthereisnoworst-caseutilitygainindoublespending.
(b) Ifthedepositisatleast(1−p)V +A,thenthereisnoaverage-caseutilitygainindoublespending.
(c) Bothboundsabovearetight.
Ourtheoremhasasimpleinterpretation: therequireddepositamountequalsthemaximumfinancialactivitythat
canhappenwithinanytimeperiodofT. Namely,ifmacropaymentshavemaximumtotalworthW withintimeT,the
depositmustbeatleastW (w.r.t. worst-caseutility);andifprobabilisticpaymentshavemaximumtotalworthAwithin
timeT,thedepositmustbeatleast≈A(w.r.t. average-caseutility). Notethatitisunsurprisingthatthetwostatements
inthetheoremdependonthetwodifferentquantitiesW andA,becausetheytargetdifferentnotionsofutility;also
notethat,whileonecantakepW ≤Awithoutlossofgenerality,aboundonW doesnotalwaysimplyaboundonA
(therecouldstillbearbitrarilymanyprobabilisticpayments,thoughwithextremelysmallprobability).
Butwhichofthetwoboundsshouldoneuseinpractice? Naturally,theworst-caseboundissaferthantheaverage-
casebound;however,anappropriatesettingofW willbeΩ(1/p)largerthanA,whichimpliesasubstantialincreasein
therequireddeposit. Thechoicebetweenthetwodependsonwhetheronecaresaboutmaliciouscustomersthatare
luckywithevenverysmallprobability(asopposedtofocusingontheiraveragegainspossiblyacrossmanydeposits).
Asalreadymentioned,boundingthevalueofprobabilisticpayments(viaA)ormacropayments(viaW)within
timeT isnecessarybecauseourboundsaretight(i.e.,thereexistdouble-spendingstrategiesthatachievethem). Inthe
“realworld”theseboundsmaybeimposedbytheenvironment(e.g.,limitednetworkthroughput),orthemerchants
(e.g.,theyacceptuptoagivennumberofpaymentswithintimeT).
In terms of analysis, our proof shows that any additional utility gained via double spending must come from
macropaymentdoublespending. Thismaybesurprisingbecause,superficially,onemaythinkthatnullpaymentdouble
spending also contributes to additional utility; e.g., one may think that a malicious customer gains pV for every
nullpaymentdoublespend. Thispropositionisalarming: intheworstcasetherecouldbeinfinitely-manynullpayment
doublespends(whichimplyinfiniteadditionalutility);andintheaveragecasetherecouldbecleverstrategiesthat
leveragedoublespendsacrossmultiplemerchantstolowertheprobabilityofdetection. Weprovethatthisisnotthe
case: weuseasimulationargumenttoshowthatthenaivestrategyofdoublespendingasmuchaspossibleisthebest
strategy(i.e.,maximizesadditionalutility),bothintheworstcaseandintheaveragecase. Inparticular,welearnthat
thebeststrategyalwaysleadstodetection(afteratimeperiodofT)andthatadditionalutilityisfiniteevenintheworst
case(ifW isfinite). DetailsofouranalysisareinSection3.
Webelieveourtheoremtobeofindependentinterestbecauseitappliestovirtuallyany(centralizedordecentralized)
settingthatenforcesadepositmechanismforofflinepayments. Onesuchsettingcouldbeprobabilisticsmartcontracts
(anapplicationsuggestedby[PS15,PS16]). Athoroughunderstandingoftheeconomicbenefitsofdoublespendingis
necessarytoensurethatsuchsmartcontracts,aswellasotherapplications,functionasintended.
Example. Asademonstration,weinvokeourtheoremonparametersthatcouldfittheapplicationofadvertisement-free
contentdelivery,toseewhatconclusionsoureconomicanalysisgivesus. SupposethatweconsideraBitcoin-like
setting,where (i)transactionfeesaretypicallyafewcents;and(ii)wecouldtakethedetectiontimeT tobe,e.g.,20
5
minutes,whichistypicallytwoblocks(idealblockgenerationfollowsanexponentialdistributionwithameanof10
minutes). SupposefurtherthatwefixthedeposittobeD :=$200andtheexpectedvalueoftheprobabilisticpayment
tobe$0.1(similarsizeasatransactionfee);concentrationboundsthensuggestthat,subjecttotheconditionpV =$0.1,
goodchoicesareV :=$10andp:=1%. NotethatthesesettingsimplythatwecantakeW uptoD =$200andA
uptoD−(1−p)V = $190.1. Thenourtheoremimpliesthat: (1)Eventheluckiestdoublespendinguserhasno
extrautilitygainifthecumulativevalueofmacropaymentsevery20minutesislessthan$200(thatis,thenumber
ofmacropaymentsevery20minutesislessthan20),regardlessofhowmuchnullpaymentdoublespendingoccurred.
(2)Adoublespendinguserhasnoextrautilitygainonaverageifthecumulativevalueofprobabilisticpaymentsevery
20minutesislessthan$190.1(thatis,thenumberofprobabilisticpaymentsevery20minutesislessthan1901).
1.1.2 Decentralizedanonymousmicropayments
Weformulatethenotionofadecentralizedanonymousmicropayment (DAM)scheme. Thisnotionformalizesthe
functionalityandsecuritypropertiesofanofflineprobabilisticpaymentschemethatenablespartieswithaccesstoa
ledgertoconducttransactionswithoneanother,directlyandprivately. Torealizetherequirementsofoureconomic
analysis,aDAMschemeenablespartiestosetupdeposits,whicharerevokedwhenmacropaymentsrevealthatdouble
spendinghasoccurred. Crucially, thesecurityguaranteesofaDAMschemeguaranteeanonymitynotonlyacross
macropaymentsbutalsoacrossnullpayments,sothateventhe“offlinestreamofpayments”remainsunlinkable.
We construct a DAM scheme and prove its security under specific cryptographic assumptions. Our two main
buildingblocksaredecentralizedanonymouspayment(DAP)schemes[BCG+14]andfractionalmessagetransfer
schemes(seebelow).
Theorem1.2(informalstatementofThm.7.1). Givenadecentralizedanonymouspaymentschemeandafractional
messagetransferscheme(andotherstandardcryptographicprimitives)thereexistsaDAMscheme.
FormallycapturingthenotionofaDAMschemeandprovingsecurityofourconstructionwasquitechallengingdue
tothecombinationofrichfunctionalityandstronganonymityguarantees. Partiescanmintstandardcoins,deposits,or
lotterytickets;theycanwithdrawdeposits;theycanpayeachotherwithdeterministicpayments,switchcointypes;they
canalsopayeachotherwithprobabilisticpayments;theycanrevokedepositsofcheatingparties—allofthiswhile
essentiallyrevealingnoinformationaboutorigins,destinations,andamountsofmoneytransfers. Inparticular,two
featuresofourconstructionrequiredparticularattention: (1)revocationofanunknowncheatingparty’sdepositwhen
twomacropaymentswiththesameticketaredetected;and(2)monitoringofpaymentvaluerates(asrequiredbyour
economicanalysis)despitedepositsbeinganonymous. Deterministicpaymentsinourconstructionarenon-interactive,
whileprobabilisticpaymentsconsistofa3-messageprotocolbetweenasenderandareceiver;itisaninterestingopen
questionwhetherthesecanbemadenon-interactiveaswell.
WeexpressthesecurityofaDAMschemeviatheideal-world/real-worldparadigm,specifyingasuitableideal
functionality,andweproveourconstruction’ssecurityviaasimulatoragainstnon-adaptivecorruptionsofparties. We
considersecurityinthestandalonesetting,andleavesecurityundercompositiontofuturework(thatperhapscanbuild
upontheworkof[KMS+16]).
1.1.3 Fractionalmessagetransfer
AkeyingredientinourconstructionofDAMschemesisfractionalmessagetransfer(FMT):aprimitivethatenables
probabilisticmessagetransmissionbetweentwoparties,calledthe‘sender’andthe‘receiver’. Informally,FMTworks
as follows: (i) the receiver samples a one-time key pair based on a transfer probability p; (ii) the sender uses the
receiver’spublickeytoencryptamessagemintoaciphertextc; (iii)thereceiverusesthesecretkeytodecryptc,
therebylearningm,butonlywiththepre-definedprobabilityp(andotherwiselearnsnoinformationaboutm).
Wethus (1)formulatethenotionofanFMTscheme,whichformallycapturesthefunctionalityandsecurityof
probabilisticmessagetransmission,and(2)presentanefficientconstructionthatworksforprobabilitiesthatareinverses
ofpositiveintegers.
Theorem1.3(informalstatementofThm.A.3). IntherandomoraclemodelandassumingthehardnessofDDHin
prime-ordergroups,thereexistsanFMTschemethatworksfortransferprobabilitiesp=1/nwithn∈N. Moreover,
thenumberofgroupelementsandscalarsinthepublickeyandciphertextisconstant(independentofn);seeTable1.
6
OurdefinitionofFMTiscloselyrelatedtonon-interactivefractionaloblivioustransfer(NFOT),whichwasstudied
inthecontextof‘translucentcryptography’asanalternativetokeyescrow[BM89,BR99]. Namely,priordefinitions
targetone-waysecurity,whichprotectsrandommessages. Whileone-waysecuritysufficestoencapsulaterandom
secretkeys(thesettingoftranslucentcryptography),itdoesnotsufficeforprobabilisticallytransmittingnon-random
messages(asneededinourconstruction). Therefore, ourdefinitionofanFMTschemetargetsafractionalvariant
ofsemanticsecurity, whichweexpressviatwoproperties: fractionalhidingandfractionalbinding. Furthermore,
sinceinoursystemanypartycanactasbothsenderandreceiver,werequiretheFMTschemetobecomposable. Our
constructionachievesthisviasimulation-extractability.
OurconstructionofFMTislooselyrelatedtotheconstructionsin[BM89,BR99],which(likeourconstruction)
buildontheElgamalencryptionscheme[Elg85]. Infact,suchconstructions,ifanalyzedunderthehardnessofDDH
ratherthanCDH,arelikelytoyieldFMTaccordingtoourstrongerdefinition. Wedidnotcarryoutsuchananalysis,but
insteadchosetoconstructaschemethatismoreefficientthanpriorworkforthecaseofp=1/n(theseprobabilities
suffice for our application); we assume hardness of DDH and work in the random oracle model in order to take
advantageofcertainΣ-protocols. SeeTable1foracomparisonofourconstructionwithpriorwork.
SeeSection4andAppendixAformoredetails.
transfer sizeofpublickey sizeofciphertext #exponentiations
scheme security assumption
probability groupelts. scalars groupelts. scalars toencrypt todecrypt
[BM89] one-way CDH 1/2 2 — 2 — 2 1
[BR99,§5.1] one-way CDH 1/n n — 2 — 2 1
[BR99,§5.1] one-way CDH (n−1)/n n — 2 — 2 1
[BR99,§5.2] one-way CDH a/n* 2log n — 2log n — 4log n 2log n
2 2 2 2
[BR99,§5.3] one-way CDH a/n a+n — 2 — 2 1
ourFMT semantic DDH+RO 1/n 2 3 2 2 4 4
∗nisrestrictedtobeapowerof2.
Table1:ComparisonofpriorNFOTschemesvs.ourFMTscheme.Allconstructionsassumeacommonrandomstring.
1.2 Priorworkonmicropaymentchannels
MicropaymentchannelswereintroducedbyHearnandSpilman[HS12,Bit13],andfurtherstudiedbyPoonandDryja
[PD16] and Decker and Wattenhofer [DW15]. Roughly, a micropayment channel enables a sender and a receiver
tosetupacontractbywayofanonline(slow)transactionthatescrowsfunds, afterwhichthesenderandreceiver
canupdatethecontract,andthustherelativesplitoftheescrowedfunds,withoutrecordingthenewcontractonthe
blockchain. Thuspaymentscanbemadeinstantaneously. Thesecanbedynamicallycombinedtoobtainmulti-hop
“paymentchannelnetworks”thatgothroughseveralintermediaries,byusinghashedtimelockcontracts;thistechnique
amortizesthecostofsettingupanewchannelfornewreceivers. Fromtheperspectiveofourwork,micropayment
channelshaveseverallimitationsintermsofeconomics,functionality,andprivacy.
Economiclimitationsofpaymentchannels. First,paymentchannelsingeneralrequireachanneltobeestablishedin
advancewithaparty: paymentsareonlyinstantaneouswithadvancedpreparation. Toalleviatethisconstraint,payment
channelnetworksallowtransactionswitharbitrarynewpartiesprovidedthereexistsapathofexistingchannelsbetween
thepayerandpayee.
Suchnetworkshavelimitations. First,considerablecapitalisescrowedinthemanypairwisechannelsforming
thenetwork. Thecapitalrequirementsmayexceedthoserequiredfordepositsinprobabilisticmicropayments. Both
settingsrequireescrowedfundsproportionaltoauser’seconomicactivity(eitherforthedoublespenddepositorthe
“lastmile”channelbetweentheuserandthepaymentnetwork),butpaymentchannelnetworksescrowsimilaramounts
ineachedgeofthenetwork. Second,avarietyofpressures,includingminimizingthecapitalescrowed,maycentralize
suchnetworksintoahub-and-spokemodel.
Privacylimitationsofpaymentchannels. Paymentchannelsrevealtotheworldthatagivenpairofpartieshavea
channelbetweenthem,theopeningvalueofthatchannel,andthefinalclosingvalue. Moreimportantly,especiallyfor
7
applicationslikeadvertisement-freecontentdelivery,paymentchannelsprovidenoprivacybetweenthepartiesonthe
channel: ifAlicepayssayWikipediaeverytimesheviewsapage,theneachofthoseviewsislinkedtothechannelshe
establishedjustaseffectivelyasifshehadatrackingcookieinherbrowser.
Attemptstoaddprivacy,eitherfromintermediatenodesinthenetwork[HAB+16]orfromrecipientsandintermedi-
aries[GM16],topaymentchannelshitsomeseeminglyfundamentallimitationsofthepaymentchannelsetting. First,
theanonymitysetwhenpayingagivenreceiveriscomposedonlyofthoseuserswhohaveopenedchannelswiththe
receiver. Thisislikelyfarsmallerthantheglobalanonymitysetprovidedbyprobabilisticpayments. Moreover,the
receivingpartycanarbitrarilyreducetheanonymitysetfurtherbyclosingchannels. Thisleavesopenarangeofattacks
thatarenotpresentinasystemwithaglobalanonymityset.
Finally it is unclear if non-hub-and-spoke private payment networks are scalable or can provide privacy for
payment values from intermediary nodes in the network. When a payment is made via two intermediaries (i.e.
A → I → I → B),somecombinationofI andI mustknowthebalanceoftheirpairwisechannelatanygiven
1 2 1 2
timeortheycouldnotclosethechannel. Thusthevalueofanypaymentrelayedthroughmultiplepartiescannotbe
completelyprivate. Moreover,discoveringamulti-hoproutebetweentwopartiesinadiverseandlargenetworkwithout
leakinganyidentifyinginformationseemscostlyatscale. While[GM16]extendtheirpoint-to-pointchannelprotocol
toahub-and-spokemodelthatalleviatesboththeseconcerns,suchanetworkisinherentlycentralized.
1.3 Roadmap
Theremainderofthepaperisorganizedasfollows. InSection2wedescribetheintuitionandtechniquesbehindour
results. In Section 3 we present our economic analysis of double spending. In Section 4 we present our result on
fractionalmessagetransfer. InSection5werecallthenotionofaDAPschemefrom[BCG+14]. InSection6we
presentourdefinitionofaDAMscheme. InSection7wepresentourconstructionofaDAMscheme.
8
2 Techniques
Wediscusstheintuitionandtechniquesbehindourresults,firstforourcryptographicconstruction(Section2.1)and
thenforoureconomicanalysisofdoublespending(Section2.2).
2.1 Constructingdecentralizedanonymouspayments
We discuss our design of a decentralized anonymous micropayment (DAM) scheme via a sequence of candidate
constructions,eachfixingproblemsofthepreviousone;thelastoneisasketchofourconstruction.
2.1.1 Attempt1: non-anonymousprobabilisticpayments+DAP
WebeginwithanaturalcandidateconstructionforaDAMscheme.Theideaistocombinetwoprimitives,oneproviding
probabilisticpaymentsandtheotheranonymity. Forexample,consider: (1)theschemeMICROPAY1of[PS15],which
providesprobabilisticpaymentsforBitcoin;5and(2)adecentralizedanonymouspayment(DAP)scheme[BCG+14],
whichprovidesprivacy-preservingpaymentsforBitcoin-likecurrencies.
To make MICROPAY1 privacy-preserving, we could try to replace its Bitcoin payments with DAP payments,
whichhidethepayment’sorigin,destination,andamount. Thus,whenaprobabilisticpaymentgoesthrough,andthe
correspondingDAP(macro-)paymentisbroadcast,otherscannotlearnthisinformationaboutthepayment. However,
thisideadoesnotprovidethestronganonymityguaranteesthatweseek,aswenowexplain.
Problem:notfullyanonymous. DespitetheanonymityguaranteesprovidedbytheDAPscheme,merchantsstilllearn
informationabouttheircustomers’spendinghabits. EachDAPpaymentincludesauniqueserialnumbercorresponding
totheunderlying“coin”thatwasspentbythatpayment; thisisusedtopreventdoublespendingofDAPcoins. In
theaboveproposal,thecustomersendsthemerchantthisserialnumberregardlessofwhetherthepaymentbecomesa
nullpaymentoramacropayment. SincethesameunderlyingDAPpaymentandserialnumberareusedacrossmultiple
probabilisticpayments(toamortizefees),thiscompromisescustomeranonymitybecauseamerchantlearns (1)which
(macroornull)paymentstohimweremadewiththesameescrow;and(2)whichmacropaymentstoothermerchants
weremadewithanescrowusedforpaymentstohim. Thiscompromiseinanonymitygetsevenworseifmerchants
sharesuchinformationwithoneanother.
Moreover, recall (from Section 1.1) that it is not possible to prevent double spending in the setting of offline
probabilistic payments. Pass and Shelat note this in the full version of their paper [PS16], and propose adding a
‘penaltyescrow’totheschemeMICROPAY1;theescrowisburneduponevidenceofdoublespending. Butobservethat
anonymityforpenaltyescrowsposesasimilarchallenge: toprovethatapenaltyescrowisunspent,amerchantreveals
itsserialnumber,onceagainenablingmerchantstolinkprobabilisticpaymentsbylearningabouttheirescrows.
Overall,whiletheaboveideasdoachieveunlinkabilityofmacropayments,customershavelittlemeaningfulprivacy
untilnullpaymentsandescrowsarealsounlinkable.
2.1.2 Attempt2: committoDAPpayment+probabilisticopening+privatedepositcoins
Onewaytoaddresstheanonymityproblemsofthepreviousattemptistoensurethatthemerchantlearnstheserial
numberonlywhenthepaymentturnsintoamacropayment(and,conversely,learnsnothingotherwise). Then,toenable
theaforementionedpenaltyescrowmechanism,acustomercreatesaspecial‘deposit’coin.
Then,themodifiedprotocolworksasfollows: (1)thecustomersendstothemerchantacommitmenttoaDAP
paymentandtoa2-out-of-nshareofthedepositserialnumber;(2)thecustomerandmerchantengageinaprotocolthat
opensthecommitmentwithprobabilityp(openingthuscorrespondstoamacropayment,andnotopeningcorresponds
toanullpayment);(3)whenpublishingamacropaymenttotheledger,themerchantalsopublishesthesecretshare.
TheprobabilisticopeninghidestheserialnumberofthecoinintheDAPpaymentuntilamacropaymentoccurs,
andthesecretsharehidesthedepositserialnumberuntilamacropaymentdoublespendoccurs. Topunishadouble
spendingcustomer,themerchantobtains(fromthenetworkorfromtheledger)twosecretsharesofthedepositserial
5Theothertwoschemesof[PS15]relyonatrustedthirdpartyforassistingtheledgerinprocessingpaymentsorresolvingdisputes,whichmakes
ithardertoachievestronganonymityguarantees.
9
numberfromtwomacropaymentsandreconstructstheserialnumber. Hethenpublishesthistotheledger,thereby
blacklistingthedeposit.
Oneissuethatmustbeaddressedisensuringthatthesecretshareddepositserialnumbercorrespondstoavalid
deposit. Todothis,firstnoticethattherearetwokindsofblacklisteddeposits: thosewhoseserialnumberappearson
theledger(inprevious‘punish’transactions),andthosethathavebeenrevokedinthecurrentepoch. Theserialnumbers
ofthelatterkindarebroadcastacrossthenetwork,buthavenotyetappearedontheledger.
Topreventusersfromusingblacklisteddepositsofthefirstkind,acustomermustprovetothemerchantthathis
deposit’sserialnumberdoesnotappearontheledger(thiscanbedoneefficiently[MRK03]). Topreventuseofdeposits
ofthesecondkind,customersmustalsosendtothemerchantatagderivedfromthedeposit’sserialnumber. Since
anyonewithaccesstothisserialnumbercancomputethistag,merchantscandeduceifadeposithasbeenrevokedby
checkingifthistaghasbeencomputedwithablacklisteddeposit’sserialnumber. Thecustomeraccompaniesthetag
withazero-knowledgeproofthatthedepositusedforthistagisconsistentwiththeshareinsidethecommitment.
Theaforementionedproposal,however,isstillvulnerabletoattacks.
Problem: front-runningdepositrevocation. Whiledepositsareintendedtodeterdoublespending,customersmay
trytowithdrawadepositbeforeitisblacklisted,therebyrenderingpunishmentineffective.
Problem: merchantaborts. Attheendofthecommitmentopeningprotocol, themerchantcanrefusetoinform
thecustomerofwhetherornotthecommitmentwasopened. Thisposesaproblemforthecustomerbecauseifthe
commitmentwasinfactopened,themerchanthaslearnedtheserialnumberandashareofthedeposit,enablinghimto:
(i)trackthecustomerandlearnwhentheyspendthecoinwithanothermerchant,and(ii)revokethecustomer’sdeposit
afterthe(honest)customernextspendsthecoin,withanothermerchantorthesameone.
2.1.3 Outlineofourconstruction
The deposit mechanism described so far is insufficient to deter double spending. The problem is that there is no
restrictiononhowandwhencoinsusedforprobabilisticpaymentsandfordepositscanbetransferred;inparticular,a
cheatingcustomercandoublespendthesebacktohimselfwhileatthesametimeengaginginaprobabilisticpayment
withamerchant. Weaddressthisproblemby (i)partitioningcoinsintodifferenttypesdependingontheirdifferent
uses,and(ii)restrictingtransfersbetweencoinsdependingontheirtypes. Wenowoutlinehowwecarryoutthisplan.
First,weextendthenotionofaDAPschemetoallowuserstoassociatepublicandprivateinformationstringswhen
mintingacoin. Userscannowstoreacoin’stypeinitspublicinformationstring,andweallowthreetypesofcoins: in
additiontothe“standard”cointype,weintroducedepositsandtickets. Aticketisboundtoadepositbystoringthe
depositinsidetheticket’sprivateinformationstring. Wethushavethefollowingsemantics:
• CoinsareusedfordeterministicDAPpayments(whoseprocessingfeesarenotamortized).
• Depositsareusedtobackticketsandarerevokedwhentwomacropaymentsusingthesameticketaredetected.
• Ticketsareusedforprobabilisticpayments;everyticketisboundtoasingledepositatmintingtime,andcanbespent
providedthattheassociateddepositisvalid(i.e.,hasnotbetransferredtoacoin,orrevoked).
Wealsorestrictthesetofpossibletransactionsdependingonthetypesofcoinsinvolved,asfollows.
• Transactionswithcoins: Coinscanbeusedtocreateothercoins,deposits,ortickets. Inparticular,coin-to-coin
transactionspreservethedeterministicpaymentfunctionalityoftheunderlyingDAPscheme.
• Transactionswithdeposits: Deposit-to-cointransactionsletcustomerswithdrawdeposits,thoughnotimmediately,
sincethesetransactionsbecomeactiveonlyafteranactivationdelay∆ thatisaparameterofthesystem.
w
• Transactionswithtickets: Ticket-to-cointransactionsenableprobabilisticpayments;theyareassociatedwithasecret
shareoftheticket’sdepositandwithadeposit-derivedtagthatallowsmerchantstodetectthevalidityoftheticket’s
deposit. Ticket-to-tickettransactionsomitthesecretshareandtagand(likedeposit-to-cointransactions)become
activeonlyafteranactivationdelay∆ thatisaparameterofthesystem.
r
Restrictionsoninter-typetransactionsareachievedviaapourpredicatethatchecksthatinputandoutputcointypes
satisfytheaboverestrictions. Havingmadethesemodifications,wecannowresolvetheissuesofthepreviousproposal.
Preventingdeposittheft. Deposit-to-cointransactionsnowhaveadelayedactivation,socustomerscannolonger
withdrawdepositsbeforetheyareblacklisted,asmerchantshaveenoughtimetopostdepositrevocationstotheledger.
Recoveringfrommerchantaborts. Sincewecannotknowwhatistheutilitygainofamerchantforlearningabout
thespendingpatternsofacustomer,wecannoteffectivelydetermerchantabortsbyeconomicmeans. Instead,attheend
10