Commit Graph

3454 Commits

Author SHA1 Message Date
Florian Dold
289d2cb572
do not interfere with page visibility 2017-12-01 03:20:57 +01:00
Florian Dold
df8ddcb5a5
Revert "only hide page when doing payment"
This reverts commit f438305b6e.
2017-12-01 03:18:15 +01:00
Florian Dold
f438305b6e
only hide page when doing payment 2017-12-01 03:17:32 +01:00
Florian Dold
b8ccc7c990
partial implementation of tipping 2017-12-01 03:00:09 +01:00
Marcello Stanisci
bc2c4aff8e
catching more TimeoutException(s) 2017-11-23 11:27:01 +01:00
Marcello Stanisci
de461a3358
catching timeout exception 2017-11-22 11:18:34 +01:00
Marcello Stanisci
5d816ca065
bundling args in a class 2017-11-02 16:20:48 +01:00
Marcello Stanisci
d4e8b98934
abort() doesn't log anymore 2017-11-02 16:03:27 +01:00
Marcello Stanisci
ca2073c22a
instantiating and using_one_ wait object, plus
porting all DOM operations to use waits.
2017-11-02 15:59:06 +01:00
Marcello Stanisci
38185fb187
finishing to fix returned values from Selenium
routines, plus general simplification of code.
2017-11-02 13:47:32 +01:00
Marcello Stanisci
a55daa797e
withdraw returns boolean 2017-11-02 12:51:32 +01:00
Marcello Stanisci
77e9eb9d07
indent 2017-11-02 11:59:36 +01:00
Marcello Stanisci
c3595fe47c
experimenting with logs 2017-11-02 11:22:27 +01:00
Florian Dold
b4525c567a
increse selenium timeout 2017-10-29 23:40:40 +01:00
Florian Dold
0f9fef41b0
print browser log on selenium pay failure 2017-10-29 23:37:18 +01:00
Florian Dold
50512f5f6e
version 0.4.0 2017-10-18 15:54:24 +02:00
Florian Dold
59fa713ff2
changelog 2017-10-18 14:53:54 +02:00
Florian Dold
b13ea64454
version 2017-10-18 14:53:54 +02:00
Marcello Stanisci
1c2e73e193
fix page title 2017-10-17 13:40:11 +02:00
Marcello Stanisci
d951a87bc4
selenium wrong class attribute 2017-10-17 13:30:55 +02:00
Florian Dold
f7585780bf
remove broken link 2017-10-17 12:11:54 +02:00
Florian Dold
4955454440
fix history rendering issue caused by i18n 2017-10-17 12:06:47 +02:00
Florian Dold
0305b2c2f7
tsconfig 2017-10-17 11:52:11 +02:00
Florian Dold
1eec95e840
remove incomplete memory IDB implementation for now
Currently lives in its own branch, will be re-added to master once
complete to avoid linting issues.
2017-10-15 20:31:50 +02:00
Florian Dold
8b2f53e3ed
fix tslint warnings 2017-10-15 20:30:33 +02:00
Florian Dold
353eeca339
add missing typeof, makes unit tests pass 2017-10-15 18:55:34 +02:00
Florian Dold
03782f8aea
derive history from db instead of storing it 2017-10-15 18:30:02 +02:00
Florian Dold
23633cf1be
gitignore 2017-10-14 22:46:08 +02:00
Florian Dold
9df98e65f8
update dependencies 2017-10-14 18:40:54 +02:00
Florian Dold
008926b184
compute full fees for refresh and spending 2017-08-30 17:08:54 +02:00
Florian Dold
24e021fef3
don't stop injection early 2017-08-30 15:36:24 +02:00
Christian Grothoff
183bf55057
mark errata properly 2017-08-30 13:33:08 +02:00
Jeffrey Burdges
4601559917
Footnote but Christian wanted this elsewhere 2017-08-29 14:24:40 +02:00
Jeffrey Burdges
ec3604261d
Actualy this part has nothing to do with BOLT being fragile 2017-08-29 14:19:52 +02:00
Jeffrey Burdges
c3752e8c96
Rephrase BOLT fix 2017-08-29 13:44:31 +02:00
Jeffrey Burdges
541256ca99
Merge branch 'master' of ssh://taler.net/wallet-webex 2017-08-29 13:41:58 +02:00
Jeffrey Burdges
33edef30ac
Errata: Statement about BOLT corrected
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-29 13:41:16 +02:00
Florian Dold
52ebba90d6
version bump: 0.4.0-pre1 2017-08-27 23:10:15 +02:00
Florian Dold
43575b5919
show error in create reserve dialog 2017-08-27 06:47:13 +02:00
Florian Dold
b47522c11b
proper rounding for amount operations 2017-08-27 05:57:39 +02:00
Florian Dold
63914ab53b
make sure that refreshing works after refund 2017-08-27 05:42:46 +02:00
Florian Dold
ccc6d82242
canonicalize account info JSON when collecting them 2017-08-27 04:35:24 +02:00
Florian Dold
665e88c72b
node_modules 2017-08-27 04:19:34 +02:00
Florian Dold
24181bdf20
better error report / retry prompt for failed payments 2017-08-27 04:19:11 +02:00
Florian Dold
8697efd2c8
implement refunds 2017-08-27 03:56:19 +02:00
Florian Dold
21c176a69e
add rudimentary error reporting in a new tab 2017-08-25 18:08:37 +02:00
Florian Dold
bf70e752b6
remove file 2017-08-14 05:05:35 +02:00
Florian Dold
363723fc84
node_modules 2017-08-14 05:02:09 +02:00
Florian Dold
5634e77ad9
fix build system / types 2017-08-14 04:59:43 +02:00
Florian Dold
d5bba630a3
implement returning coins to user's account 2017-08-14 04:16:12 +02:00