aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2017-12-10fix German po bugFlorian Dold
2017-12-09manifest versionFlorian Dold
2017-12-09fix tippingFlorian Dold
2017-12-09implement new, optimized refresh protocolFlorian Dold
2017-12-08nicely show version if there is a mismatchFlorian Dold
2017-12-01do not interfere with page visibilityFlorian Dold
2017-12-01Revert "only hide page when doing payment"Florian Dold
This reverts commit f438305b6e207bfcec8f0d3019c10d146210fd21.
2017-12-01only hide page when doing paymentFlorian Dold
2017-12-01partial implementation of tippingFlorian Dold
2017-11-23catching more TimeoutException(s)Marcello Stanisci
2017-11-22catching timeout exceptionMarcello Stanisci
2017-11-02bundling args in a classMarcello Stanisci
2017-11-02abort() doesn't log anymoreMarcello Stanisci
2017-11-02instantiating and using_one_ wait object, plusMarcello Stanisci
porting all DOM operations to use waits.
2017-11-02finishing to fix returned values from SeleniumMarcello Stanisci
routines, plus general simplification of code.
2017-11-02withdraw returns booleanMarcello Stanisci
2017-11-02indentMarcello Stanisci
2017-11-02experimenting with logsMarcello Stanisci
2017-10-29increse selenium timeoutFlorian Dold
2017-10-29print browser log on selenium pay failureFlorian Dold
2017-10-18version 0.4.0v0.4.0Florian Dold
2017-10-18changelogFlorian Dold
2017-10-18versionFlorian Dold
2017-10-17fix page titleMarcello Stanisci
2017-10-17selenium wrong class attributeMarcello Stanisci
2017-10-17remove broken linkFlorian Dold
2017-10-17fix history rendering issue caused by i18nFlorian Dold
2017-10-17tsconfigFlorian Dold
2017-10-15remove incomplete memory IDB implementation for nowFlorian Dold
Currently lives in its own branch, will be re-added to master once complete to avoid linting issues.
2017-10-15fix tslint warningsFlorian Dold
2017-10-15add missing typeof, makes unit tests passFlorian Dold
2017-10-15derive history from db instead of storing itFlorian Dold
2017-10-14gitignoreFlorian Dold
2017-10-14update dependenciesFlorian Dold
2017-08-30compute full fees for refresh and spendingFlorian Dold
2017-08-30don't stop injection earlyFlorian 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-29Merge branch 'master' of ssh://taler.net/wallet-webexJeffrey 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
2017-08-27version bump: 0.4.0-pre1Florian Dold
2017-08-27show error in create reserve dialogFlorian Dold
2017-08-27proper rounding for amount operationsFlorian Dold
2017-08-27make sure that refreshing works after refundFlorian Dold
2017-08-27canonicalize account info JSON when collecting themFlorian Dold
2017-08-27node_modulesFlorian Dold
2017-08-27better error report / retry prompt for failed paymentsFlorian Dold
2017-08-27implement refundsFlorian Dold