gnunet-svn
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-SVN] [taler-wallet-webex] branch master updated: Errata: Stateme


From: gnunet
Subject: [GNUnet-SVN] [taler-wallet-webex] branch master updated: Errata: Statement about BOLT corrected
Date: Tue, 29 Aug 2017 13:42:06 +0200

This is an automated email from the git hooks/post-receive script.

burdges pushed a commit to branch master
in repository wallet-webex.

The following commit(s) were added to refs/heads/master by this push:
     new 33edef30 Errata: Statement about BOLT corrected
     new 541256ca Merge branch 'master' of ssh://taler.net/wallet-webex
33edef30 is described below

commit 33edef30acda54fc23ec1238d8de13c07a0c87a8
Author: Jeffrey Burdges <address@hidden>
AuthorDate: Tue Aug 29 13:41:16 2017 +0200

    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 <address@hidden>
    > To:   address@hidden <address@hidden>
    >
    >
    >
    > 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
---
 articles/ui/ui.tex | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex
index adf1a025..de9d99ed 100644
--- a/articles/ui/ui.tex
+++ b/articles/ui/ui.tex
@@ -455,9 +455,9 @@ Amongst these, the blind off-chain lightweight transactions 
(BOLT)
 proposal~\cite{BOLT} provides anonymity by routing off-blockchain
 transfers through bank-like intermediaries.  Although interesting,
 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.
+including aborts deanonymizing customers, intermediaries taking
+unexpected legal risks, and theft if a party fails to post a refute
+message in a timely fashion.
 % Of course, Taler itself could be used to provide a side-chain like technology
 % Assuming these issues can be addressed,
 % % and the relatively advanced crypto involved became production ready,

-- 
To stop receiving notification emails like this one, please contact
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]