Skip to content
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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

MCIP Draft - Recoverable SCIs #62

wants to merge 4 commits into from

Conversation

briancorbin
Copy link

@briancorbin briancorbin commented Mar 2, 2023

@briancorbin briancorbin changed the title Recoverable SCIs MCIP Draft - Recoverable SCIs Mar 2, 2023
| --------------- | --------------------- |
| 0x0301 | SCI generation memo |
| 0x0302 | SCI cancellation memo |
| 0x0003 | SCI sender memo |
Copy link
Contributor

@wjuan-mob wjuan-mob Mar 2, 2023

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.

Copy link
Contributor

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?

Copy link
Contributor

@eranrund eranrund left a 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:

  1. The TxOut that goes into the SCI_SUBADDRESS_INDEX
  2. The TxOut that cancels an SCI by self-spending an output from the SCI_SUBADDRESS_INDEX
  3. Any required outputs - https://github.com/mobilecoinfoundation/mobilecoin/blob/master/transaction/core/src/input_rules.rs#L34
  4. Any partial fill outputs - https://github.com/mobilecoinfoundation/mobilecoin/blob/master/transaction/core/src/input_rules.rs#L46
  5. Partial fill change output - https://github.com/mobilecoinfoundation/mobilecoin/blob/master/transaction/core/src/input_rules.rs#L60
  6. 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`.
Copy link
Contributor

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 |
Copy link
Contributor

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants