effectfully

> By introducing a special builtin, it seems we are going backwards: for the special case of equality we want to do it this other way. Equality and serialization. They...

> My point is that I'd like to be convinced that this is the best viable approach to this problem, and so far I remain unconvinced That is fair enough...

> Also I'm not saying that you are proposing something that is not sensible, I pointed out some possible drawbacks. Eek, sorry, I didn't express myself properly. To provide some...

I've amended the Preface section (mentioning that the proposal doesn't really address the community split properly) and added three new sections: - Parametricity issues - Security of the system as...

> to change the language (add the canonical type) It's not a change to the language, just another built-in type (unless you consider that to be a change to the...

> I'd mildly prefer to merge it, I think it's easier to find notes like this if they're in-tree. Still useful even if it's incomplete (we have lots of incomplete...

@michaelpj could you please take a look at this one?

Unfortunately, Michael is going to be on leave for a while. I've been jumping around asking people if there's a way to convert a `PubKey` to a `PubKeyHash` on-chain, but...

The Plutus Tools team pointed me to how a `PubKey` gets [converted](https://github.com/input-output-hk/plutus-apps/blob/6951f572251b32cb47e16c2049c963af16722a00/plutus-ledger/src/Ledger/Crypto.hs#L107-L112) to a `PubKeyHash`. That conversion function uses `Blake2b_224`, but we only have `Blake2b_256` on-chain, so it doesn't seem...

> Looking on previous such issues (byte operations or something like that), I think this is up for CIP, cuz changes user primops list. Is that right? Yeah, that's what...