diff options
Diffstat (limited to 'design-documents/013-peer-to-peer-payments.rst')
| -rw-r--r-- | design-documents/013-peer-to-peer-payments.rst | 41 |
1 files changed, 32 insertions, 9 deletions
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst index c44ab348..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,6 +376,8 @@ 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 + 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 (coin) deposits and **merges** involving the purse. @@ -422,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, @@ -703,7 +705,6 @@ database.) (merge_request_serial_id BIGSERIAL UNIQUE ,reserve_uuid BYTEA NOT NULL REFERENCES reserves (reserve_uuid) ON DELETE CASCADE ,partner_serial_id INT8 REFERENCES partners(partner_serial_id) ON DELETE CASCADE, - ,reserve_url TEXT NOT NULL, ,reserve_pub BYTEA NOT NULL CHECK (LENGTH(reserve_pub)=32), ,purse_pub BYTEA NOT NULL CHECK (LENGTH(purse_pub)=32), ,reserve_sig BYTEA NOT NULL CHECK (LENGTH(reserve_sig)=64)) @@ -721,8 +722,6 @@ database.) IS 'identifies the reserve'; COMMENT ON COLUMN mergers.partner_serial_id IS 'identifies the partner exchange, NULL in case the target reserve lives at this exchange'; - COMMENT ON COLUMN mergers.reserve_url - IS 'payto://-URL of the reserve, identifies the exchange and the reserve'; COMMENT ON COLUMN mergers.reserve_pub IS 'public key of the target reserve'; COMMENT ON COLUMN mergers.purse_pub @@ -821,7 +820,6 @@ database.) CREATE TABLE IF NOT EXISTS purse_deposits (purse_deposit_serial_id BIGSERIAL UNIQUE ,purse_pub BYTEA NOT NULL CHECK (LENGTH(purse_pub)=32), - ,purse_expiration INT8 NOT NULL ,coin_pub BYTEA NOT NULL REFERENCES known_coins (coin_pub) ON DELETE CASCADE ,amount_with_fee_val INT8 NOT NULL ,amount_with_fee_frac INT4 NOT NULL @@ -832,8 +830,6 @@ database.) IS 'Requests depositing coins into a purse'; COMMENT ON COLUMN purse_deposits.purse_pub IS 'Public key of the purse'; - COMMENT ON COLUMN purse_deposits.purse_expiration - IS 'When the purse is set to expire'; COMMENT ON COLUMN purse_deposits.coin_pub IS 'Public key of the coin being deposited'; COMMENT ON COLUMN purse_deposits.amount_with_fee_val @@ -1072,6 +1068,33 @@ Aside from implementation complexity, the solution has the following drawbacks: account private key before initiating the KYC process. +Refinements +=========== + +In the original design, a payer making a payment offer sends the purse private +key to the payee, so that the payee can sign the merge request with it. This +creates a security issue, as theoretically the payee could sign a different +contract with the purse private key, and conspire with the exchange to replace +the original contract. In this case, the payer would be making a payment to +the "wrong" contract, and have no proof of the exchange an payee conspiring +against it. + +A simple fix seems possible: instead of having simply one public-private key +pair for a purse, we have a PayerContractKey and a PurseMergeKey pair. The payer +would pay into a purse identified by the PayerContractKey and associate a +PurseMergeKey with the purse. The payer can then safely share the +PayeeMergeKey with the payee, as it is ONLY useful for the merge and not to +sign the contract. Payments would be made into a purse identified by the +PurseContractKey. + +When payments flow in the other direction, the split of the keys seems +unnecessary (as only a public key is transmitted anyway. However, schema-wise, +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 ===== |