You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What should the "success" condition for a bll expression be? (ie, what result(s) from the expression should be treated as "the input is authorised to be spent as part of this transaction", vs "this tx is invalid")
Anything except nil -- logical, matches the success path of the if opcode
Exactly the single byte atom \x01 -- matches the result of (not (= 1 2)), limits malleability
Exactly nil -- is the result of the (softfork) opcode, matches what chia would see as "no additional requirements", limits malleability
Anything that is not an exception -- very broad
Any atom other than nil -- similar to bitcoin's "cleanscript" rule
Any atom that is not equivalent to 0 -- matches bitcoin's rule
I think I'm leaning towards "anything that is not an exception". However, a problem with that is it's annoying to convert falseyness to an exception, you have to write (a (i (CONDITION) nil '(x))).
Perhaps it would be worth having a "verify" opcode, so you could reduce that to (verify (CONDITION)), where verify acts like x if its argument is nil, but evaluates to 1 otherwise. In that case, if you had an expression that expected to be run in one of the contexts above, you could convert it to context 4 as:
(verify (CONDITION))
(verify (= 1 (CONDITION)))
(verify (notall (CONDITION)))
(CONDITION)
(verify (| (CONDITION)))
(verify (+ (CONDITION)))
which feels like a more reasonable level of overhead.
The text was updated successfully, but these errors were encountered:
What should the "success" condition for a bll expression be? (ie, what result(s) from the expression should be treated as "the input is authorised to be spent as part of this transaction", vs "this tx is invalid")
\x01-- matches the result of(not (= 1 2)), limits malleability(softfork)opcode, matches what chia would see as "no additional requirements", limits malleabilityI think I'm leaning towards "anything that is not an exception". However, a problem with that is it's annoying to convert falseyness to an exception, you have to write
(a (i (CONDITION) nil '(x))).Perhaps it would be worth having a "verify" opcode, so you could reduce that to
(verify (CONDITION)), where verify acts likexif its argument is nil, but evaluates to 1 otherwise. In that case, if you had an expression that expected to be run in one of the contexts above, you could convert it to context 4 as:(verify (CONDITION))(verify (= 1 (CONDITION)))(verify (notall (CONDITION)))(CONDITION)(verify (| (CONDITION)))(verify (+ (CONDITION)))which feels like a more reasonable level of overhead.
The text was updated successfully, but these errors were encountered: