diff options
Diffstat (limited to 'design-documents/013-peer-to-peer-payments.rst')
| -rw-r--r-- | design-documents/013-peer-to-peer-payments.rst | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst index 5c0d7d12..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 ======= @@ -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 ===== |