-
Notifications
You must be signed in to change notification settings - Fork 95
SIP-040: SIP for improved post-conditions #257
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
base: main
Are you sure you want to change the base?
SIP-040: SIP for improved post-conditions #257
Conversation
|
@brice-stacks can you move the files into the expected structure? |
Co-authored-by: wileyj <2847772+wileyj@users.noreply.github.com>
Co-authored-by: wileyj <2847772+wileyj@users.noreply.github.com>
|
|
||
| - https://forum.stacks.org/t/improved-post-conditions/18661 | ||
|
|
||
| # Abstract |
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.
Is it worth mentioning that this sip is a rider for SIP-039, and if that sip is approved this one follows the same activation?
or is this SIP intended to activate separately?
| reverting to signing `Allow` mode transactions, just to make it work. This is a | ||
| very bad habit to teach our users, and we can do better. What the user really | ||
| cares about is something like, "When I call contract X, at most `m` STX and `n` | ||
| USDCx may be moved from my wallet." They don't care if contract X sends sBTC to | ||
| contract Y, which sends USDCx to contract Z, etc. `Originator` mode allows the | ||
| user to specify only the restrictions on their own assets, allowing any | ||
| movements of assets amongst other principals. |
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.
| reverting to signing `Allow` mode transactions, just to make it work. This is a | |
| very bad habit to teach our users, and we can do better. What the user really | |
| cares about is something like, "When I call contract X, at most `m` STX and `n` | |
| USDCx may be moved from my wallet." They don't care if contract X sends sBTC to | |
| contract Y, which sends USDCx to contract Z, etc. `Originator` mode allows the | |
| user to specify only the restrictions on their own assets, allowing any | |
| movements of assets amongst other principals. | |
| reverting to signing `Allow` mode transactions, just to make it work. What users typically | |
| prefer is something like, "When I call contract X, at most `m` STX and `n` | |
| USDCx may be moved from my wallet.", and less so if contract X sends sBTC to | |
| contract Y, which sends USDCx to contract Z, etc. `Originator` mode allows the | |
| user to specify only the restrictions on their own assets, allowing any | |
| movements of assets amongst other principals. |
I hope i kept the intent in this section, but i felt it was important to not ascribe emotion to what users may or may not want.
| The transaction encoding reserves 1-byte for the non-fungible condition code. | ||
| `MAY SEND` adds a new acceptable value for this byte, `0x12`. | ||
|
|
||
| ## Updates to the SIP-005 Specification |
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.
hmmm - i wonder if we need a way to differentiate when a SIP replaces an older one -as well as- updates an existing spec. 🤔
| - This SIP will activate in epoch 3.4 together with | ||
| [SIP-clarity5](../sip-clarity5/sip-clarity5.md) |
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.
Please update with SIP numbers (039).
This SIP proposes two new post-condition improvements,
Originatormode, and aMAY SENDcondition for NFTs.