From f4fde30c5b0412dae0b991961f6bc887d4e735a5 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Tue, 5 Nov 2019 09:55:13 -0500 Subject: [PATCH 1/6] Create 0000-payment-proofs.md --- text/0000-payment-proofs.md | 64 +++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 text/0000-payment-proofs.md diff --git a/text/0000-payment-proofs.md b/text/0000-payment-proofs.md new file mode 100644 index 0000000..99ea8b7 --- /dev/null +++ b/text/0000-payment-proofs.md @@ -0,0 +1,64 @@ +- Title: payment-proofs +- Authors: [David Burkett](mailto:davidburkett38@gmail.com) + +--- + +# Summary +[summary]: #summary + +Support generating and validating payment proofs for sender-initiated (ie. non-invoice) transactions. + +# Motivation +[motivation]: #motivation + +Bitcoin and other cryptocurrencies with transparent protocol-level addressing and immutable, unpruneable blockchains can prove sender, receiver, and amounts of payments simply by pointing to the transaction in the blockchain. +Grin's privacy and scalability means users no longer have this ability. This prevents some merchants from accepting Grin due to the high possibility of payment disputes that are unresolvable in the same way they are for transparent coins. + +This RFC proposes a change to the transaction building process where payers can require payees to create a "proof" they've received a payment before the payer finalizes and broadcasts the transaction. + +# Community-level explanation +[community-level-explanation]: #community-level-explanation + +From an end-user perspective, payers can require payees to prove receipt of funds as part of the transacting process. +Payers can then use these "proofs", along with information from the blockchain, to resolve payment disputes and prove funds were sent to the correct payee, and the transaction was confirmed on the blockchain. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +## Common workflow + +## Slate changes + +## Generating proofs + +## Verifying proofs + +## Wallet actions +### init-send + +### receive + +### finalize + +# Drawbacks +[drawbacks]: #drawbacks + +* Drawback 1 +* Drawback 2 + +# Unresolved questions +[unresolved-questions]: #unresolved-questions + +* Can this be adapted to work for invoices? +* Question 2 + +# Future possibilities +[future-possibilities]: #future-possibilities + +None + +# References +[references]: #references + +None + From e170da0bce97c2843b3e233cd85e65ca6caed7b6 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Tue, 12 Nov 2019 05:37:35 -0500 Subject: [PATCH 2/6] Update 0000-payment-proofs.md --- text/0000-payment-proofs.md | 52 ++++++++++++++++++++++++++++++++----- 1 file changed, 45 insertions(+), 7 deletions(-) diff --git a/text/0000-payment-proofs.md b/text/0000-payment-proofs.md index 99ea8b7..fb25150 100644 --- a/text/0000-payment-proofs.md +++ b/text/0000-payment-proofs.md @@ -25,32 +25,69 @@ Payers can then use these "proofs", along with information from the blockchain, # Reference-level explanation [reference-level-explanation]: #reference-level-explanation -## Common workflow - ## Slate changes +A new, optional, structure (`payment_info`) will be added to transaction slates, along with a version increase. The structure will contain: + +* `message` - Optional message to include in the payment proof. Limited to 100(?) characters. +* `sender_address` - Optional ed25519 public key generated by the sender. +* `receiver_address` - An ed25519 public key for the receiver, typically the public key of the user's v3 onion address. +* `receiver_signature` - A signature of the sender_address, received amount, and kernel commitment that validates against the `receiver_address`. + ## Generating proofs -## Verifying proofs +Receipt confirmations (`receiver_signature`s) will be generated by the payee by providing an ED25519 signature of: `(amount || kernel_commitment || sender_address || message)`, using the private key of the `receiver_address`. + +If a `sender_address` was provided, then `sender_signature` can be generated for `(amount || kernel_commitment || sender_address || message)` using the private key of the `sender_address`. + +Sender will then create and store the following info, which can be considered the complete `payment_proof`: + +* `receiver_address` +* `receiver_signature` +* `amount` +* `kernel_commitment` +* `sender_address` (OPTIONAL) +* `sender_signature` (OPTIONAL) +* `message` (OPTIONAL) + +## Verifying Proofs + +This `payment_proof` can be provided by the sender at any time to convince a payee that a payment was made to them. The proof can be verified as follows: + +1. Ensure the `kernel_commitment` is confirmed on-chain. +2. Verify that the `receiver_address` belongs to the payee. +3. Verify that the `receiver_signature` is valid. +4. If a `sender_address` was included, verify that a valid `sender_signature` was provided. ## Wallet actions ### init-send +As part of the first step of the tx-building process, the sender/payer can optionally choose to generate the `sender_address` using their keychain. + +The `receiver_address`, optional keychain path of the `sender_address`, and the optional `message` must be stored locally, along with the `slate_id`. + +The `sender_address`, `receiver_address`, and `messsage` will then be added to the `payment_proof` structure of the slate. + ### receive +If the `payment_proof` structure exists on the slate, it is mandatory that the `receiver_signature` is generated and added to the slate as part of the receive tx-building step. + ### finalize +Using the `slate_id`, the sender can retrieve the original `sender_address`, `receiver_address`, and `message` that were included in the slate, and verify that those fields remain unchanged. The sender must then validate the `receiver_signature`. If any of the original `payment_proof` slate fields were modified, or if the `receiver_signature` is invalid, the transaction must be rejected by the sender. + +Once the `payment_info` details have been validated, the sender can generate and store the `payment_proof` (See `Generating Proofs` above), and then finalize the transaction as normal. + # Drawbacks [drawbacks]: #drawbacks -* Drawback 1 -* Drawback 2 +None # Unresolved questions [unresolved-questions]: #unresolved-questions +* Should the `sender_address` and `sender_signature` be optional, required, or removed entirely? * Can this be adapted to work for invoices? -* Question 2 # Future possibilities [future-possibilities]: #future-possibilities @@ -60,5 +97,6 @@ None # References [references]: #references -None +* Tx slate structure: https://github.com/mimblewimble/grin-wallet/blob/master/libwallet/src/slate.rs +* Beam's approach: https://github.com/BeamMW/beam/blob/c9beb0eae55fa6b7fb3084ebe9b5db2850cf83b9/wallet/wallet_db.cpp#L3231-L3236 From b98b647f99bcb575569d5899a1f225ec137551d0 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Tue, 12 Nov 2019 05:40:58 -0500 Subject: [PATCH 3/6] Update 0000-payment-proofs.md --- text/0000-payment-proofs.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-payment-proofs.md b/text/0000-payment-proofs.md index fb25150..a128a01 100644 --- a/text/0000-payment-proofs.md +++ b/text/0000-payment-proofs.md @@ -27,7 +27,7 @@ Payers can then use these "proofs", along with information from the blockchain, ## Slate changes -A new, optional, structure (`payment_info`) will be added to transaction slates, along with a version increase. The structure will contain: +A new (optional) structure (`payment_info`) will be added to transaction slates, along with a version increase. The `payment_info` structure will contain: * `message` - Optional message to include in the payment proof. Limited to 100(?) characters. * `sender_address` - Optional ed25519 public key generated by the sender. @@ -98,5 +98,4 @@ None [references]: #references * Tx slate structure: https://github.com/mimblewimble/grin-wallet/blob/master/libwallet/src/slate.rs -* Beam's approach: https://github.com/BeamMW/beam/blob/c9beb0eae55fa6b7fb3084ebe9b5db2850cf83b9/wallet/wallet_db.cpp#L3231-L3236 - +* Beam's payment proof model: https://github.com/BeamMW/beam/blob/c9beb0eae55fa6b7fb3084ebe9b5db2850cf83b9/wallet/wallet_db.cpp#L3231-L3236 From 5a59f6c8817a30b166c6553e45de9554a3dc2198 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Thu, 14 Nov 2019 14:38:01 -0500 Subject: [PATCH 4/6] Addressing comments --- text/0000-payment-proofs.md | 44 +++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/text/0000-payment-proofs.md b/text/0000-payment-proofs.md index a128a01..e66fc5e 100644 --- a/text/0000-payment-proofs.md +++ b/text/0000-payment-proofs.md @@ -1,26 +1,28 @@ - Title: payment-proofs - Authors: [David Burkett](mailto:davidburkett38@gmail.com) - +- Start date: Nov 5, 2019 +- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) +- Tracking issue: [Edit if merged with link to tracking github issue] --- # Summary [summary]: #summary -Support generating and validating payment proofs for sender-initiated (ie. non-invoice) transactions. +Support generating and validating payment proofs for sender-initiated (i.e. non-invoice) transactions. # Motivation [motivation]: #motivation -Bitcoin and other cryptocurrencies with transparent protocol-level addressing and immutable, unpruneable blockchains can prove sender, receiver, and amounts of payments simply by pointing to the transaction in the blockchain. +Bitcoin and other cryptocurrencies with transparent protocol-level addressing and immutable, unprunable blockchains can prove sender, receiver, and amounts of payments simply by pointing to the transaction in the blockchain. Grin's privacy and scalability means users no longer have this ability. This prevents some merchants from accepting Grin due to the high possibility of payment disputes that are unresolvable in the same way they are for transparent coins. -This RFC proposes a change to the transaction building process where payers can require payees to create a "proof" they've received a payment before the payer finalizes and broadcasts the transaction. +This RFC changes the transaction building process where payers can require payees to create a "proof" they've received a payment before the payer finalizes and broadcasts the transaction. # Community-level explanation [community-level-explanation]: #community-level-explanation From an end-user perspective, payers can require payees to prove receipt of funds as part of the transacting process. -Payers can then use these "proofs", along with information from the blockchain, to resolve payment disputes and prove funds were sent to the correct payee, and the transaction was confirmed on the blockchain. +Payers can then use these "proofs" to resolve payment disputes and prove they sent funds to the correct payee. # Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -30,15 +32,15 @@ Payers can then use these "proofs", along with information from the blockchain, A new (optional) structure (`payment_info`) will be added to transaction slates, along with a version increase. The `payment_info` structure will contain: * `message` - Optional message to include in the payment proof. Limited to 100(?) characters. -* `sender_address` - Optional ed25519 public key generated by the sender. +* `sender_address` - An ed25519 public key generated by the sender. * `receiver_address` - An ed25519 public key for the receiver, typically the public key of the user's v3 onion address. * `receiver_signature` - A signature of the sender_address, received amount, and kernel commitment that validates against the `receiver_address`. ## Generating proofs -Receipt confirmations (`receiver_signature`s) will be generated by the payee by providing an ED25519 signature of: `(amount || kernel_commitment || sender_address || message)`, using the private key of the `receiver_address`. +Receipt confirmations (`receiver_signature`) will be generated by the payee by providing an ED25519 signature of: `(amount || kernel_commitment || sender_address || message)`, using the private key of the `receiver_address`. -If a `sender_address` was provided, then `sender_signature` can be generated for `(amount || kernel_commitment || sender_address || message)` using the private key of the `sender_address`. +The `sender_signature` can be generated for `(amount || kernel_commitment || sender_address || message)` using the private key of the `sender_address`. Sender will then create and store the following info, which can be considered the complete `payment_proof`: @@ -46,8 +48,8 @@ Sender will then create and store the following info, which can be considered th * `receiver_signature` * `amount` * `kernel_commitment` -* `sender_address` (OPTIONAL) -* `sender_signature` (OPTIONAL) +* `sender_address` +* `sender_signature` * `message` (OPTIONAL) ## Verifying Proofs @@ -57,14 +59,14 @@ This `payment_proof` can be provided by the sender at any time to convince a pay 1. Ensure the `kernel_commitment` is confirmed on-chain. 2. Verify that the `receiver_address` belongs to the payee. 3. Verify that the `receiver_signature` is valid. -4. If a `sender_address` was included, verify that a valid `sender_signature` was provided. +4. Verify that the `sender_signature` is valid. ## Wallet actions ### init-send -As part of the first step of the tx-building process, the sender/payer can optionally choose to generate the `sender_address` using their keychain. +As part of the first step of the tx-building process, the sender/payer generates the `sender_address` using their keychain. -The `receiver_address`, optional keychain path of the `sender_address`, and the optional `message` must be stored locally, along with the `slate_id`. +The `receiver_address`, keychain path of the `sender_address`, and the optional `message` must be stored locally, along with the `slate_id`. The `sender_address`, `receiver_address`, and `messsage` will then be added to the `payment_proof` structure of the slate. @@ -81,18 +83,28 @@ Once the `payment_info` details have been validated, the sender can generate and # Drawbacks [drawbacks]: #drawbacks -None +* Increases the size of tx slates. +* Possibility of privacy leakage through address reuse. + +# Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +* This design works well with TOR tx building, yet is generic enough to work with all known transacting mechanisms. + +# Prior art +[prior-art]: #prior-art + +* Wallet713 implements payment proofs for grinbox transactions, which our design adapts and builds on to work more seemlessly with onion addresses and with transaction building methods that don't inherently rely on addresses. # Unresolved questions [unresolved-questions]: #unresolved-questions -* Should the `sender_address` and `sender_signature` be optional, required, or removed entirely? * Can this be adapted to work for invoices? # Future possibilities [future-possibilities]: #future-possibilities -None +* Payment proofs could potentially be added to invoice payments in the future, but at the cost of an additional round of communication. # References [references]: #references From 22d3835de1ec816de765c29ea4c3b5559d86a1b6 Mon Sep 17 00:00:00 2001 From: David Burkett Date: Wed, 20 Nov 2019 06:34:11 -0500 Subject: [PATCH 5/6] Removing message field --- text/0000-payment-proofs.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/text/0000-payment-proofs.md b/text/0000-payment-proofs.md index e66fc5e..44b270a 100644 --- a/text/0000-payment-proofs.md +++ b/text/0000-payment-proofs.md @@ -31,16 +31,15 @@ Payers can then use these "proofs" to resolve payment disputes and prove they se A new (optional) structure (`payment_info`) will be added to transaction slates, along with a version increase. The `payment_info` structure will contain: -* `message` - Optional message to include in the payment proof. Limited to 100(?) characters. * `sender_address` - An ed25519 public key generated by the sender. * `receiver_address` - An ed25519 public key for the receiver, typically the public key of the user's v3 onion address. * `receiver_signature` - A signature of the sender_address, received amount, and kernel commitment that validates against the `receiver_address`. ## Generating proofs -Receipt confirmations (`receiver_signature`) will be generated by the payee by providing an ED25519 signature of: `(amount || kernel_commitment || sender_address || message)`, using the private key of the `receiver_address`. +Receipt confirmations (`receiver_signature`) will be generated by the payee by providing an ED25519 signature of: `(amount || kernel_commitment || sender_address)`, using the private key of the `receiver_address`. -The `sender_signature` can be generated for `(amount || kernel_commitment || sender_address || message)` using the private key of the `sender_address`. +The `sender_signature` can be generated for `(amount || kernel_commitment || sender_address)` using the private key of the `sender_address`. Sender will then create and store the following info, which can be considered the complete `payment_proof`: @@ -50,7 +49,6 @@ Sender will then create and store the following info, which can be considered th * `kernel_commitment` * `sender_address` * `sender_signature` -* `message` (OPTIONAL) ## Verifying Proofs @@ -66,9 +64,9 @@ This `payment_proof` can be provided by the sender at any time to convince a pay As part of the first step of the tx-building process, the sender/payer generates the `sender_address` using their keychain. -The `receiver_address`, keychain path of the `sender_address`, and the optional `message` must be stored locally, along with the `slate_id`. +The `receiver_address` and keychain path of the `sender_address` must be stored locally, along with the `slate_id`. -The `sender_address`, `receiver_address`, and `messsage` will then be added to the `payment_proof` structure of the slate. +The `sender_address` and `receiver_address` will then be added to the `payment_proof` structure of the slate. ### receive @@ -76,7 +74,7 @@ If the `payment_proof` structure exists on the slate, it is mandatory that the ` ### finalize -Using the `slate_id`, the sender can retrieve the original `sender_address`, `receiver_address`, and `message` that were included in the slate, and verify that those fields remain unchanged. The sender must then validate the `receiver_signature`. If any of the original `payment_proof` slate fields were modified, or if the `receiver_signature` is invalid, the transaction must be rejected by the sender. +Using the `slate_id`, the sender can retrieve the original `sender_address` and `receiver_address` that were included in the slate, and verify that those fields remain unchanged. The sender must then validate the `receiver_signature`. If any of the original `payment_proof` slate fields were modified, or if the `receiver_signature` is invalid, the transaction must be rejected by the sender. Once the `payment_info` details have been validated, the sender can generate and store the `payment_proof` (See `Generating Proofs` above), and then finalize the transaction as normal. From 7d25a3668a7d30a421d587f2297aa471f9dd122b Mon Sep 17 00:00:00 2001 From: David Burkett Date: Mon, 2 Dec 2019 10:04:07 -0500 Subject: [PATCH 6/6] Update and rename 0000-payment-proofs.md to 0006-payment-proofs.md --- text/{0000-payment-proofs.md => 0006-payment-proofs.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-payment-proofs.md => 0006-payment-proofs.md} (96%) diff --git a/text/0000-payment-proofs.md b/text/0006-payment-proofs.md similarity index 96% rename from text/0000-payment-proofs.md rename to text/0006-payment-proofs.md index 44b270a..3438be7 100644 --- a/text/0000-payment-proofs.md +++ b/text/0006-payment-proofs.md @@ -1,8 +1,8 @@ - Title: payment-proofs - Authors: [David Burkett](mailto:davidburkett38@gmail.com) - Start date: Nov 5, 2019 -- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/0000) -- Tracking issue: [Edit if merged with link to tracking github issue] +- RFC PR: Edit if merged: [mimblewimble/grin-rfcs#0006](https://github.com/mimblewimble/grin-rfcs/pull/31) +- Tracking issue: [mimblewimble/grin-wallet#265](https://github.com/mimblewimble/grin-wallet/issues/265) --- # Summary