diff options
Diffstat (limited to 'design-documents/013-peer-to-peer-payments.rst')
| -rw-r--r-- | design-documents/013-peer-to-peer-payments.rst | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst index da4b4bbc..20124532 100644 --- a/design-documents/013-peer-to-peer-payments.rst +++ b/design-documents/013-peer-to-peer-payments.rst @@ -1,5 +1,5 @@ -Design Doc 013: Wallet-to-Wallet Payments -######################################### +DD 13: Wallet-to-Wallet Payments +################################ Summary ======= @@ -376,7 +376,7 @@ In this protocol variant, the payer is initiating the process. 3. The payer shares the purse's private key and the base URL of the exchange where the purse was created with the payee. This can be done using a ``taler://purse/$BASE_URL/$PURSE_PRIV`` URL. - The chapter on ``Refinements'' below clarifies why this + The chapter on ``Refinements`` below clarifies why this step is not quite OK and was modified when implementing the design. 4. The payee uses the new ``/purse/$PURSE_PUB`` endpoint to retrieve the encrypted contract (if available) and purse balance, which includes all @@ -424,7 +424,7 @@ Payment requests 1. The payee creates a **purse** by computing a public-private key pair. 2. The payee POSTs to the ``/purse/$PURSE_PUB/merge`` endpoint to - both upload the encrypted contract, associate it with the payer's + both upload the encrypted contract, associate it with the payee's account and signal its agreement to the contract. The **merge** request must be signed by the purse's private key. A second signature must be provided by the account private key, @@ -1067,7 +1067,7 @@ Aside from implementation complexity, the solution has the following drawbacks: as the wallet software can trivially ensure that a backup was made of the account private key before initiating the KYC process. - + Refinements =========== @@ -1093,7 +1093,7 @@ signing the contract with the PurseContractKey and the merge with the PurseMergeKey would still work. Only the public PurseContractKey would need to be sent to the payer. - + Q / A ===== |