KIP-0029: Proposal of new guard type: Constant boolean guard

[CryptoPascal31]

The idea is to propose a new guard, the most simple as possible, the easiest to understand.

But it's currently missing, and would be very useful, and would improve the clarity.
Nothing revolutionary.

https://github.com/CryptoPascal31/KIPs/blob/119fe2df7df6a42bba7f46c406ca631aec95e99a/kip-0029.md

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208668844268900

[daplcor]

This seems extremely useful, I assume it would help with things like the function below. You can type specify bool, arrays, objects, strings, but not guards that I am aware of. So we end up having to add extra helper functions which serve no real purpose.
(defcap USERPAY (account:string)
(with-default-read taxes account {'guard: (create-null-guard) } {'guard:=guard}
(if (!= guard (create-null-guard))
(enforce-guard (at 'guard (coin.details account)))
(enforce-guard guard)
)
)
)

(defun enforce-null:bool
()
false)

(defun create-null-guard:guard
()
(create-user-guard (enforce-null)))

[jmcardon]

Apologies for the late reply on this one, but this one is achievable with userland code.

(module m g (defcap g () true)
  (defun enforce-bool (b:bool) (enforce b "boolean guard failed"))
  (defun create-boolean-guard:guard (b:bool) (create-user-guard (enforce-bool b)))

[CryptoPascal31]

Apologies for the late reply on this one, but this one is achievable with userland code.

(module m g (defcap g () true)
  (defun enforce-bool (b:bool) (enforce b "boolean guard failed"))
  (defun create-boolean-guard:guard (b:bool) (create-user-guard (enforce-bool b)))

Yes of course it is.
But IMHO, such a common and simple need should be handled and guaranteed by the language itself.

Plus, having an associated clean principal (as I propose) would improve a lot of transparency and security for non-technical users. Everybody should be able to identify quickly Burn / "Free to use" accounts.

Because with a userland workaround, anybody who wants to verify what's going on:

• need to check the associated userland function,
• check the code of the function.
• check the governance and upgrade conditions of the module...

I can give you an example:
Everybody thinks that the free namespace is "free"... But everybody is wrong, In fact:

• It's guard given by describe-namespace is a user guard to ns.success
• While the function ns.success is correct, the module ns can be upgraded by ns-admin-keyset (probably Kadena 😉)
• Basically, it means that the owners of these keys could revoke the authorization of the free userspace at anytime. => I believe this is obviously not considered... 😃

Having a constant boolean guard, managed by Pact, would allow fulfilling such use-cases more easily and without any possible ambiguity.