moving here wallet papers forlder

articles/pml/taler-pay.pml

@@ -0,0 +1,45 @@
+@startuml
+!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml
+
+Actor "Payer (Shopper) Browser" as Payer
+Participant "Payee (Merchant) Site" as Payee
+Participant "Taler Exchange" as Exchange
+
+note over Payer, Payee: Tor/HTTPS
+note over Payee, Exchange: HTTP/HTTPS
+
+title Taler (Payment)
+
+== Establish Payment Obligation ==
+
+opt
+Payer->Payer: Select Taler payment method (skippable with auto-detection)
+end
+
+Payer->Payee: Choose goods
+
+Payee->Payer: Send signed digital contract proposal
+
+== Execute Payment ==
+
+opt
+Payer->Payer: Affirm contract
+end
+
+Payer->Payee: Send payment
+
+Payee->Exchange: Forward payment
+
+Exchange->Payee: Confirm payment
+
+== Fulfilment ==
+
+Payee->Payer: Confirm payment
+
+opt
+Payer->Payee: Request fulfillment (if Web article)
+
+Payee->Payer: Provide media product
+end
+
+@enduml

articles/pml/taler-withdraw.pml

@@ -0,0 +1,33 @@
+@startuml
+!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml
+
+Actor "Customer Browser" as Customer
+Participant "Bank Site" as Bank
+Participant "Taler Exchange" as Exchange
+
+note over Customer, Bank: HTTPS
+note over Customer, Exchange: HTTPS
+note over Bank, Exchange: SEPA
+
+title Taler (Withdraw coins)
+
+Customer->Bank: user authentication
+Bank->Customer: send account portal
+
+Customer->Customer: initiate withdrawal (specify amount and exchange)
+
+Customer->Exchange: request key material and wire transfer data
+Exchange->Customer: send key material and wire transfer data
+
+Customer->Bank: execute withdrawal
+
+opt
+Bank->Customer: request transaction authorization
+Customer->Bank: transaction authorization
+end
+
+Bank->Customer: withdrawal confirmation
+Bank->Exchange: execute wire transfer
+
+
+@enduml

articles/spending.txt

