Hi Matt,

On Mon, Mar 11, 2019 at 10:23 PM Matt Corallo <lf-lists@mattcorallo.com> wrote:

I think you may have misunderstood part of the motivation. Yes, part of the motivation *is* to remove OP_CODESEPARATOR wholesale, greatly simplifying the theoretical operation of checksig operations (thus somewhat simplifying the implementation but also simplifying analysis of future changes, such as sighash-caching code).

I see. I was under the mistaken impression the concerns about of OP_CODESEPARATOR was simply due to the vulnerability it induces.

I'll say it now then: Simplifying the theoretical operation of Bitcoin is not a sufficient reason to make changes to the consensus rules, and it is most certainly not a sufficient reason to remove usable op codes.

Had I understood that this was your motivation I would have presented my opinion earlier. I understand that the OP_CODESEPARATOR vulnerability is quite serious and making it non-standard while we address the problem is a good idea (hence the reason why I never objected before now).

What I don't understand is why you feel that avoiding flushing the sigcache is so critical that you are willing to go through a risky consensus change just to achieve it? The sigcache is effectively flushed for each input of a transaction anyways, so what's the big deal about flushing it during Script execution as well?

I think a key part of the analysis here is that no one I've spoken to (and we've been discussing removing it for *years*, including many attempts at coming up with reasons to keep it) is aware of any real proposals to use OP_CODESEPARATOR, let alone anyone using it in the wild. Hiding data in invalid pubic keys is a long-discussed-and-implemented idea (despite it's discouragement, not to mention it appears on the chain in many places).

Well you've spoken to me now, and I believe I have given you good reasons to keep it. We all used to think that OP_CODESEPARATOR was a useless operation that no one in their right mind would ever use, but it turns out that we were wrong. Lesson learned. We should be more humble about considering these sorts of changes in the future because it seems we might not understand Bitcoin as well as we think we do. At the very least I was caught by surprise by the utility of OP_CODESEPARATOR.

You misunderstand my point regarding invalid public keys. My point is that if no one has spoken up about the invalid public key issue on this mailing list, something that we know really does affects people, why do you expect that people would have spoken up about OP_CODESEPARATATOR affecting them?

It would end up being a huge shame to have all the OP_CORESEPARATOR mess left around after all the effort that has gone into removing it for the past few years, especially given the stark difference in visibility of a fork when compared to a standardness change.

As for your specific proposal of increasing the weight of anything that has an OP_CODESEPARATOR in it by the cost of an additional (simple) input, this doesn't really solve the issue. After all, if we're assuming some user exists who has been using sending money, unspent, to scripts with OP_CODESEPARATOR to force signatures to commit to whether some other signature was present and who won't see a (invariably media-covered) pending soft-fork in time to claim their funds, we should also assume such a user has pre-signed transactions which are time-locked and claim a number of inputs and have several paths in the script which contain OP_CODESEPARATOR, rendering their transcription invalid.

Agreed, that's why we will want to not simply count the OP_CODESEPARATORS, but rather count the maximum number of OP_CODESEPARATORS that can be executed through the any of the various possible OP_IF branches. Adding this sort of control-flow analysis is a pretty simple. It just requires a small stack of pairs of numbers and linear traversal through the Script. This sort of OP_IF control flow analysis ought to have been done for counting CHECKSIG operations, but unfortunately it is too late for that now. I could prototype the sort of analysis I have in mind if you think that would be helpful.

In fact, it is really alternating uses of OP_CODESEPARATOR and CheckSig operations that is problematic, so it is probably worth attempting to count these pairs rather than just OP_CODESEPARATORS.