-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MCIP Draft - Recoverable SCIs #62
base: main
Are you sure you want to change the base?
Conversation
| --------------- | --------------------- | | ||
| 0x0301 | SCI generation memo | | ||
| 0x0302 | SCI cancellation memo | | ||
| 0x0003 | SCI sender memo | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a sender memo? We're imagining these scis are mostly traded around via the deqs, so it is unlikely that the identify of the sci creator is known to the sci executor.
I suppose it's probably still useful for the sci executor to note the quantities that were exchanged to obtain the output.
We should probably also put the information about the partial fill ratio on the change output sent to the sci creator since they probably also need that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth mentioning that the consumer of the SCI, who includes a TxOut to pay back the originator change as part of a partial fill, cannot alter the memo, so it is up to the originator to put something there.
There should probably be a memo type that indicates this is a change or partial change - there could be required change input rule (represented as a required output) and/or a partial change input rule.
I'm not sure what information we'd want to include in that memo. Some things we might consider putting there are the public key of the original TxOut, and maybe for partial change the max amount that was available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good start, thanks for writing this. I think it needs to lay out very specifically which memo goes into all the following TxOuts involved:
- The TxOut that goes into the SCI_SUBADDRESS_INDEX
- The TxOut that cancels an SCI by self-spending an output from the SCI_SUBADDRESS_INDEX
- Any required outputs - https://github.com/mobilecoinfoundation/mobilecoin/blob/master/transaction/core/src/input_rules.rs#L34
- Any partial fill outputs - https://github.com/mobilecoinfoundation/mobilecoin/blob/master/transaction/core/src/input_rules.rs#L46
- Partial fill change output - https://github.com/mobilecoinfoundation/mobilecoin/blob/master/transaction/core/src/input_rules.rs#L60
- TxOuts generated by the consumer of an SCI to pay themselves whatever they are taking from the SCI
|
||
The `TxOut` generated for use as the SCI must contain an `SCI Generation Memo` to identify the details of the SCI it was included in (specifics TBD as feature evolves from feedback and discussion) | ||
|
||
After an SCI is sent, an app can check if it has been claimed based on if this `TxOut` has been spent. Until it has been spent, the app can potentially cancel the `SCI` by sending a self payment with the `TxOut`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's worth elaborating on how the app differentiates between canceling an SCI and the SCI being used. In both cases the TxOut will get spent.
| --------------- | --------------------- | | ||
| 0x0301 | SCI generation memo | | ||
| 0x0302 | SCI cancellation memo | | ||
| 0x0003 | SCI sender memo | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's worth mentioning that the consumer of the SCI, who includes a TxOut to pay back the originator change as part of a partial fill, cannot alter the memo, so it is up to the originator to put something there.
There should probably be a memo type that indicates this is a change or partial change - there could be required change input rule (represented as a required output) and/or a partial change input rule.
I'm not sure what information we'd want to include in that memo. Some things we might consider putting there are the public key of the original TxOut, and maybe for partial change the max amount that was available?
Rendered MCIP