CIP-0070? | Add rejected CIP for spending policies

[michaelpj]

This adds a rejected CIP recording a possible design that has been discussed in the past for "spending policies". I wanted to have somewhere to point when it comes up, and also to publicly record the reasons why designs like this are difficult.

---

see rendered Markdown

[rphair]

I understand this proposal at a high level but would want @KtorZ and/or @SebastienGllmt to agree that it should be put on record with these details.

@michaelpj I also think it's appropriate to have a Rejected status and have argued for this in #331 (comment)... expecting your earlier conversation there will be resolved in favour of adding the Rejected status back into the CIP workflow 😎

[michaelpj]

Yeah, this can have whatever the "not gonna happen" status is, when you decide on one :)

[KtorZ]

Suggested change

	Created: 23/09/2022
	Created: 2022-09-23

ISO-8601 please 🙏

[michaelpj]

This should probably actually become a CPS.

[zygomeb]

@michaelpj

I've recently discussed that this could be implemented in a way that I don't believe was discussed before -- that we can modify the event that triggers a spending policy to only happen when we move tokens between two different spending addresses (no invocation on any other change).

I believe that would be sufficient to create tokens that

1. blacklist addresses
2. have custom fees
3. have claw back (more annoying to implement but possible)

This would also allow us to safely use them in wallets as at any time the user may isolate the token to a 'garbage' utxo.

[michaelpj]

I've recently discussed that this could be implemented in a way that I don't believe was discussed before -- that we can modify the event that triggers a spending policy to only happen when we move tokens between two different spending addresses (no invocation on any other change).

1. Can you be more specific about the triggering condition? Bear in mind that many tokens are fungible, so there is not necessarily a clear answer about which tokens moved where.
2. Are you suggesting that spending policies would only trigger in this context, or that they can somehow choose not to trigger if the transfer is to the same address?
3. I don't think this fundamentally makes things easier: wallets still become largely unable to reliably transfer tokens to other people, which is one of the main functionalities of a wallet!

[zygomeb]

1. Can you be more specific about the triggering condition? Bear in mind that many tokens are fungible, so there is not necessarily a clear answer about which tokens moved where.

On: transfer of token from a locking/spending address A to a spending address B. A change of stake key and change of datum (and any other utxo-carried information) does not trigger the Spending policy to run under this definition.

2. Are you suggesting that spending policies would only trigger in this context, or that they can somehow choose not to trigger if the transfer is to the same address?

Only in this context. Choosing to not act IMO should be done inside the script.

3. I don't think this fundamentally makes things easier: wallets still become largely unable to reliably transfer tokens to other people, which is one of the main functionalities of a wallet!

Yes, but that case is now largely silo'd out into outgoing transfers which may now be isolated and understood on a case by case basis. The feature is a burden for wallets but now we can build an off-chain knowledge base to be able to construct transactions in a way that this spending policy would find acceptable.

[KtorZ]

Flagging this as "Waiting for author" from @michaelpj's earlier comment:

This should probably actually become a CPS.

Seems like a good idea to me indeed; we've taken quite some time processing that proposal and although we agreed with the general idea, CPS didn't exist at the time and could now be a better fit indeed. I am fine either way: merging as an inactive CIP or turning this to a CPS.

[rphair]

Note @zygomeb @fallen-icarus (as you have shown some interested) that this indeed should have been a CPS... unfortunately we were not fortunate enough, as the CPS was evolving, to have the benefit of Michael's understanding in rewriting this as a CPS.

We have to close this now because editors don't have the skills to rephrase it as a CPS, but someone in the community might take that over: likely as a new PR since the authorship would be different. Editors are standing by to cross-reference the old & new discussions if that ever happens. cc @Ryun1 @Crypto2099