sync

1 files changed, 39 insertions, 55 deletions

diff --git a/stuff.txt b/stuff.txt
index 2d67253..65c428e 100644
--- a/stuff.txt
+++ b/stuff.txt
@@ -13,6 +13,16 @@ Priorities:
 stretch goals:
 * protocol diagrams for tipping and refunds
 * screenshots in Firefox
+* illustration for the browser-based payment process
+* illustration for contract terms etc.
+
+passes:
+* check that everything is cited properly
+
+missing citations:
+- rscoin (?)
+- monero
+- algorand, consensus stuff that jeff sent
 
 --------------------------
 Q&A:
@@ -23,10 +33,19 @@ would it not be better if the exchange knew about the amount for a contract
 and could refund automatically if the payment wasn't completed before the pay deadline?
 => No, since the customer can complete the payment themselves
 
+Should there be some diagram showing the contents for the
+contract terms + deposit modalities
+
+Do we support in the implementation that different deposits are unlinkable
+from the contract?  It does not currently look like it, we mix both cases,
+leading to some confusion.
+
 
 Should I have a notation index?
 => ?
 
+Should I have a glossary for terms like "contract", "offer", "contrac terms", etc.?
+
 What about deanonymization with the link protocol?
 Where is the discussion?
 => The customer can only be deanonymized with link
@@ -40,6 +59,7 @@ Where do we state "what prevents tax evasion"?
 Where is the refresh/linking protocol described on a high level?
 
 Should we rename RefreshRequest to RefreshPrepare?
+=> Not really necessary IMHO
 
 Where do we describe the indian merchant scenario?
 
@@ -47,26 +67,31 @@ Where do we clearly state the security assumptions used in practice?
 
 Does the customer check that the exchange gave the same
 gamma when the protocol is replayed?
-!!! It doesn't!
+=> Fixed now, needed to be added
 
+Should we get rid of the X- prefix?
+=> Yes!
 
---------------------------
-Issues:
+Are the reasons for a refresh protocol is essential clearly explained?
 
-* I don't cite monero at all
-* what about algorand and similar consensus stuff
+Are practical anonymity concerns discussed properly (amounts, denomination, contrac terms, ...)?
+
+/track/transaction is horribly named, it should be /track/deposit
+=>  No!  This is not the right answer, as it does not track deposits,
+    but rather all deposits associated with a h_contract_terms
+
+- should the RSA blind signature algorithm be shown somewhere?
+=> yes, complete concrete instantiation
 
---------------------------
 
-- probabilistic checks for
-  deposit confirmation
-auditor:
-- does not check if link is not implemented
-- auditor rest api:
- - give the auditor proof of misbehavior
-   or denial of service
- - statistical checks on certain behaviors
+- salting of wire hash info?
+=> should not happen in the "/wire" response
+
+- on-line vs online
+=> "current usage favors online", so we use that
+
 
+--------------------------
 - NFC
  - indian merchant scenario using KYC hash
 
@@ -87,20 +112,9 @@ auditor:
 - writing Taler vs GNU Taler
   => always write GNU Taler?
 
-- what happens if the auditor detects a problem?
-
-
 - byz consensus chapter does *not* currently contain any references
   to the blockchain stuff.  it should discuss the application in more detail
 
-
-- should the RSA blind signature algorithm be shown somewhere?
-=> yes, complete concrete instantiation
-
-
-- salting of wire hash info?
-=> should not happen in the "/wire" response
-
 - mention explicitly that taler does not do automatic tax collection
 
 - limits on withdrawal, where, how?  is the auditor involved?
@@ -120,34 +134,10 @@ auditor:
 
 - reference the BIS reports somewhere, they are good.
 
-- on-line vs online
-
-- refresh isn't properly introduced
-
-- should we separate related work from related work discussion?
-
-
 - if customer can submit coins, then can't this mess with
   the merchant's accounting in an audit?
   => NO, the merchant simply pays normal taxes for gifts/donations
 
-
-- need to go through bibliography to fix problems
-
-- make sure everything has enough references put in
-
-- rscoin in related work?
-
-- KDF vs hash mismatch in the crypto chapter
-
-- maybe put stuff about why transaction ID is necessary earlier?
-
-
-- reasons why you need refresh in practice:
- - depending on the deposit protocol, when the merchant is unresponsive
- - when restoring from backup!
-
-
 - discuss practical anonymity somewhere
   (amounts, denominations, contract terms, Tor)
 
@@ -155,9 +145,3 @@ auditor:
  - what about /payback with refreshed coins?  should be possible
    if the revoked denom is the refresh target
 
-- should nonce_pub be used to sign the deposit permission too?
-
-
-- should we get rid of the X- prefix?
-
-- /track/transaction is horribly named, it should be /track/deposit