From 8e991e6494d3a8bde3dea74b5d5124b20988ef73 Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Wed, 14 Jul 2021 22:39:44 +0200 Subject: [PATCH 01/12] Manual confirmation initial draft --- text/0000-manual-confirmation.md | 115 +++++++++++++++++++++++++++++++ 1 file changed, 115 insertions(+) create mode 100644 text/0000-manual-confirmation.md diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md new file mode 100644 index 0000000..d3c497e --- /dev/null +++ b/text/0000-manual-confirmation.md @@ -0,0 +1,115 @@ +- Title: manual-confirmation +- Authors: [David Tavarez](mailto:david@punksec.com) +- Start date: July 14, 2021 +- RFC PR: [mimblewimble/grin-rfcs#0021](https://github.com/mimblewimble/grin-rfcs/pull/) +- Tracking issue: https://github.com/mimblewimble/grin/issues/ + +--- + +## Summary +[summary]: #summary + +This RFC defines the API changes and additions required to give users the ability of manually joinning the transaction building process in a synchronous transaction scenario. Synchronous transaction are done via the Tor network. + +## Motivation +[motivation]: #motivation + +Mimblewimble transactions are interactive, this doesn't necessarily mean that parties have to be online, they just need to be able to communicate with each other at some point. This gives the recepient the opportunity to refuse being involved in a transaction, but currently when a slatepack address is provided, this is not possible. The `SlatepackAddress` is not only used to encrypt asynchronous transactions but also to route synchronous transactions. By default when a request is received, the grin wallet is automatically adding the receipient's signature data [1] and returning the slatepack including this signature data. While automatically adding the recipient's signature data is convenient, it takes away users' freedom to have full control over their own wallets, which is a key advantage of the Mimblewimble protocol. The ability of refusing incoming transactions is only possible when transactions are non interactive, like in Mimblewimble. + +Manually acceptance of incoming transactions also adds: + +- Protection of an Output Injection (or Dust attact) in users' wallet. +- Consistency between Sender-Reciver-Sender (SRS) flow and the Receiver-Sender-Receiver (RSR) one. +- The ability of both parties involved in the transaction to confirm the amount of the transaction. + +This helps users to understand Grin better, and it is a unique feature that Grin users can benefit from. We also gain the ability for both the sender and the receiver to commit to an arbitrary statement/document with our transaction. This is because they both can read what they're commiting to before they confirm (sign) the transaction. + +## Community-level explanation +[community-level-explanation]: #community-level-explanation + +This an opt-in feature, disabled by default, that can be enabled by setting to true a configuration flag named `manual_confirmation`. + +When a request to build a synchronous transaction is received, the wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on, if it is, the receiver's wallet will not add the Signature Data to the returned slatepack. After accepting the transaction, the wallet will add the receiver's Signature Data and then it will try to share the partial signed slate with the sender via the Tor network, if the sender wallet is not recheable, the wallet will display the slatepack to the receiver [2]. + +### Singing the transaction offer + +The receiver can then sign the unsigned transaction by specifying the transaction `id` (`-i`) or the `tx-UUID` (`-t`) (obtained by `txs`) to the `sign` command, for example: + +`grin-wallet sign -i 4` + +After entering the command, the wallet will sign the slatepack of the transaction and automatically will try to share it with the sender. If the communication with the sender can't be established, the partial signed slatepack will be displayed. + +If the flag `-n` `--noshare` is present, the transaction will be signed but the wallet won't try to send it to the sender and only will display the partial signed slatepack. + +## Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +### Configuration + +### `manual_confirmation` + +A new boolean property should be added with the name of `manual_confirmation`, this property is optional and the default value is `false`. The grin wallet will look for this property in the configuration file, if the property is not found the value should set to `false`. + +### API changes + +### Foreign RPC API + +### `receive_tx` + +The `receive_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the receipient's signature data will no be added to the slate, neither the receipient payment proof. The status in this case will be `Receiving (Unsigned)`. + +### Owner RPC API + +### `init_send_tx` + +Currently, when a recipient address is provided, this endpoint tries to share the transaction offer with the recepient via Tor. Now, it will validate if the receipient's signature data is present in the received slate response. It will return a message notifying that the recepient did not sign the transaction if recepient's signature data is not found. + +### API additions + +### Foreign RPC API + +### `receive_tx_sig` + +The `receive_tx_sig` endpoint adds the a signature data to the corresponding transaction. It tries to finalized the transaction if it is possible, and returns the same output as the `finalize_tx` endpoint. + +### Owner RPC API + +### `sign_tx` + +The `sign_tx` endpoint adds the receipient's signature data and the corresponding payment proof to a specified transaction. It starts a synchronous transaction with the sender, if the transaction can not be finalized by the sender, the transaction slatepack is returned. + +### Commands + +### `sign` command + +Users will be able of signing the transaction using the `sign` command. This command receives either the `id` or the `UUID` of the transaction, adds the participant data and returns the partially signed slatepack of the transaction. + +## Drawbacks +[drawbacks]: #drawbacks + +None! + +## Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +There is no compelling reason for leaving a height dependency in the fee method. + +## Unresolved questions +[unresolved-questions]: #unresolved-questions + +Should the use of this feature be encouraged? +Could be `manual_confirmation = true` the default state? +Will this work for more than 2 participants? + +## Future possibilities +[future-possibilities]: #future-possibilities + +Manually confirmations could be useful if we implement at some point a `memo` field for the `payment proof`. Sender and receiver could agree on accepting a document/file attached to the transaction. + +## References +[references]: #references + + +[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) + +[2] [RFC-0015](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0015-slatepack.md) From 5d338d24fa58022e861b9f75d47a02292789576e Mon Sep 17 00:00:00 2001 From: David Tavarez <337107+davidtavarez@users.noreply.github.com> Date: Wed, 14 Jul 2021 22:49:05 +0200 Subject: [PATCH 02/12] Update 0000-manual-confirmation.md --- text/0000-manual-confirmation.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index d3c497e..4c31fa5 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -1,7 +1,7 @@ - Title: manual-confirmation - Authors: [David Tavarez](mailto:david@punksec.com) - Start date: July 14, 2021 -- RFC PR: [mimblewimble/grin-rfcs#0021](https://github.com/mimblewimble/grin-rfcs/pull/) +- RFC PR: [mimblewimble/grin-rfcs#0000](https://github.com/mimblewimble/grin-rfcs/pull/) - Tracking issue: https://github.com/mimblewimble/grin/issues/ --- @@ -87,12 +87,11 @@ Users will be able of signing the transaction using the `sign` command. This com ## Drawbacks [drawbacks]: #drawbacks -None! +None. ## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives -There is no compelling reason for leaving a height dependency in the fee method. ## Unresolved questions [unresolved-questions]: #unresolved-questions From 826f3e1dd0306c370712214f2dd60b44103fe21a Mon Sep 17 00:00:00 2001 From: David Tavarez <337107+davidtavarez@users.noreply.github.com> Date: Mon, 19 Jul 2021 11:46:44 +0200 Subject: [PATCH 03/12] Update 0000-manual-confirmation.md --- text/0000-manual-confirmation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 4c31fa5..4ce6eff 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -27,7 +27,7 @@ This helps users to understand Grin better, and it is a unique feature that Grin ## Community-level explanation [community-level-explanation]: #community-level-explanation -This an opt-in feature, disabled by default, that can be enabled by setting to true a configuration flag named `manual_confirmation`. +This is an opt-in feature, disabled by default, that can be enabled by setting to true a configuration flag named `manual_confirmation`. When a request to build a synchronous transaction is received, the wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on, if it is, the receiver's wallet will not add the Signature Data to the returned slatepack. After accepting the transaction, the wallet will add the receiver's Signature Data and then it will try to share the partial signed slate with the sender via the Tor network, if the sender wallet is not recheable, the wallet will display the slatepack to the receiver [2]. From c53fccf273d276477e0f5fc2800790ae8d210b5a Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Mon, 19 Jul 2021 11:42:22 +0200 Subject: [PATCH 04/12] better wording --- text/0000-manual-confirmation.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 4ce6eff..957bb1b 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -29,7 +29,7 @@ This helps users to understand Grin better, and it is a unique feature that Grin This is an opt-in feature, disabled by default, that can be enabled by setting to true a configuration flag named `manual_confirmation`. -When a request to build a synchronous transaction is received, the wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on, if it is, the receiver's wallet will not add the Signature Data to the returned slatepack. After accepting the transaction, the wallet will add the receiver's Signature Data and then it will try to share the partial signed slate with the sender via the Tor network, if the sender wallet is not recheable, the wallet will display the slatepack to the receiver [2]. +When the grin wallet receive a request to build a transaction synchronously, the grin wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on, if it is, the receiver's wallet will not automatically add the `Signature Data` if the receiver to the returned slatepack. The receiver could now accept the incomming request and add the `Signature Data`. After manually accepting the transaction using the UI, the wallet will add the receiver's Signature Data and then it will try to share the partial signed slate with the sender via the Tor network, if the sender wallet is not recheable, the wallet will display the partially signed slatepack to the receiver [2]. ### Singing the transaction offer @@ -48,7 +48,7 @@ If the flag `-n` `--noshare` is present, the transaction will be signed but the ### `manual_confirmation` -A new boolean property should be added with the name of `manual_confirmation`, this property is optional and the default value is `false`. The grin wallet will look for this property in the configuration file, if the property is not found the value should set to `false`. +A new boolean property should be added with the name of `manual_confirmation` in the configuration, this property is optional and the default value is `false`. If the property is not found the value should set to `false`. ### API changes @@ -56,13 +56,13 @@ A new boolean property should be added with the name of `manual_confirmation`, t ### `receive_tx` -The `receive_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the receipient's signature data will no be added to the slate, neither the receipient payment proof. The status in this case will be `Receiving (Unsigned)`. +The `receive_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the receipient's signature data will no be added to the slate, neither the receipient payment proof. The status in this case will be `Receiving (Unsigned)` for the receiver point of view. ### Owner RPC API ### `init_send_tx` -Currently, when a recipient address is provided, this endpoint tries to share the transaction offer with the recepient via Tor. Now, it will validate if the receipient's signature data is present in the received slate response. It will return a message notifying that the recepient did not sign the transaction if recepient's signature data is not found. +Currently, if the recipient's address is provided, this endpoint tries to share the transaction offer with the recepient via Tor. Now, it will validate whether the recipient's signature data is present in the response received from the recipient's wallet. If the recepient's signature data is not found, it will return a message notifying that the recepient did not sign the transaction. Otherwise, the endpoint's behavior remains as it was before this RFC. ### API additions @@ -76,7 +76,7 @@ The `receive_tx_sig` endpoint adds the a signature data to the corresponding tra ### `sign_tx` -The `sign_tx` endpoint adds the receipient's signature data and the corresponding payment proof to a specified transaction. It starts a synchronous transaction with the sender, if the transaction can not be finalized by the sender, the transaction slatepack is returned. +The `sign_tx` endpoint adds the user's signature data and the corresponding payment proof to a specified transaction. It starts a synchronous transaction with the sender, the transaction slatepack is returned if the sender is not reachable. It is recommendable to internally call the `init_send_tx` owner endpoint to unified the experience. ### Commands From 8e17f86a501f7106a66cf35eb0c297cc67ab2aa9 Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Tue, 20 Jul 2021 22:35:46 +0200 Subject: [PATCH 05/12] adding more details --- text/0000-manual-confirmation.md | 34 ++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 957bb1b..fdb298c 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -14,9 +14,9 @@ This RFC defines the API changes and additions required to give users the abilit ## Motivation [motivation]: #motivation -Mimblewimble transactions are interactive, this doesn't necessarily mean that parties have to be online, they just need to be able to communicate with each other at some point. This gives the recepient the opportunity to refuse being involved in a transaction, but currently when a slatepack address is provided, this is not possible. The `SlatepackAddress` is not only used to encrypt asynchronous transactions but also to route synchronous transactions. By default when a request is received, the grin wallet is automatically adding the receipient's signature data [1] and returning the slatepack including this signature data. While automatically adding the recipient's signature data is convenient, it takes away users' freedom to have full control over their own wallets, which is a key advantage of the Mimblewimble protocol. The ability of refusing incoming transactions is only possible when transactions are non interactive, like in Mimblewimble. +Mimblewimble transactions are interactive, this doesn't necessarily mean that parties have to be online, they just need to be able to communicate with each other at some point. This gives the recepient the opportunity to refuse being involved in a transaction, but currently when a slatepack address is provided, this is not possible. The `SlatepackAddress` is not only used to encrypt asynchronous transactions but also to route synchronous transactions. By default when a request is received, the grin wallet is automatically adding the receipient's signature data [1] and returning the slatepack including this signature data. While automatically adding the recipient's signature data is convenient, it takes away users' freedom to have full control over their own wallets. The ability of refusing incoming transactions is only possible when noninteractive transactions are impossible, like in Mimblewimble. -Manually acceptance of incoming transactions also adds: +Manually accepting incoming transactions also adds: - Protection of an Output Injection (or Dust attact) in users' wallet. - Consistency between Sender-Reciver-Sender (SRS) flow and the Receiver-Sender-Receiver (RSR) one. @@ -31,6 +31,8 @@ This is an opt-in feature, disabled by default, that can be enabled by setting t When the grin wallet receive a request to build a transaction synchronously, the grin wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on, if it is, the receiver's wallet will not automatically add the `Signature Data` if the receiver to the returned slatepack. The receiver could now accept the incomming request and add the `Signature Data`. After manually accepting the transaction using the UI, the wallet will add the receiver's Signature Data and then it will try to share the partial signed slate with the sender via the Tor network, if the sender wallet is not recheable, the wallet will display the partially signed slatepack to the receiver [2]. +Although this is an optional feature, its use should be encouraged. + ### Singing the transaction offer The receiver can then sign the unsigned transaction by specifying the transaction `id` (`-i`) or the `tx-UUID` (`-t`) (obtained by `txs`) to the `sign` command, for example: @@ -56,13 +58,14 @@ A new boolean property should be added with the name of `manual_confirmation` in ### `receive_tx` -The `receive_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the receipient's signature data will no be added to the slate, neither the receipient payment proof. The status in this case will be `Receiving (Unsigned)` for the receiver point of view. - -### Owner RPC API +The `receive_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the receipient's wallet will: +- Avoid adding the participant data (`excess`, `signature` and `nonce` ). +- Avoid adjusting the transaction offset. +- Avoid adding the output(s) to the transaction. -### `init_send_tx` +By doing the above it won't be possible to add the receipient payment proof. The endpoint will then return the same received slatepack. -Currently, if the recipient's address is provided, this endpoint tries to share the transaction offer with the recepient via Tor. Now, it will validate whether the recipient's signature data is present in the response received from the recipient's wallet. If the recepient's signature data is not found, it will return a message notifying that the recepient did not sign the transaction. Otherwise, the endpoint's behavior remains as it was before this RFC. +The status of the transaction in this case will be set as `Receiving (Unsigned)` in the receiver's wallet database. ### API additions @@ -74,9 +77,15 @@ The `receive_tx_sig` endpoint adds the a signature data to the corresponding tra ### Owner RPC API -### `sign_tx` +### `create_tx` -The `sign_tx` endpoint adds the user's signature data and the corresponding payment proof to a specified transaction. It starts a synchronous transaction with the sender, the transaction slatepack is returned if the sender is not reachable. It is recommendable to internally call the `init_send_tx` owner endpoint to unified the experience. +The `create_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the wallet will: +- Add the participant data (`excess`, `signature` and `nonce` ). +- Adjust the transaction offset. +- Add the output(s) to the transaction. +- Add the payment proof to the specified transaction + +It will automatically try to perform a synchronous transaction with the sender, the transaction slatepack is returned if the sender is not reachable. It is recommendable to internally call the `init_send_tx` owner endpoint to unified the experience. ### Commands @@ -89,20 +98,19 @@ Users will be able of signing the transaction using the `sign` command. This com None. -## Rationale and alternatives -[rationale-and-alternatives]: #rationale-and-alternatives - - ## Unresolved questions [unresolved-questions]: #unresolved-questions Should the use of this feature be encouraged? Could be `manual_confirmation = true` the default state? Will this work for more than 2 participants? +Can the the `finalize` replaced? ## Future possibilities [future-possibilities]: #future-possibilities +This also adds the ability for the receiver to manually include a payjoin input in a specific transaction but it should be implemented by the wallets developers. + Manually confirmations could be useful if we implement at some point a `memo` field for the `payment proof`. Sender and receiver could agree on accepting a document/file attached to the transaction. ## References From e353887011148bc65b8054e4173db8572fa37c09 Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Tue, 20 Jul 2021 22:38:42 +0200 Subject: [PATCH 06/12] fixing typos --- text/0000-manual-confirmation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index fdb298c..29090a2 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -101,10 +101,10 @@ None. ## Unresolved questions [unresolved-questions]: #unresolved-questions -Should the use of this feature be encouraged? -Could be `manual_confirmation = true` the default state? +Should the use of this feature be encourage? +Could it be `true` for the `manual_confirmation` configuration property? Will this work for more than 2 participants? -Can the the `finalize` replaced? +Can we replace the `finalize` command by `replaced`? ## Future possibilities [future-possibilities]: #future-possibilities From 44e7660847cfc4ceb85689cc38f823096c162819 Mon Sep 17 00:00:00 2001 From: David Tavarez <337107+davidtavarez@users.noreply.github.com> Date: Mon, 19 Jul 2021 15:28:50 +0200 Subject: [PATCH 07/12] Update 000-manual-confirmation.md --- text/0000-manual-confirmation.md | 39 +++++++++++++++----------------- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 29090a2..844e074 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -9,39 +9,39 @@ ## Summary [summary]: #summary -This RFC defines the API changes and additions required to give users the ability of manually joinning the transaction building process in a synchronous transaction scenario. Synchronous transaction are done via the Tor network. +This RFC defines the API changes and additions necessary to give users the ability to manually accept an incoming transaction. ## Motivation [motivation]: #motivation -Mimblewimble transactions are interactive, this doesn't necessarily mean that parties have to be online, they just need to be able to communicate with each other at some point. This gives the recepient the opportunity to refuse being involved in a transaction, but currently when a slatepack address is provided, this is not possible. The `SlatepackAddress` is not only used to encrypt asynchronous transactions but also to route synchronous transactions. By default when a request is received, the grin wallet is automatically adding the receipient's signature data [1] and returning the slatepack including this signature data. While automatically adding the recipient's signature data is convenient, it takes away users' freedom to have full control over their own wallets. The ability of refusing incoming transactions is only possible when noninteractive transactions are impossible, like in Mimblewimble. +Mimblewimble transactions are interactive, this doesn't necessarily mean that parties have to be online, they just need to be able to communicate with each other at some point. This gives the recipient the opportunity to reject an incoming transaction which is currently not possible. The `SlatepackAddress` is not only used to encrypt asynchronous transactions but also to route synchronous transactions. By default when a recipient's wallet receives the request to participate in the transaction building process, the wallet automatically adds the recipient's signature data [1] and returns a slatepack which includes recipient's signature. While automatically adding the recipient's signature data is convenient, it takes away users' freedom to have full control over their own wallets. The ability of refusing incoming transactions is only possible when transactions are interactive, like in Mimblewimble. -Manually accepting incoming transactions also adds: +Manual acceptance incoming transactions also adds: -- Protection of an Output Injection (or Dust attact) in users' wallet. -- Consistency between Sender-Reciver-Sender (SRS) flow and the Receiver-Sender-Receiver (RSR) one. +- Protection of an Output Injection (or Dust attack) in users' wallet. +- Consistency between Sender-Receiver-Sender (SRS) flow and the Receiver-Sender-Receiver (RSR) one. - The ability of both parties involved in the transaction to confirm the amount of the transaction. -This helps users to understand Grin better, and it is a unique feature that Grin users can benefit from. We also gain the ability for both the sender and the receiver to commit to an arbitrary statement/document with our transaction. This is because they both can read what they're commiting to before they confirm (sign) the transaction. +Manual confirmation helps users understand the interactivity of Grin and are a unique feature that is only possible in protocols with interactive transaction. We also gain the ability for both the sender and the receiver to commit to an arbitrary statement/document with our transaction. This is because they both can read what they're commiting to before they confirm (sign) the transaction. ## Community-level explanation [community-level-explanation]: #community-level-explanation This is an opt-in feature, disabled by default, that can be enabled by setting to true a configuration flag named `manual_confirmation`. -When the grin wallet receive a request to build a transaction synchronously, the grin wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on, if it is, the receiver's wallet will not automatically add the `Signature Data` if the receiver to the returned slatepack. The receiver could now accept the incomming request and add the `Signature Data`. After manually accepting the transaction using the UI, the wallet will add the receiver's Signature Data and then it will try to share the partial signed slate with the sender via the Tor network, if the sender wallet is not recheable, the wallet will display the partially signed slatepack to the receiver [2]. +When the grin wallet receives a request to build a transaction synchronously, the grin wallet will check for the `manual_confirmation` flag to determine if the manual confirmation feature is on. if it is, the recipient's wallet **will not automatically enter to the transaction creation process with the sender**. The receiver could now accept the incomming transaction manually. -Although this is an optional feature, its use should be encouraged. +Although this is an optional feature, we should encourage its use. -### Singing the transaction offer +### Signing the transaction offer The receiver can then sign the unsigned transaction by specifying the transaction `id` (`-i`) or the `tx-UUID` (`-t`) (obtained by `txs`) to the `sign` command, for example: `grin-wallet sign -i 4` -After entering the command, the wallet will sign the slatepack of the transaction and automatically will try to share it with the sender. If the communication with the sender can't be established, the partial signed slatepack will be displayed. +After entering the command, the wallet will sign the transaction, generate a slatepack and automatically try to share it with the sender. If the communication with the sender can't be established, the partial signed slatepack will be displayed. -If the flag `-n` `--noshare` is present, the transaction will be signed but the wallet won't try to send it to the sender and only will display the partial signed slatepack. +If the flag `-n` `--noshare` is present, the transaction will be signed but the wallet won't try to send it to the sender and will only display the partial signed slatepack. ## Reference-level explanation [reference-level-explanation]: #reference-level-explanation @@ -50,7 +50,7 @@ If the flag `-n` `--noshare` is present, the transaction will be signed but the ### `manual_confirmation` -A new boolean property should be added with the name of `manual_confirmation` in the configuration, this property is optional and the default value is `false`. If the property is not found the value should set to `false`. +A new boolean property should be added with the name of `manual_confirmation` in the configuration, this property is optional and the default value is `false`. If the property is not found the value should be set to `false`. ### API changes @@ -73,13 +73,13 @@ The status of the transaction in this case will be set as `Receiving (Unsigned)` ### `receive_tx_sig` -The `receive_tx_sig` endpoint adds the a signature data to the corresponding transaction. It tries to finalized the transaction if it is possible, and returns the same output as the `finalize_tx` endpoint. +The `receive_tx_sig` endpoint adds the signature data to the corresponding transaction. It tries to finalize the transaction if it is possible, and returns the same output as the `finalize_tx` endpoint. ### Owner RPC API ### `create_tx` -The `create_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the wallet will: +The `create_tx` endpoint will receive a transaction as a parameter and it will: - Add the participant data (`excess`, `signature` and `nonce` ). - Adjust the transaction offset. - Add the output(s) to the transaction. @@ -101,10 +101,9 @@ None. ## Unresolved questions [unresolved-questions]: #unresolved-questions -Should the use of this feature be encourage? -Could it be `true` for the `manual_confirmation` configuration property? -Will this work for more than 2 participants? -Can we replace the `finalize` command by `replaced`? +- Could it be true the default value of the `manual_confirmation` configuration property? +- Will this could work for more than 2 participants? +- Can we replace the `finalize` command by the `sign` command? ## Future possibilities [future-possibilities]: #future-possibilities @@ -117,6 +116,4 @@ Manually confirmations could be useful if we implement at some point a `memo` fi [references]: #references -[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) - -[2] [RFC-0015](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0015-slatepack.md) +[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) \ No newline at end of file From b11da84785905638ed66e4ba7101c1d995622ebd Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Tue, 20 Jul 2021 23:33:59 +0200 Subject: [PATCH 08/12] more simple explanation --- text/0000-manual-confirmation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 844e074..289a0ca 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -116,4 +116,4 @@ Manually confirmations could be useful if we implement at some point a `memo` fi [references]: #references -[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) \ No newline at end of file +[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) From 8d2618ea8eace51477b9b610015dd17f48957592 Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Tue, 20 Jul 2021 23:53:59 +0200 Subject: [PATCH 09/12] questions format --- text/0000-manual-confirmation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 289a0ca..844e074 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -116,4 +116,4 @@ Manually confirmations could be useful if we implement at some point a `memo` fi [references]: #references -[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) +[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) \ No newline at end of file From fd3446b1de75e7f40b51122c876413dde1af364f Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Sun, 25 Jul 2021 11:17:39 +0200 Subject: [PATCH 10/12] rebasing branch --- text/0000-manual-confirmation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 844e074..289a0ca 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -116,4 +116,4 @@ Manually confirmations could be useful if we implement at some point a `memo` fi [references]: #references -[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) \ No newline at end of file +[1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) From c6829a4254a8837188c767c5818dcb0ad04520a0 Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Sun, 25 Jul 2021 11:19:06 +0200 Subject: [PATCH 11/12] cleaning file --- text/0000-manual-confirmation.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 289a0ca..1cd8da6 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -59,6 +59,7 @@ A new boolean property should be added with the name of `manual_confirmation` in ### `receive_tx` The `receive_tx` endpoint will check the value of `manual_confirmation`, If `manual_confirmation` is `true` the receipient's wallet will: + - Avoid adding the participant data (`excess`, `signature` and `nonce` ). - Avoid adjusting the transaction offset. - Avoid adding the output(s) to the transaction. @@ -80,6 +81,7 @@ The `receive_tx_sig` endpoint adds the signature data to the corresponding trans ### `create_tx` The `create_tx` endpoint will receive a transaction as a parameter and it will: + - Add the participant data (`excess`, `signature` and `nonce` ). - Adjust the transaction offset. - Add the output(s) to the transaction. From 37dc112e2f60d2a6d50299668f69fd947b9e3868 Mon Sep 17 00:00:00 2001 From: David Tavarez Date: Sat, 7 Aug 2021 10:14:19 +0200 Subject: [PATCH 12/12] adding payment proof reference --- text/0000-manual-confirmation.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-manual-confirmation.md b/text/0000-manual-confirmation.md index 1cd8da6..2e3895b 100644 --- a/text/0000-manual-confirmation.md +++ b/text/0000-manual-confirmation.md @@ -64,7 +64,7 @@ The `receive_tx` endpoint will check the value of `manual_confirmation`, If `man - Avoid adjusting the transaction offset. - Avoid adding the output(s) to the transaction. -By doing the above it won't be possible to add the receipient payment proof. The endpoint will then return the same received slatepack. +By doing the above it won't be possible to add the receipient payment proof[2]. The endpoint will then return the same received slatepack. The status of the transaction in this case will be set as `Receiving (Unsigned)` in the receiver's wallet database. @@ -119,3 +119,4 @@ Manually confirmations could be useful if we implement at some point a `memo` fi [1] [Signature Data](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0012-compact-slates.md#signature-data) +[1] [Payment Proof](https://github.com/mimblewimble/grin-rfcs/blob/master/text/0006-payment-proofs.md)