@@ -0,0 +1,147 @@
+
+
+Just to answer Marcello's question from this evening about optimal coin spending:
+
+We have:
+  a set D of denominations,
+  a value function v : D -> R,
+  a deposit fee function f : D -> R,
+  a maximum deposit fee m>=0,
+  a refresh/melt fee function r : D -> R,
+  a wallet function w : D -> Z,
+  an unknown constant c>0 but very small,
+  and a price>0
+where f, r, and w are non-negative.  And R and Z denote the reals and integers, respectively.
+
+We want to select two functions
+  spend total t : D -> Z,
+  spend partial p : D -> Z, and
+  partial value v' : D -> R
+so as to minimize the function :
+  max(0, -m + sum_x f[x]*d[x])
+  + sum_x r[x]*p[x]
+  + c * sum_x (d+p)[x]
+subject to the constraints
+  t[x] >= 0
+  p[x] >= 0
+  (t+p)[x] <= w[x]
+  sum_x v[x]*d[x] >= price
+  sum_x (v[x]*t[x] + v'[x]) <= price
+  v'[x] <= v[x]
+  p[x] <= 1
+where d = t+p is a convenient notation.
+
+We assume these last two because if p[x] > 1 then you could refresh one less coin.  In fact, you should never refresh more than one coin, so that's sum_x p[x] <= 1, but not sure we need that much.
+
+
+1.  Dynamic Programming
+
+There is a solution using dynamic programming because the problem has the optimal substructure property :
+
+If the above parameters have an optimal assignment, then replacing
+  price := price - v[x]*t[x] - v'[x],  
+  t[x] := 0,  
+  p[x] := 0,  and  
+  v'[x] := 0
+gives another optimal solution, as otherwise we'd get a better one for the first situation.  
+
+There is however no assurence that t[x] = price mod v[x] for some x in D, so nievely such solutions give you running times like O(price * |D|), which kinda sucks actually.  Just one simplified example :
+ http://www.codeproject.com/Articles/31002/Coin-Change-Problem-Using-Dynamic-Programming
+
+
+2.  Greedy Algorithm
+
+There is a greedy algorithm that runs linear time for the usual change problem, but it assumes a sane coin systems.  I have not read the reference
+ http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=5254395
+but presumably it assumes v[x] divides v[y] whenever v[y]>v[x] or something similar.
+
+There are crazy coin systems that violate this assumption, which impacts Taler in two ways :
+
+First, an obnoxious mint could make insane denominations that forced customers and merchants to spend slightly more, while nominally claiming fees competitive with other mints.  We can ignore this as it's rather obvious manipulation and an obnoxious mint cannot charge much more.  I think an approximation result says the mint cannot even double the fees.  
+
+Second, there could be two mints whose denominations together formed an insane set that caused bad coin usage.  Again the results should not be too bad, but one could combat this by processing mints individually before considering them together.  
+
+Now there are some additional complexities related to giving change and not knowing how to order the denominations, so maybe worth a bit more formalism first.
+
+
+3.  Integer linear programming
+(It helps with understanding the greedy algorithm too)
+
+We almost have an integer linear program because all these functions parameterized by D are simply vectors.  We just need to eliminate that annoying max(0, ), which we do by introducing a variable z.  I'm going to switch from t[x] to d[x] = t[x] + p[x] and surpress the indexes [x] here since only m, c, and z lack indexes.
+
+Select d : D -> Z and p : D -> Z so as to minimize the function
+  z + sum_x ( r*p + c*(d+p) )
+subject to the constraints
+  d <= w  for all x
+  sum_x v*(d-p) <= price
+  sum_x v*d >= price
+  z >= - m + sum_x f*(t+p)
+and
+  z >= 0
+  d >= 0  for all x
+  p >= 0  for all x
+
+We should introduce slack variables so that row operations cannot lose information:
+
+Select d and p so as to minimize the function
+  z + sum_x ( r*p + c*(d+p) )
+subject to the constraints
+  d(x) = w - w'  for all x
+  sum_x v*(d-p) = price - price1
+  sum_x v*d = price + price2
+  z - sum_x f*d = -m + m'
+and
+  w' >= 0  for all x
+  m' >= 0
+  price1 >= 0
+  price2 >= 0
+  z >= 0
+  d >= 0  for all x
+  p >= 0  for all x
+
+We can eliminate z with a row operation and then drop -m + m' from the objective, so that price is the only constraint set by the merchant.
+
+Select d and p so as to minimize the function
+  sum_x ( r*p + c*(d+p) + f*d ) = sum_x ( (r+c)*p + (f+c)*d )
+subject to the constraints
+  d = w-w'  for all x
+  sum_x v*(d-p) = price - price1
+  sum_x v*d = price + price2
+and  ...
+
+And those constraints could again be written as
+  d <= w
+  sum_x v*(d-p) <= price
+  sum_x v*d >= price
+
+It's maybe now easier to visualize the greedy algorithm working when you think about that sum_x v*d together with this simple objective function.  As a bonus, we observe that c got folded into r and f, which simplifies implementing stuff.
+
+
+4.  Smarter Greed
+
+If we're only allowed to spend one denomination at some price, then we shown the minium is achieved when that denomination x in D is chosen to minimize
+	(f[x]+c)/v[x] + (r[x]+c)/(v[x]*d[x])*p[x]
+where p[x] = max(1,price mod v[x]).  We could approximate this by (f[x]+c)/v[x] under several reasonable hypotheses, not unfortunately r >> f, but price >> v[x] still helps.  In any case, there are many situations where minimizing (f[x]+c)/v[x] handles this single denomination spend.
+
+We know from our optimal substructure property that, for an optimal allocation, there is a denomination x such that zeroing out t[y], p[y], and v'[y] for y not x, and adjusting the price acordingly, gives an optimal allocation.  It follows that a greedy algorithm that uses D sorted by increasing (f[x]+c)/v[x] frequently works, although not when mints charge too much for refreshes
+
+Roughly this algorithm looks like:
+
+FindCoinsGreedily(price,D,v,f,m,r,w,c)
+  set cost = 0
+      t = empty_array
+      done_cost = infinite
+      done_denom = null
+      done_t = empty_array
+  sort D by increasing (f[x]+c)/v[x]
+  for x in D do
+    let t[x] = price mod v[x]
+    set price = price - v[x]*t[x]
+    set cost = cost + (f[x]+c)*v[x]*t[x]
+    if cost + r[z]+c < done_cost then
+      set done_cost = cost + r[z]+c
+      set done_denom = x
+      set done_t to be a copy of t
+  return (done_t,done_denom)
+
+

articles/ui/btc.bib

@@ -0,0 +1,162 @@
+
+
+@incollection{BTC:Anonymity,
+    abstract = {{Anonymity in Bitcoin, a peer-to-peer electronic currency system, is a complicated issue. Within the system, users are identified only by public-keys. An attacker wishing to de-anonymize users will attempt to construct the one-to-many mapping between users and public-keys, and associate information external to the system with the users. Bitcoin tries to prevent this attack by storing the mapping of a user to his or her public-keys on that user's node only and by allowing each user to generate as many public-keys as required. In this chapter we consider the topological structure of two networks derived from Bitcoin's public transaction history. We show that the two networks have a non-trivial topological structure, provide complementary views of the Bitcoin system, and have implications for anonymity. We combine these structures with external information and techniques such as context discovery and flow analysis to investigate an alleged theft of Bitcoins, which, at the time of the theft, had a market value of approximately US\$500,000.}},
+    author = {Reid, Fergal and Harrigan, Martin},
+    booktitle = {Security and Privacy in Social Networks},
+    citeulike-article-id = {12141473},
+    citeulike-linkout-0 = {http://dx.doi.org/10.1007/978-1-4614-4139-7\_10},
+    citeulike-linkout-1 = {http://link.springer.com/chapter/10.1007/978-1-4614-4139-7\_10},
+    doi = {10.1007/978-1-4614-4139-7\_10},
+    editor = {Altshuler, Yaniv and Elovici, Yuval and Cremers, Armin B. and Aharony, Nadav and Pentland, Alex},
+    keywords = {bitcoin, sociophysics},
+    pages = {197--223},
+    posted-at = {2013-08-30 04:39:05},
+    priority = {2},
+    publisher = {Springer New York},
+    title = {{An Analysis of Anonymity in the Bitcoin System}},
+    url = {http://arxiv.org/abs/1107.4524},
+    doi_url = {http://dx.doi.org/10.1007/978-1-4614-4139-7\_10},
+    year = {2013}
+} 
+
+
+@article{BTC:vsTor,
+  author    = {Alex Biryukov and
+               Ivan Pustogarov},
+  title     = {Bitcoin over Tor isn't a good idea},
+  journal   = {CoRR},
+  volume    = {abs/1410.6079},
+  year      = {2014},
+  url       = {http://arxiv.org/abs/1410.6079},
+  youtube   = {https://www.youtube.com/watch?v=gd5NZvsyAfw},
+  timestamp = {Sun, 02 Nov 2014 11:25:59 +0100},
+  biburl    = {http://dblp2.uni-trier.de/rec/bib/journals/corr/BiryukovP14},
+  bibsource = {dblp computer science bibliography, http://dblp.org}
+}
+
+
+
+@article{BTC:MajorityNotEnough,
+  author = {Eyal, Ittay and Sirer, Emin Gün},
+  biburl = {http://www.bibsonomy.org/bibtex/25fc206a8cbe0e366414aaef4eeec9773/dblp},
+  ee = {http://arxiv.org/abs/1311.0243},
+  interhash = {5d649d73ce634befdac40bf0fe53fb9c},
+  intrahash = {5fc206a8cbe0e366414aaef4eeec9773},
+  journal = {CoRR},
+  keywords = {dblp},
+  timestamp = {2013-12-04T11:33:22.000+0100},
+  title = {Majority is not Enough: Bitcoin Mining is Vulnerable.},
+  url = {http://arxiv.org/abs/1311.0243},
+  doi_url = {http://dblp.uni-trier.de/db/journals/corr/corr1311.html#EyalS13},
+  volume = {abs/1311.0243},
+  year = 2013
+}
+
+
+@article{BTC:Bahack13,
+  author    = {Lear Bahack},
+  title     = {Theoretical Bitcoin Attacks with less than Half of the Computational
+               Power (draft)},
+  journal   = {{IACR} Cryptology ePrint Archive},
+  volume    = {2013},
+  pages     = {868},
+  year      = {2013},
+  url       = {http://eprint.iacr.org/2013/868},
+  url_too   = {http://arxiv.org/abs/1312.7013},
+  timestamp = {Thu, 30 Jan 2014 00:00:00 +0100},
+  biburl    = {http://dblp.uni-trier.de/rec/bib/journals/iacr/Bahack13},
+  bibsource = {dblp computer science bibliography, http://dblp.org}
+}
+
+
+@inproceedings{BTC:Eclipse,
+ author = {Heilman, Ethan and Kendler, Alison and Zohar, Aviv and Goldberg, Sharon},
+ title = {Eclipse Attacks on Bitcoin's Peer-to-peer Network},
+ booktitle = {Proceedings of the 24th USENIX Conference on Security Symposium},
+ series = {SEC'15},
+ year = {2015},
+ isbn = {978-1-931971-232},
+ location = {Washington, D.C.},
+ pages = {129--144},
+ numpages = {16},
+ url = {http://dl.acm.org/citation.cfm?id=2831143.2831152},
+ acmid = {2831152},
+ publisher = {USENIX Association},
+ address = {Berkeley, CA, USA},
+} 
+
+
+
+
+@article{DBLP:journals/corr/Rosenfeld14,
+  author    = {Meni Rosenfeld},
+  title     = {Analysis of Hashrate-Based Double Spending},
+  journal   = {CoRR},
+  volume    = {abs/1402.2009},
+  year      = {2014},
+  url       = {http://arxiv.org/abs/1402.2009},
+  timestamp = {Wed, 05 Mar 2014 14:43:44 +0100},
+  biburl    = {http://dblp2.uni-trier.de/rec/bib/journals/corr/Rosenfeld14},
+  bibsource = {dblp computer science bibliography, http://dblp.org}
+}
+
+
+
+@misc{BTCfees,
+  author = {Ofir Beigel},
+  title = {What Bitcoin Exchanges Won’t Tell You About Fees},
+  year = {2015},
+  actual_date = {11/07/2015},
+  url = {https://www.cryptocoinsnews.com/what-bitcoin-exchanges-wont-tell-you-about-fees/},
+  urldate = {2016-02-10},
+  note = {[Online; Accessed: 2016-02-10]}
+}
+
+
+@misc{vice_btc_unsustainable,
+  author = {Christopher Malmo},
+  title = {Bitcoin Is Unsustainable},
+  year = {2015},
+  actual_date = {29 June 2015},
+  url = {https://www.cryptocoinsnews.com/what-bitcoin-exchanges-wont-tell-you-about-fees/},
+  urldate = {2016-02-10},
+  note = {[Online; Accessed: 2016-02-10]}
+}
+
+
+@misc{lehmann_btc_fools_gold,
+  author = {Chris Lehmann},
+  title = {Bitcoin: Digital Fool’s Gold?},
+  subtitle = {Silicon Valley investors are betting heavily on the online currency. But is it a libertarian boondoggle?},
+  year = {2015},
+  actual_date = {12 May 2015},
+  url = {http://inthesetimes.com/article/17859/bitcoin-the-rush-for-digital-fools-gold},
+  urldate = {2016-02-28},
+  note = {[Online; Accessed: 2016-02-28]}
+}
+
+
+@misc{jeffries_economists_v_btc,
+  author = {Adrianne Jeffries},
+  title = {Why don’t economists like Bitcoin?},
+  subtitle = {Paul Krugman and others can't get behind the virtual currency},
+  year = {2013},
+  actual_date = {31 December 2013},
+  url = {http://www.theverge.com/2013/12/31/5260534/krugman-bitcoin-evil-economists},
+  urldate = {2016-02-28},
+  note = {[Online; Accessed: 2016-02-28]}
+}
+
+
+@misc{lewis_btc_is_junk,
+  author = {Nathan Lewis},
+  title = {Bitcoin Is a Junk Currency, But It Lays the Foundation For Better Money},
+  year = {2013},
+  actual_date = {9 May 2013},
+  url = {http://www.forbes.com/sites/nathanlewis/2013/05/09/bitcoin-is-a-junk-currency-but-it-lays-the-foundation-for-better-money/},
+  urldate = {2016-02-28},
+  note = {[Online; Accessed: 2016-02-28]}
+}
+
+

articles/ui/figs/bitcoin.pml

@@ -0,0 +1,37 @@
+# FROM: https://github.com/w3c/webpayments/tree/gh-pages/PaymentFlows
+
+@startuml
+!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml
+
+Database "Invoice Database" as DB
+Participant "Payee Website" as Website
+Database "Bitcoin Network" as Bitcoin
+Participant "Payer Wallet" as Wallet
+Actor "Payer (Browser)" as Payer
+
+title Bitcoin Payment Protocol (BIP70)
+
+Payer->Website: Request checkout with Bitcoin
+Website->Website: Generate Bitcoin address
+Website->DB: Store invoice details
+Website->Payer: Basket Page with bitcoin: pay link
+Payer->Payer: Click bitcoin: link
+Payer->Wallet: Wallet handles bitcoin: URL and extracts invoice URL
+Wallet->Website: Request invoice
+Website->DB: Get invoice details
+Website->Website: Create PaymentDetails (Amount, Memo, Ref#, Pay URL)
+Website->Website: Create PaymentRequest (Signed PaymentDetails)
+Website->Wallet: PaymentRequest containing PaymentDetails
+Wallet->Payer: Confirm payment details?
+Payer->Wallet: Accept payment
+Wallet->Wallet: Generate and sign payment
+Wallet->Website: Signed payment
+Website->Bitcoin: Submit payment
+Website->Wallet: Payment ACK
+Wallet->Payer: Confirm payment is complete
+loop until payment is confirmed
+    Bitcoin->Website: Latest confirmed transactions
+end
+
+
+@enduml

articles/ui/figs/cc3ds.pml

@@ -0,0 +1,96 @@
+# FROM: https://github.com/w3c/webpayments/tree/gh-pages/PaymentFlows
+
+@startuml
+!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml
+
+Participant "Payee (Merchant) PSP [Acquirer]" as MPSP
+Participant "Payee (Merchant) [Acceptor] Site " as Payee
+Actor "Payer (Shopper) [Cardholder] Browser" as Payer
+participant "Browser Form Filler" as UA
+participant "Card Scheme Directory" as CSD
+participant "Issuing Bank [Issuer] Website" as CPSPW
+participant "Issuing Bank [Issuer]" as CPSP
+
+note over Payee, Payer: HTTPS
+
+title
+<b>Legacy Merchant Hosted Card Payment with Acquirer Supported 3DS (Current)</b>
+
+<i>3DS is used to add confidence that the payer is who they say they are and importantly in the event of a dispute liability shift to the Issuer.</i>
+end title
+
+== Establish Payment Obligation ==
+
+Payee->Payer: Present Check-out page with Pay Button
+Payer->Payer: Select Card Payment Method
+
+alt
+	UA->Payer: Form Fill
+	Note right: fields are PAN & Expiry Date with optional CVV, & Address, Also Card Valid Date and Issue Number are required for some Schemes
+else
+	Payer->Payer: User Fills Form
+End
+
+== Card Payment Initiation ==
+
+Payer->Payee: Payment Initiation
+Note right: Custom code on merchant webpage can encrypt payload to reduce PCI burden from SAQ D to SAQ A-EP
+
+opt
+	Payee->Payee: Store Card
+	note right: Merchant can store card details apart from CVV (even if encrypted) for future use (a.k.a. Card on File)
+end
+
+Payee-\MPSP: Authorise
+
+
+== 3DS part of flow ==
+
+Note over MPSP, Payee: At this point, the Merchant or Merchant's PSP can decide if it wishes to invoke 3DS. This might be based on transaction value (i.e. low value -> low risk) or other factors, e.g. if the Shopper is a repeat purchaser.
+
+	MPSP –> CSD: BIN to URL lookup (VAReq message)
+	CSD -> CSD: Lookup URL from BIN
+	CSD –> CPSPW : “PING”
+	note right: verify URL validity
+	CPSPW –> CSD: “PING” response
+	CSD –> MPSP: URL
+
+	MPSP-/Payee: 3DS redirect (PAReq message)
+	Payee->Payer: 3DS redirect (PAReq message)
+	Payer->CPSPW: 3DS invoke
+	CPSPW-\Payer: 3DS challenge
+	Payer-/CPSPW: 3DS response (PARes message)
+	CPSPW->Payer: 3DS response (PARes message)
+	Payer->Payee: 3DS response (PARes message)
+	Payee-\MPSP: 3DS response (PARes message)
+
+	MPSP->MPSP: Verification of PARes signature
+
+== End of 3DS ==
+
+
+MPSP-\CPSP: Authorisation Request
+CPSP-/MPSP: Authorisation Response
+
+MPSP-/Payee: Authorisation Response
+
+== Notification ==
+
+Payee->Payer: Result Page
+
+== Request for Settlement process (could be immediate, batch (e.g. daily) or after some days) ==
+
+Alt
+	Payee -> MPSP : Capture
+	note right: Later Capture may be called, for example after good shipped or tickets pickedup
+Else
+	MPSP -> MPSP : Auto Capture in batch processing at end-of-day
+End
+
+MPSP->CPSP: Capture
+
+== Fulfilment ==
+
+Payee->Payer: Provide products or services
+
+@enduml

articles/ui/figs/paypal.pml

@@ -0,0 +1,64 @@
+# FROM: https://github.com/w3c/webpayments/tree/gh-pages/PaymentFlows
+
+@startuml
+!includeurl https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/skin.ipml
+
+Participant "Payee (Merchant) Site" as Payee
+Actor "Payer (Shopper) Browser" as Payer
+participant "Payer (Shopper) PSP (PayPal)" as CPSP
+
+note over MPSP, CPSP: HTTPS
+
+title PayPal Payment (REST API) (Current)
+
+Payee->Payer: Present Checkout Page with Pay Button
+
+Payer->Payer: Select PayPal Payment Method
+
+Payer-\Payee: Payment Page Request
+
+Payee<->CPSP: Create Payment
+
+Payee-/Payer: HTTP Redirect
+
+Note right: HTTP Direct now send the shopper to the PayPal site
+
+Payer-\CPSP: Payment Initiation
+
+CPSP-/Payer: Authentication Page
+
+Payer-\CPSP: Authenticate
+note right: Typically a username & password
+
+CPSP-/Payer: Payment Page
+
+opt
+	Payer<->CPSP: Instrument Choice
+	note right: Payer can change from default payment instrument
+end
+
+Payer->Payer: Approval
+
+Payer-\CPSP: Payment Approval
+
+CPSP-/Payer: Payment Response Redirect
+
+Payer-\Payee: Payment Response
+
+Payee<->CPSP: Execute Payment
+
+Payee-/Payer: Result Page
+
+
+... asynchronous notification ...
+
+CPSP->Payer: Payment Notification (email)
+
+Opt
+	Payee->Payer: Payment Notification (email)
+End
+
+Note right: Provides out of band confirmation to protect against failure/modification at browser
+
+
+@enduml

articles/ui/figs/taler-contract.js

@@ -0,0 +1,35 @@
+/* Trigger Taler contract generation on the server, and pass the
+   contract to the extension once we got it. */
+function taler_pay(form) {
+  var contract_request = new XMLHttpRequest();
+
+  /* Note that the URL we give here is simply an example
+     and not dictated by the protocol: each web shop can
+     have its own way of generating and transmitting the
+     contract, there just must be a way to get the contract
+     and to pass it to the wallet when the user selects 'Pay'. */
+  contract_request.open("GET", "generate-taler-contract", true);
+  contract_request.onload = function (e) {
+    if (contract_request.readyState == 4) {
+      if (contract_request.status == 200) {
+        /* Send contract to the extension. */
+        handle_contract(contract_request.responseText);
+      } else {
+        /* There was an error obtaining the contract from the merchant,
+           obviously this should not happen. To keep it simple, we just
+           alert the user to the error. */
+        alert("Failure to download contract " +
+              "(" + contract_request.status + "):\n" +
+              contract_request.responseText);
+      }
+    }
+  };
+  contract_request.onerror = function (e) {
+    /* There was an error obtaining the contract from the merchant,
+       obviously this should not happen. To keep it simple, we just
+       alert the user to the error. */
+      alert("Failure requesting the contract:\n" +
+            contract_request.statusText);
+  };
+  contract_request.send();
+}

articles/ui/figs/taler-presence.js

@@ -0,0 +1,35 @@
+function handleInstall() {
+  var show = document.getElementsByClassName("taler-installed-show");
+  var hide = document.getElementsByClassName("taler-installed-hide");
+  for (var i = 0; i < show.length; i++) {
+    show[i].style.display = "";
+  }
+  for (var i = 0; i < hide.length; i++) {
+    hide[i].style.display = "none";
+  }
+};
+
+function handleUninstall() {
+  var show = document.getElementsByClassName("taler-installed-show");
+  var hide = document.getElementsByClassName("taler-installed-hide");
+  for (var i = 0; i < show.length; i++) {
+    show[i].style.display = "none";
+  }
+  for (var i = 0; i < hide.length; i++) {
+    hide[i].style.display = "";
+  }
+};
+
+function probeTaler() {
+  var eve = new Event("taler-probe");
+  document.dispatchEvent(eve);
+};
+
+function initTaler() {
+  handleUninstall(); probeTaler();
+};
+
+document.addEventListener("taler-wallet-present", handleInstall, false);
+document.addEventListener("taler-unload", handleUninstall, false);
+document.addEventListener("taler-load", handleInstall, false);
+window.addEventListener("load", initTaler, false);

articles/ui/taler.bib

@@ -0,0 +1,183 @@
+@article{nakamoto2008bitcoin,
+  title={Bitcoin: A peer-to-peer electronic cash system},
+  author={Nakamoto, Satoshi},
+  year={2008}
+}
+
+@InProceedings{apod,
+  author =       {Elli Androulaki and Steven Bellovin},
+  title =        {APOD: Anonymous Physical Object Delivery},
+  booktitle = {Symposium on Privacy-Enhancing Technologies (PETS)},
+  year =      {2009},
+}
+
+@Article{blum1981,
+  author = 	 {Manuel Blum},
+  title = 	 {Coin Flipping by Telephone},
+  journal = 	 {CRYPTO},
+  year = 	 {1981},
+  pages = 	 {11-15},
+}
+
+
+@Misc{target,
+  author =    {Michael Riley and Ben Elgin and Dune Lawrence and Carol Matlack},
+  title =     {Missed Alarms and 40 Million Stolen Credit Card Numbers: How Target Blew It},
+  howpublished = {\url{http://www.bloomberg.com/bw/articles/2014-03-13/target-missed-alarms-in-epic-hack-of\-credit-card-data}},
+  month =     {March},
+  year =      {2013},
+}
+
+@Misc{greece2015cash,
+  author =    {Reuters},
+  title =     {Greek council recommends 60 euro limit on ATM withdrawals from Tuesday},
+  howpublished = {\url{http://www.reuters.com/article/2015/06/28/eurozone-greece-limits-idUSA8N0Z302P20150628}},
+  month =     {June},
+  year =      {2015},
+}
+
+@Misc{france2015cash,
+  author =    {Heinz-Peter Bader},
+  title =     {France steps up monitoring of cash payments to fight low-cost terrorism},
+  howpublished = {\url{http://www.reuters.com/article/2015/03/18/us-france-security-financing-idUSKBN0ME14720150318}},
+  month =     {Mar},
+  year =      {2015},
+}
+
+
+@Misc{fatf1997,
+  title =     {FATF-IX report on money laundering typologies},
+  howpublished = {\url{http://www.fatf-gafi.org/media/fatf/documents/reports/1996\%201997\%20ENG.pdf}},
+  month =     {feb},
+  year =      {1998},
+}
+
+@TechReport{,
+  author =       {},
+  title =        {},
+  institution =  {},
+  year =         {},
+  OPTkey =       {},
+  OPTtype =      {},
+  OPTnumber =    {},
+  OPTaddress =   {},
+  OPTmonth =     {},
+  OPTnote =      {},
+  OPTannote =    {}
+}
+
+@InProceedings{sander1999escrow,
+  author =       {Tomas Sander and Amnon Ta-Shma},
+  title =        {On Anonymous Electronic Cash and Crime},
+  booktitle = {ISW'99},
+  year =      {1999},
+  series =    {LNCS 1729},
+  pages =     {202--206},
+}
+
+@Article{solms1992perfect,
+  author =       {Sebastiaan H. von Solms and David Naccache},
+  title =        {On blind signatures and perfect crimes},
+  journal = {Computers \& Security},
+  year =      {1992},
+  volume =    {11},
+  number =    {6},
+  pages =     {581--583},
+}
+
+@inproceedings{chaum1990untraceable,
+  title={Untraceable electronic cash},
+  author={Chaum, David and Fiat, Amos and Naor, Moni},
+  booktitle={Proceedings on Advances in cryptology},
+  pages={319--327},
+  year={1990},
+  organization={Springer-Verlag New York, Inc.}
+}
+
+@inproceedings{chaum1983blind,
+  title={Blind signatures for untraceable payments},
+  author={Chaum, David},
+  booktitle={Advances in cryptology},
+  pages={199--203},
+  year={1983},
+  organization={Springer}
+}
+
+@inproceedings{rivest2004peppercoin,
+  title={Peppercoin micropayments},
+  author={Rivest, Ronald L},
+  booktitle={Financial Cryptography},
+  pages={2--8},
+  year={2004},
+  organization={Springer}
+}
+
+@inproceedings{miers2013zerocoin,
+  title={Zerocoin: Anonymous distributed e-cash from bitcoin},
+  author={Miers, Ian and Garman, Christina and Green, Matthew and Rubin, Aviel D},
+  booktitle={Security and Privacy (SP), 2013 IEEE Symposium on},
+  pages={397--411},
+  year={2013},
+  organization={IEEE}
+}
+
+
+
+@InProceedings{fc2014murdoch,
+  author =       {Stephen Murdoch and Ross Anderson},
+  title =        {Security Protocols and Evidence: Where Many Payment Systems Fail},
+  booktitle = {Financial Cryptography and Data Security},
+  year =      {2014},
+}
+
+@book{ engels1844,
+  author = 	 "Friedrich Engels",
+  title = 	 "{Umrisse zu einer Kritik der National\"okonomie}",
+  year = 	 "1844",
+  publisher = "Ruge and Marx, Paris",
+}
+
+
+@inproceedings{selby2004analyzing,
+  title={Analyzing the Success and Failure of Recent e-Payment Schemes},
+  author={Selby, Jack R},
+  booktitle={Financial Cryptography},
+  pages={1--1},
+  year={2004},
+  organization={Springer}
+}
+
+@misc{brands1993efficient,
+  title={An efficient off-line electronic cash system based on the representation problem},
+  author={Brands, Stefan A},
+  year={1993},
+  publisher={Centrum voor Wiskunde en Informatica}
+}
+
+@article{dent2008extensions,
+  title={Extensions to Chaum's Blind Signature Scheme and OpenCoin Requirements},
+  author={Dent, AW and Paterson, KG and Wild, PR},
+  year={2008}
+}
+
+@article{dent2008preliminary,
+  title={Preliminary Report on Chaum's Online E-Cash Architecture},
+  author={Dent, AW and Paterson, KG and Wild, PR},
+  journal={Royal Holloway, University of London},
+  year={2008}
+}
+
+
+
+@inproceedings{tor-design,
+  title = {Tor: The Second-Generation Onion Router},
+  author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+  booktitle = {Proceedings of the 13th USENIX Security Symposium},
+  year = {2004},
+  month = {August},
+  www_important = {1},
+  www_tags = {selected},
+  www_html_url = {https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.html},
+  www_pdf_url = {https://www.torproject.org/svn/trunk/doc/design-paper/tor-design.pdf},
+  www_section = {Anonymous communication},
+}

articles/ui/ui-outline.tex

@@ -0,0 +1,101 @@
+\documentclass[letterpaper,12pt]{article}
+\usepackage[margin=1in]{geometry}
+\usepackage{url}
+
+\begin{document}
+
+
+theme : Privacy increses usability
+title?
+
+outline : 
+
+
+Describe workflow in existing payment systems
+- Cash
+  - authentication at ATM
+  - transaction authenticated by the cash
+  - worries : counterfit bills, wrong currency, etc.
+  - refunds
+- CC authentication 
+  - online vs offline
+  - extended verification
+  - credential theft
+  "this reversal of authentication vs shoping slows shopping"
+    - worse because exposing yourself to a merchant
+    - can choose not to use a particular ATM
+    - 40 million stolen at target
+  - refunds, annoys banks
+  - swipe vs chip vs NFC
+- Bitcoin
+  - external application
+    - p2p not prowser friendly
+  - 5+ or 10 minute transactions mean designing new shopping carts
+  - minning suck0rs, 
+    - massive transaction fees : blockchain.info 
+      - hits you 2-3 times
+  - conversion sucks
+  - DDoS : wired article?
+
+
+Taler overview
+  copy from proposals?
+- bank, mint
+- wallet
+- merchant
+- auditor
+
+Taler payment process from customers prospective
+- similar to cash 
+  - ATM
+  - merchant
+- contract 
+  - digitally signed is better than paper reciept
+- failure modes
+  - insufficent funds
+  - restoring from backups causes double spending
+    - mint gives proof
+  - restoring from backups can lose coins
+  - mint not accepted by merchant
+    - F
+- change
+- refunds
+  vs CC
+  vs Cash
+
+
+Wallet provides isolation
+  Near copy from EXIST protosal?
+- Limits user risk
+- Nearly eliminates risk for merchant and mint
+  - lower transaction fees
+- Reserves simplify things 
+
+Denomination choice
+- Anonymity refresh protocol
+- Withdraw automates like ATMs
+
+Broser extension
+- RESTful vs Bitcoin, OpenCoin, etc.
+  - Retrying RESTful transactions always works
+- minimizing dialog
+- see & pay ??
+- TBB integration
+  - Needed anyways
+- Other browser integration?
+  - Is it wise?  Ok if not worried about anonymity  Taler is still better
+  - Is tor2web worse? 
+- W3C
+
+Autopay?  pat payment recognision?
+- dangerous?
+- high charges
+- good for funny money
+
+NFC
+
+
+\end{document}
+
+
+

articles/ui/ui.aux

@@ -0,0 +1,98 @@
+\relax 
+\citation{dominguez1993}
+\citation{quantitytheory1997volckart}
+\citation{lewis_btc_is_junk}
+\citation{adblockblocks}
+\citation{ehrenberg2014data}
+\citation{rms2013democracy}
+\citation{chaum1983blind}
+\@writefile{toc}{\contentsline {section}{\numberline {1}Introduction}{1}}
+\citation{ezb2016ourmoney}
+\citation{pets2004kuegler}
+\citation{Bankrate}
+\citation{kobil2016tan}
+\citation{emv}
+\citation{mtan}
+\citation{holz2014}
+\citation{pigs}
+\citation{ibi2014}
+\citation{nakamoto2008bitcoin}
+\citation{BTCfees}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Existing payment workflows}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Cash}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Credit and debit cards}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Bitcoin}{2}}
+\citation{nakamoto2008bitcoin}
+\citation{BTC:Bahack13}
+\citation{BTC:MajorityNotEnough}
+\citation{BTC:Eclipse}
+\citation{vice_btc_unsustainable}
+\citation{lehmann_btc_fools_gold}
+\citation{jeffries_economists_v_btc}
+\citation{lewis_btc_is_junk}
+\citation{BTC:Anonymity}
+\citation{crinkey2011rundle}
+\citation{guardian2015cap}
+\@writefile{lof}{\contentsline {figure}{\numberline {2}{\ignorespaces Bitcoin payment processing. (From: W3c Web Payments IG.)\relax }}{3}}
+\newlabel{fig:bitcoin}{{2}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Walled garden payment systems}{3}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3}{\ignorespaces Payment processing with Paypal. (From: W3c Web Payments IG.)\relax }}{3}}
+\newlabel{fig:paypal}{{3}{3}}
+\citation{chaum1983blind}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Taler}{4}}
+\@writefile{lof}{\contentsline {figure}{\numberline {4}{\ignorespaces Taler system overview.\relax }}{4}}
+\newlabel{fig:system}{{4}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Web payment workflow}{4}}
+\@writefile{toc}{\contentsline {paragraph}{Withdrawing coins}{4}}
+\@writefile{lof}{\contentsline {figure}{\numberline {5}{\ignorespaces Withdrawing coins with Taler.\relax }}{4}}
+\newlabel{fig:taler-withdraw}{{5}{4}}
+\newlabel{subfig:login}{{6a}{5}}
+\newlabel{sub@subfig:login}{{a}{5}}
+\newlabel{subfig:withdraw}{{6b}{5}}
+\newlabel{sub@subfig:withdraw}{{b}{5}}
+\newlabel{subfig:exchange}{{6c}{5}}
+\newlabel{sub@subfig:exchange}{{c}{5}}
+\newlabel{subfig:pin}{{6d}{5}}
+\newlabel{sub@subfig:pin}{{d}{5}}
+\@writefile{lof}{\contentsline {figure}{\numberline {6}{\ignorespaces Required steps in a Taler withdrawal process.\relax }}{5}}
+\newlabel{fig:withdrawal}{{6}{5}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Card payment processing with 3DS. (From: W3c Web Payments IG.)\relax }}{6}}
+\providecommand*\caption@xref[2]{\@setref\relax\@undefined{#1}}
+\newlabel{fig:cc3ds}{{1}{6}}
+\@writefile{toc}{\contentsline {paragraph}{Spending coins}{7}}
+\@writefile{lof}{\contentsline {figure}{\numberline {7}{\ignorespaces Payment processing with Taler.\relax }}{7}}
+\newlabel{fig:taler-pay}{{7}{7}}
+\newlabel{subfig:cart}{{8a}{8}}
+\newlabel{sub@subfig:cart}{{a}{8}}
+\newlabel{subfig:payment}{{8b}{8}}
+\newlabel{sub@subfig:payment}{{b}{8}}
+\newlabel{subfig:fulfillment}{{8c}{8}}
+\newlabel{sub@subfig:fulfillment}{{c}{8}}
+\@writefile{lof}{\contentsline {figure}{\numberline {8}{\ignorespaces Required steps in a Taler checkout process.\relax }}{8}}
+\newlabel{fig:shopping}{{8}{8}}
+\@writefile{toc}{\contentsline {paragraph}{Bookmarks and deep links}{8}}
+\citation{rfc6454}
+\citation{cors}
+\@writefile{toc}{\contentsline {paragraph}{Giving change and refunds}{9}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}NFC payments}{9}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.3}Peer-to-peer payments}{9}}
+\citation{target}
+\citation{pcidss}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.4}Usability for merchants}{10}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Discussion}{10}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.1}Security risks}{10}}
+\citation{munichicecream}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.2}Failure modes}{11}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {4.3}Comparison}{11}}
+\citation{diaspora2011}
+\bibstyle{abbrv}
+\bibdata{ui,btc,taler,rfc}
+\@writefile{toc}{\contentsline {section}{\numberline {5}Conclusion}{12}}
+\@writefile{lol}{\contentsline {lstlisting}{figs/taler\textendash presence.js}{13}}
+\@writefile{lof}{\contentsline {figure}{\numberline {9}{\ignorespaces Sample code to detect the Taler wallet. Allowing the Web site to detect the presence of the wallet leaks one bit of information about the user. The above logic also works if the wallet is installed while the page is open.\relax }}{13}}
+\newlabel{listing:presence}{{9}{13}}
+\@writefile{lol}{\contentsline {lstlisting}{figs/taler\textendash contract.js}{14}}
+\@writefile{lof}{\contentsline {figure}{\numberline {10}{\ignorespaces Sample code to pass a contract to the Taler wallet. Here, the contract is fetched on-demand from the server. The {\tt  taler\_pay()} function needs to be invoked when the user triggers the checkout.\relax }}{14}}
+\newlabel{listing:contract}{{10}{14}}
+\@writefile{lof}{\contentsline {figure}{\numberline {11}{\ignorespaces Both the customer's client and the merchant's server execute sensitive cryptographic operations in a secured background/backend that is protected against direct access. Interactions with the Taler exchange from the wallet background to withdraw coins and the Taler backend (Figure\nobreakspace  {}4\hbox {}) to deposit coins are not shown. Existing system security mechanisms are used to isolate the cryptographic components (boxes) from the complex rendering logic (circles), hence the communication is restricted to JavaScript signals or HTTP(S) respectively.\relax }}{14}}
+\newlabel{fig:frobearch}{{11}{14}}

articles/ui/ui.bib

@@ -0,0 +1,197 @@
+
+
+@Misc{pigs,
+  author =    {W3c},
+  title =     {Web Payments Payment Flows},
+  howpublished = {\url{https://github.com/w3c/webpayments/tree/gh-pages/PaymentFlows}},
+  month =     {February},
+  year =      {2016},
+}
+
+
+
+
+@techreport{dominguez1993,
+ title = "Does Central Bank Intervention Increase the Volatility of Foreign       Exchange Rates?",
+ author = "Kathryn M. Dominguez",
+ institution = "National Bureau of Economic Research",
+ type = "Working Paper",
+ series = "Working Paper Series",
+ number = "4532",
+ year = "1993",
+ month = "November",
+ doi = {10.3386/w4532},
+ URL = "\url{http://www.nber.org/papers/w4532}",
+}
+
+@article{quantitytheory1997volckart,
+ ISSN = {00130117, 14680289},
+ URL = {http://www.jstor.org/stable/2599810},
+ author = {Oliver Volckart},
+ journal = {The Economic History Review},
+ number = {3},
+ pages = {430-449},
+ publisher = {[Economic History Society, Wiley]},
+ title = {Early Beginnings of the Quantity Theory of Money and Their Context in Polish and Prussian Monetary Policies, c. 1520-1550},
+ volume = {50},
+ year = {1997}
+}
+
+@book{pcidss,
+ author = {Wright, Steve},
+ title = {PCI DSS A Practical Guide to Implementing and Maintaining Compliance},
+ year = {2011},
+ isbn = {1849281866, 9781849281867},
+ edition = {3rd},
+ publisher = {It Governance Ltd},
+}
+
+
+
+@Misc{ezb2016ourmoney,
+  author =    {European Central Bank},
+  title =     {Our Money},
+  howpublished = {\url{http://www.new-euro-banknotes.eu/}},
+  year =      {2016},
+}
+
+@techreport{buiter2003deflation,
+ title = "Deflation: Prevention and Cure",
+ author = "Willem H. Buiter",
+ institution = "National Bureau of Economic Research",
+ type = "Working Paper",
+ series = "Working Paper Series",
+ number = "9623",
+ year = "2003",
+ month = "April",
+ doi = {10.3386/w9623},
+ URL = "http://www.nber.org/papers/w9623",
+}
+
+@Article{nigeria2015exchange,
+  author =       {Nnanna Philemon Azu and Alireza Nasiri},
+  title =        {Exchange rate Fluctuation and Sustainable Economic growth in Nigeria: VAR Approach},
+  journal =      {Journal of Econonomics and Sustainable Development},
+  year =         {2015},
+  volume =    {6},
+  number =    {13},
+  pages =     {228--238},
+}
+
+@Misc{diaspora2011,
+  author =    {Josh Constine},
+  title =     {After The Regretsy and Diaspora Account Freezes, We’ve Lost Confidence In PayPal},
+  howpublished = {\url{http://techcrunch.com/2011/12/06/paypal-account-freeze/}},
+  month =     {Dec},
+  year =      {2011},
+}
+
+@Misc{crinkey2011rundle,
+  author =    {Guy Rundle},
+  title =     {The humble credit card is now a political tool},
+  howpublished = {\url{http://www.crikey.com.au/2011/10/25/rundle-humble-credit-card-now-a-political\-tool-just-ask-wikileaks/}},
+  month =     {Oct},
+  year =      {2011},
+}
+
+@Misc{guardian2015cap,
+  author =    {Rupert Jones},
+  title =     {Cap on card fees could lead to lower prices for consumers},
+  howpublished = {\url{http://www.theguardian.com/money/2015/jul/27/cap-on-card-fees-retailers}},
+  month =     {July},
+  year =      {2015},
+}
+
+@Article{rms2013democracy,
+  author =       {Richard Stallman},
+  title =        {How Much Surveillance can Democracy Withstand?},
+  journal =      {WIRED},
+  year =         {2013},
+}
+
+@Misc{ibi2014,
+  author =    {ibi research},
+  title =     {Digitalisierung der Gesellschaft 2014 --- Aktuelle Einsch\"atzungen und Trends},
+  howpublished = {\url{http://www.ecommerce-leitfaden.de/digitalisierung-der-gesellschaft-2014.html}},
+  year =      {2014},
+}
+
+@Misc{mtan,
+  author =    {John E. Dunn},
+  title =     {Eurograbber SMS Trojan steals 36 million from online banks},
+  howpublished = {\url{http://www.techworld.com/news/security/eurograbber-sms-trojan-steals-36-million\-from-online-banks-3415014/}},
+  month =     {Dec},
+  year =      {2012},
+}
+
+@Misc{emv,
+  title =     {EMVCo},
+  howpublished = {\url{http://www.emvco.com/}},
+  year =      {2016},
+}
+
+@Misc{kobil2016tan,
+  title =     {ChipTAN/CardTAN: What you see is what you sign},
+  howpublished = {\url{http://www.kobil.com/solutions/identity-access-card-readers/chiptan/}},
+  year =      {2016},
+}
+
+@Misc{cors,
+  author =    {A. van Kersteren},
+  title =     {Cross-Origin Resource Sharing},
+  howpublished = {\url{http://www.w3.org/TR/cors/}},
+  month =     {January},
+  year =      {2014},
+}
+
+@Misc{ehrenberg2014data,
+  author =    {Billy Ehrenberg},
+  title =     {How much is your personal data worth?},
+  howpublished = {\url{http://www.theguardian.com/news/datablog/2014/apr/22/how-much-is-personal-data-worth}},
+  month =     {April},
+  year =      {2014},
+}
+
+@Misc{adblockblocks,
+  author =    {Mark Sweney},
+  title =     {City AM becomes first UK newspaper to ban ad blocker users},
+  howpublished = {\url{http://www.theguardian.com/media/2015/oct/20/city-am-ban-ad-blocker-users}},
+  month =     {October},
+  year =      {2015},
+}
+
+@Misc{munichicecream,
+  author =    {Timot Szent-Ivanyi},
+  title =     {Wie Firmen ihre Kassen manipulieren},
+  howpublished = {\url{http://www.fr-online.de/wirtschaft/steuerhinterziehung-wie-firmen-ihre-kassen\-manipulieren-,1472780,31535960.html}},
+  month =     {August},
+  year =      {2015},
+}
+
+@InProceedings{pets2004kuegler,
+  author =       {Dennis K\"ugler},
+  title =        {On the Anonymity of Banknotes},
+  booktitle = {Privacy Enhancing Technologies},
+  year =      {2004},
+  pages =     {108--120},
+  publisher = {Springer Verlag},
+}
+
+@PhdThesis{holz2014,
+  author =       {Ralph Holz},
+  title =        {Empirical analysis of Public Key Infrastructures and investigation of
+improvements},
+  school =       {TU Munich},
+  year =         {2014},
+}
+
+
+@misc{Bankrate,
+  author = {Chris Kahn},
+  site = {Bankrate.com},
+  title = {May 2014 Financial Security Index charts},
+  year = 2014,
+  url = {http://www.bankrate.com/finance/consumer-index/financial-security-charts-0514.aspx},
+  urldate = {2016-02-10},
+  note = {[Online; Accessed: 2016-02-10]}
+}