aboutsummaryrefslogtreecommitdiff
path: root/articles
AgeCommit message (Collapse)Author
2020-08-03cleanupFlorian Dold
2018-09-20.gitignoreFlorian Dold
2017-08-30mark errata properlyChristian Grothoff
2017-08-29Footnote but Christian wanted this elsewhereJeffrey Burdges
2017-08-29Actualy this part has nothing to do with BOLT being fragileJeffrey Burdges
2017-08-29Rephrase BOLT fixJeffrey Burdges
2017-08-29Errata: Statement about BOLT correctedJeffrey Burdges
Discussion : Christian & Florian, This is about the UI paper in SPACE, not the protocol paper with real crypto discussions. And the text in question never existed in the protocol paper. Ian, I'm the member of our team who looked into BOLT the most, mostly looking to see if any of the ideas helped us. I might manage to reconstruct more details later, but right now my description there sounds bizarre and wrong. In Taler, our denomination key expirations limit the exchange's liability to double its deposits, even in the case that its private keys are all compromised and used to create unbacked coins. In practice, offline ecash schemes lack this limit due to their decreased ability to rotate denomination keys. I do not see why I wrote that BOLT lacked this property: If I recall, both BOLT payment channel types are created with fixed initial value commitments. In particular, intermediaries have already committed the maximum funds they could transfer to each merchant. That would prevent unbacked transfers in the payment channel, and thus limit liability, even when the intermediary gets compromised. There is an anonymity cost if BOLT's approach limits the number of users in payment channels with each intermediary of course. I do not know if a compromised BOLT intermediary could complete payments to merchants while refunding customers, but even if so that's still not the sort of "unlimited" liability you get in offline ecash schemes. It's just the sort of 2x limit on liability that Taler provides. In BOLT, the x would be value committed to outgoing channels, while in Taler x is value deposited by customers, so I suppose the intermediary could technically be robbed of their money without seeing any incoming money. That's not "unlimited" though. It's limited by the intermediary's commitments to the network. I doubt I even thought about it this deeply though when I wrote that. I think once-upon-a-time I wanted to express some vague concern around intermediaries and anonymity sets in BOLT, but never thought about it clearly, and later managed to confuse myself with conventional ecash issues when discussing related work with Christian while we were writing this usability paper. Sorry for writing what appears to be nonsense! Jeff On Mon, 2017-08-28 at 21:10 +0200, Christian Grothoff wrote: > > -------- Forwarded Message -------- > Subject: bolt attack? > Date: Mon, 28 Aug 2017 18:49:43 +0000 > From: Ian Miers <imiers@cs.jhu.edu> > To: christian@grothoff.org <christian@grothoff.org> > > > > Hi, > Someone pointed me at a copy of your Taler paper from 2016 and pointed > out that it describes Bolt saying there "are numerous seemingly > fragile aspects of the BOLT protocol, including aborts deanonymizing > customers, *intermediaries risking unlimited losses,* and theft if a > party fails to post a refute message in a timely fashion." > > The unlimited loss to intermediaries comment surprised both them and > me. Are you referring to some specific attack or an issue involving > timeouts and delays? > > Thanks, > Ian
2016-10-01Minor tweaks to ui paperJeff Burdges
2016-09-22remove generated fileChristian Grothoff
2016-09-22Merge branch 'master' of git+ssh://taler.net/var/git/wallet-webexChristian Grothoff
2016-09-22cameraready editionChristian Grothoff
2016-09-14sort out libs / fix warningsFlorian Dold
2016-08-30define 3dsChristian Grothoff
2016-08-30krista passChristian Grothoff
2016-08-26Merge branch 'master' of git.taler.net:/var/git/wallet-webexJeff Burdges
2016-08-26Makefile for PlantUMLJeff Burdges
2016-08-26plantuml / autonumberFlorian Dold
2016-08-26url syntaxFlorian Dold
2016-08-26Merge branch 'master' of git+ssh://taler.net/var/git/wallet-webexChristian Grothoff
2016-08-26compressChristian Grothoff
2016-08-26put an actual fulfillment URL in the contractFlorian Dold
2016-08-26mergeChristian Grothoff
2016-08-26cutChristian Grothoff
2016-08-26js payment executionFlorian Dold
2016-08-26Merge branch 'master' of git+ssh://taler.net/var/git/wallet-webexChristian Grothoff
2016-08-26reorder figsChristian Grothoff
2016-08-26Rebuild PlantUMLJeff Burdges
2016-08-26fix URL againFlorian Dold
2016-08-26match contract examplesFlorian Dold
2016-08-26do not be so POST-specificChristian Grothoff
2016-08-26fix pay processChristian Grothoff
2016-08-26Merge branch 'master' of git+ssh://taler.net/var/git/wallet-webexChristian Grothoff
2016-08-26major edits of pay processChristian Grothoff
2016-08-26match offer URL with contract exampleFlorian Dold
2016-08-26include pay url in exampleFlorian Dold
2016-08-26clarify payment replayFlorian Dold
2016-08-26ClarificationsFlorian Dold
2016-08-25more editsChristian Grothoff
2016-08-25minor editsChristian Grothoff
2016-08-25Merge branch 'master' of git+ssh://taler.net/var/git/wallet-webexChristian Grothoff
2016-08-25more minor editsChristian Grothoff
2016-08-25Merge branch 'master' of git.taler.net:/var/git/wallet-webexJeff Burdges
2016-08-25Two referencesJeff Burdges
2016-08-25updates sec 1-3Christian Grothoff
2016-08-25Merge branch 'master' of git.taler.net:/var/git/wallet-webexJeff Burdges
2016-08-25Fig 7Jeff Burdges
2016-08-24fix bibChristian Grothoff
2016-08-24misc minor editsChristian Grothoff
2016-08-24Merge branch 'master' of git.taler.net:/var/git/wallet-webexJeff Burdges
2016-08-24use EUR and not KUDOS in the exampleFlorian Dold