[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated (b4f52c3 -> be360fc)
From: |
gnunet |
Subject: |
[taler-docs] branch master updated (b4f52c3 -> be360fc) |
Date: |
Mon, 26 Apr 2021 16:36:56 +0200 |
This is an automated email from the git hooks/post-receive script.
dold pushed a change to branch master
in repository docs.
from b4f52c3 update man page
new b89b917 remove logspam
new be360fc formatting fixes
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
_exts/typescriptdomain.py | 1 -
design-documents/013-peer-to-peer-payments.rst | 6 +++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/_exts/typescriptdomain.py b/_exts/typescriptdomain.py
index ac6e4b8..50ffdc0 100644
--- a/_exts/typescriptdomain.py
+++ b/_exts/typescriptdomain.py
@@ -420,7 +420,6 @@ class LinkingHtmlFormatter(HtmlFormatter):
+ "#"
+ r1[1]
)
- print(f"relative URL from {self._bridge.docname} to {r1[0]} is
{rel_uri}")
return (
'<a style="color:inherit;text-decoration:underline"
href="%s">%s</a>'
% (rel_uri, content)
diff --git a/design-documents/013-peer-to-peer-payments.rst
b/design-documents/013-peer-to-peer-payments.rst
index c96fd46..8087af5 100644
--- a/design-documents/013-peer-to-peer-payments.rst
+++ b/design-documents/013-peer-to-peer-payments.rst
@@ -139,6 +139,7 @@ Contract metadata for W2W payments can be exchanged in
three ways:
2. The payee can create a **purse** and immediately associate it with
an **account** by sending a signed **merge** request together with
the (encrypted) contract.
+
a. The purse creation request created by the payee must include a
signature with the account private key of the payee signing the purse
public key and the hash of the contract, thereby affirming that
@@ -148,6 +149,7 @@ Contract metadata for W2W payments can be exchanged in
three ways:
by paying the **purse fee**.
3. The payer can store a contract with the exchange by POSTing
an encrypted contract to the exchange as part of creating a **purse**.
+
a. The exchange charges the **purse fee** to payers for purses that
are refunded after not being **merged**.
b. When paying into a purse, the coin signature includes the purse
@@ -264,6 +266,7 @@ In this protocol variant, the payer is initiating the
process.
affirming that the payee accepted the contract.
The account is of the form
``payto://taler/$EXCHANGE_BASE_URL/$ACCOUNT_PUB``.
7. Processing continues depending on the location of the account:
+
a. If the ``$EXCHANGE_BASE_URL`` matches the local exchange, then
the exchange processes the **merge** request akin to the logic
for payments into known accounts, as detailed above.
@@ -304,6 +307,7 @@ Payment requests
5. The payer software decrypts the encrypted contract using the purse private
key and the payer accepts the contract in the user interface.
6. Processing continues depending on the source of the coins:
+
a. If the payer's coins originate from the same exchange, the
payer software POSTs to the ``/purse/$PURSE_PUB/depost`` endpoint to
deposit coins into the purse. The deposit signatures should use
@@ -573,7 +577,7 @@ Q / A
* Refunds are not possible with purses after they are closed.
* The customer cannot prove that they own the contract terms
(Contract terms claiming requires interactivity that is not
- possible in all W2W scenarios.) Thus, while payers can prove
+ possible in all W2W scenarios.) Thus, while payers can prove
that they paid, the payee may claim someone else also
bought the same product. A secure channel must thus be used to
exchange the purchase offer.
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-docs] branch master updated (b4f52c3 -> be360fc),
gnunet <=