Let me first confirm one thing: I believe smaller granularity of OTX, where we guard single field than a full cell, is not without its merits. But the past trials of OTX also taught us a valuable lesson: in the quest of CKB, we always aim at flexibility. But the truth is: flexibility has its costs, when a model is too flexible, it might also be hard to make sure it is secure. I do personally believe that you are underestimating the efforts by augmenting an Action to impose finer constraints. We could disagree here of course, what I’m trying to explain here, is that I do want to start simple in the current OTX Cobuild protocol.
If later we understand this protocol better, and believe finer-grained guards provide enough advantages while being completely understood, we can definitely introduce those extra features to cobuild. But shall we do that now? I have my concerns.
In CKB, we now have 3 different levels of flexibility:
- A sighash-all signed transaction, where every piece in the transaction is signed. No modification is allowed
- An OTX, where certain input / output cells are fully guarded. No modifications to those cells are allowed
- An OTX with custom actions, it might guard certain input cells, but allowing arbitrary output cells satisfying the additional rules required in actions
We are now arguing if we need a level 2.5, where part of the output cells are guarded via OTX rules, but other part of the output cells are guarded by rules provided by actions. Personally, I would wait to see the answer to the following 2 questions:
- Is it really true that level 2 does not provide enough flexibility for certain cases?
- Is there any rule that is particularly hard to enforce via custom actions?
You mentioned that we can use Action to impose finer constraints on output cells, I personally believe this is totally doable, and should also be the answer when you only need constraints on part of output cells.
Note in previous discussions, I mentioned that I have my concerns augmenting an Action to an OTX for further constraints. Let me be clear: I have no problems with OTX Cobuild protocol, where OTX protocol guards full output cells, I also have no problems using custom Actions to guard part of output cells. But I do have a problem mixing OTX Cobuild protocol and custom Actions, where one field might be guarded by OTX protocol, but another field would be validated by custom Actions. Personally I believe this to be a dangerous thing.
What’s more, if you stick strictly to custom Actions validated by a single lock / type script, Cell Output Reusing Attack won’t really be a problem here. The said lock / type script can already ensure different output cells contribute to different OTX.