From 6f74c6f120cfe9d2ca48e733a8bd55c4b9933ad0 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sat, 10 Oct 2020 11:44:14 +0200 Subject: [PATCH 1/5] start new RFC --- text/0000-safe-cancel.md | 96 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 96 insertions(+) create mode 100644 text/0000-safe-cancel.md diff --git a/text/0000-safe-cancel.md b/text/0000-safe-cancel.md new file mode 100644 index 00000000..b7d6d869 --- /dev/null +++ b/text/0000-safe-cancel.md @@ -0,0 +1,96 @@ + +- Title: [`safe-cancel`] +- Authors: [John Tromp](mailto:john.tromp@gmail.com) +- Start date: [`Oct 10, 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 + +One paragraph explanation of the improvement. + +## Motivation +[motivation]: #motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +## Community-level explanation +[community-level-explanation]: #community-level-explanation + +Explain the proposal as if it were already introduced into the Grin ecosystem and you were teaching it to another community member. That generally means: + +- Introducing new named concepts. +- Explaining the feature largely in terms of examples. +- Explaining how Grin community members should *think* about the improvement, and how it should impact the way they interact with Grin. It should explain the impact as concretely as possible. +- If applicable, provide sample error messages, deprecation warnings, or migration guidance. +- If applicable, describe the differences between teaching this to existing Grin community members and new Grin community members. + +For implementation-oriented RFCs (e.g. for wallet), this section should focus on how wallet contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. + +## Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +This is the technical portion of the RFC. Explain the design in sufficient detail that: + +- Its interaction with other features is clear. +- It is reasonably clear how the feature would be implemented. +- Corner cases are dissected by example. + +The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. + +## Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +## Rationale and alternatives +[rationale-and-alternatives]: #rationale-and-alternatives + +- Why is this design the best in the space of possible designs? +- What other designs have been considered and what is the rationale for not choosing them? +- What is the impact of not doing this? + +## Prior art +[prior-art]: #prior-art + +Discuss prior art, both the good and the bad, in relation to this proposal. +A few examples of what this can include are: + +- For core, node, wallet and infrastructure proposals: Does this feature exist in other projects and what experience have their community had? +- For community, ecosystem and moderation proposals: Is this done by some other community and what were their experiences with it? +- For other teams: What lessons can we learn from what other communities have done here? +- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. + +This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other projects. + +Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. +Please also take into consideration that Grin sometimes intentionally diverges from common project features. + +## Unresolved questions +[unresolved-questions]: #unresolved-questions + +- What parts of the design do you expect to resolve through the RFC process before this gets merged? +- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? +- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? + +## Future possibilities +[future-possibilities]: #future-possibilities + +Think about what the natural extension and evolution of your proposal would be and how it would affect the project and ecosystem as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and language in your proposal. Also consider how it fits into the road-map of the project and of the relevant sub-team. + +This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. + +If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. + +Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. + +## References +[references]: #references + +Include any references such as links to other documents or reference implementations. + +- [reference 1](link) +- [reference 2](link) From d9f2f2ae9557ff1b9ca0344cd71a39753805077d Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 11 Oct 2020 09:26:44 +0200 Subject: [PATCH 2/5] [WIP] Safe Cancel --- text/0000-safe-cancel.md | 78 +++++++++++++++++----------------------- 1 file changed, 32 insertions(+), 46 deletions(-) diff --git a/text/0000-safe-cancel.md b/text/0000-safe-cancel.md index b7d6d869..6e57b839 100644 --- a/text/0000-safe-cancel.md +++ b/text/0000-safe-cancel.md @@ -1,7 +1,7 @@ -- Title: [`safe-cancel`] +- Title: safe-cancel - Authors: [John Tromp](mailto:john.tromp@gmail.com) -- Start date: [`Oct 10, 2019`] +- Start date: Oct 10, 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] @@ -10,83 +10,69 @@ ## Summary [summary]: #summary -One paragraph explanation of the improvement. +Allow for safe cancellation of pending transactions, preventing future so-called play attacks. ## Motivation [motivation]: #motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +A wallet cannot simply cancel a pending transaction bu forgetting about it and returning its inputs to the wallet balance. +Especially not when the other party is responsible for completing and broadcasting the transaction. +They may still do so at any time as long as the inputs are not spent differently. ## Community-level explanation [community-level-explanation]: #community-level-explanation -Explain the proposal as if it were already introduced into the Grin ecosystem and you were teaching it to another community member. That generally means: +Suppose Bob sends Alice an invoice slatepack to which Alice responds, but then +Bob doesn't finalize it. He might suggest a problem with the invoice, with his +wallet, or the exchange rate, or the (suddenly realized) +need to pay in a different currency. Whatever the case, he convinces Alice to +have the current transaction cancelled. Alice is fine with that, but needs to +make sure that Bob doesn't later complete the transaction and steal Alice's +inputs. -- Introducing new named concepts. -- Explaining the feature largely in terms of examples. -- Explaining how Grin community members should *think* about the improvement, and how it should impact the way they interact with Grin. It should explain the impact as concretely as possible. -- If applicable, provide sample error messages, deprecation warnings, or migration guidance. -- If applicable, describe the differences between teaching this to existing Grin community members and new Grin community members. +Alice has two options; spend a transaction input back to herself, or +construct a new transaction that shares at least one input with the +old transaction. The former is cleaner, but requires separate fees, and possibly waiting +for confirmation. -For implementation-oriented RFCs (e.g. for wallet), this section should focus on how wallet contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms. +The wallet provides a command for each of these options. -## Reference-level explanation -[reference-level-explanation]: #reference-level-explanation +grin-wallet respend [OPTIONS] -This is the technical portion of the RFC. Explain the design in sufficient detail that: +will mark the pending transaction, specified either by ID or TxID UUID, +as requiring one of its inputs to be spent in the very next wallet spend. -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- Corner cases are dissected by example. +grin-wallet unspend [OPTIONS] -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. +will generate and broadcast a self spend of an input of +the pending transaction, specified either by ID or TxID UUID, + +## Reference-level explanation +[reference-level-explanation]: #reference-level-explanation ## Drawbacks [drawbacks]: #drawbacks -Why should we *not* do this? +The user is required to understand the trade-offs between the two types of cancel. ## Rationale and alternatives [rationale-and-alternatives]: #rationale-and-alternatives -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? +The simpler alternative is to always do a self spend. Giving the user control +over whether to spend extra fees seems preferrable though. ## Prior art [prior-art]: #prior-art -Discuss prior art, both the good and the bad, in relation to this proposal. -A few examples of what this can include are: - -- For core, node, wallet and infrastructure proposals: Does this feature exist in other projects and what experience have their community had? -- For community, ecosystem and moderation proposals: Is this done by some other community and what were their experiences with it? -- For other teams: What lessons can we learn from what other communities have done here? -- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background. - -This section is intended to encourage you as an author to think about the lessons from other languages, provide readers of your RFC with a fuller picture. If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other projects. - -Note that while precedent set by other projects is some motivation, it does not on its own motivate an RFC. -Please also take into consideration that Grin sometimes intentionally diverges from common project features. +Coins such as Monero suggest the use of self spends to reduce linkability, but our motivation is quite different, +and with likely no aggregation in the Dandelion stem phase, self-spends in Grin do nothing to reduce linkability. ## Unresolved questions [unresolved-questions]: #unresolved-questions -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before stabilization? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? - ## Future possibilities [future-possibilities]: #future-possibilities -Think about what the natural extension and evolution of your proposal would be and how it would affect the project and ecosystem as a whole in a holistic way. Try to use this section as a tool to more fully consider all possible interactions with the project and language in your proposal. Also consider how it fits into the road-map of the project and of the relevant sub-team. - -This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related. - -If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything. - -Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information. - ## References [references]: #references From 4089f6445897820977d1ba2393a2118b5a9e62ea Mon Sep 17 00:00:00 2001 From: John Tromp Date: Thu, 15 Oct 2020 21:07:50 +0200 Subject: [PATCH 3/5] fixed typo --- text/0000-safe-cancel.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-safe-cancel.md b/text/0000-safe-cancel.md index 6e57b839..b1f89674 100644 --- a/text/0000-safe-cancel.md +++ b/text/0000-safe-cancel.md @@ -15,7 +15,7 @@ Allow for safe cancellation of pending transactions, preventing future so-called ## Motivation [motivation]: #motivation -A wallet cannot simply cancel a pending transaction bu forgetting about it and returning its inputs to the wallet balance. +A wallet cannot simply cancel a pending transaction but forgetting about it and returning its inputs to the wallet balance. Especially not when the other party is responsible for completing and broadcasting the transaction. They may still do so at any time as long as the inputs are not spent differently. From d83056cca2c047bdf164d4020df36e4bb932215d Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 24 Jan 2021 20:04:47 +0100 Subject: [PATCH 4/5] fox typo --- text/0000-safe-cancel.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-safe-cancel.md b/text/0000-safe-cancel.md index b1f89674..fa884ae5 100644 --- a/text/0000-safe-cancel.md +++ b/text/0000-safe-cancel.md @@ -15,7 +15,7 @@ Allow for safe cancellation of pending transactions, preventing future so-called ## Motivation [motivation]: #motivation -A wallet cannot simply cancel a pending transaction but forgetting about it and returning its inputs to the wallet balance. +A wallet cannot simply cancel a pending transaction by forgetting about it and returning its inputs to the wallet balance. Especially not when the other party is responsible for completing and broadcasting the transaction. They may still do so at any time as long as the inputs are not spent differently. From 5a411cda0c3e2d7fde5494d49e1e73f530234cc9 Mon Sep 17 00:00:00 2001 From: John Tromp Date: Sun, 28 Mar 2021 22:44:12 +0200 Subject: [PATCH 5/5] discuss different flows --- text/0000-safe-cancel.md | 22 +++++++++++++++++++--- 1 file changed, 19 insertions(+), 3 deletions(-) diff --git a/text/0000-safe-cancel.md b/text/0000-safe-cancel.md index fa884ae5..db367d30 100644 --- a/text/0000-safe-cancel.md +++ b/text/0000-safe-cancel.md @@ -22,15 +22,16 @@ They may still do so at any time as long as the inputs are not spent differently ## Community-level explanation [community-level-explanation]: #community-level-explanation -Suppose Bob sends Alice an invoice slatepack to which Alice responds, but then -Bob doesn't finalize it. He might suggest a problem with the invoice, with his +Suppose Bob as the receiver sends Alice as the sender an invoice slatepack +(Receiver-Sender-Receiver or RSR flow) to which Alice responds, but then Bob +doesn't finalize it. He might suggest a problem with the invoice, with his wallet, or the exchange rate, or the (suddenly realized) need to pay in a different currency. Whatever the case, he convinces Alice to have the current transaction cancelled. Alice is fine with that, but needs to make sure that Bob doesn't later complete the transaction and steal Alice's inputs. -Alice has two options; spend a transaction input back to herself, or +Alice has two options; spend a transaction input back to herself (a self-spend), or construct a new transaction that shares at least one input with the old transaction. The former is cleaner, but requires separate fees, and possibly waiting for confirmation. @@ -47,6 +48,21 @@ grin-wallet unspend [OPTIONS] will generate and broadcast a self spend of an input of the pending transaction, specified either by ID or TxID UUID, +The problem is not limited to RSR flow. In the more common SRS flow, once the +sender has signed and published the transaction, it can still fail to confirm. + +It could be that one of the nodes in the Dandelion stem drops it, either by +accident or on purpose. Alternatively, it could be explicitly rejected by the +mempool. +The receiver can arrange for that to happen by (slightly earlier) publishing +another transaction with an identical output. When two transaction conflict by +sharing either an input or an output, the first to enter the mempool will block +the second from entering. + +In case the sender's wallet notices that failure to confirm is due to a +conflicting transaction, it should alert the user that the receiver is being +malicious. + ## Reference-level explanation [reference-level-explanation]: #reference-level-explanation