From: "Russell O'Connor" <roconnor@blockstream•io>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
Date: Tue, 12 Mar 2019 21:38:44 -0400 [thread overview]
Message-ID: <CAMZUoK=NKfxMpDs18R1VUGg5YcwiTXUaTcE+H7RSArn0fBMjDw@mail.gmail.com> (raw)
In-Reply-To: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 4426 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 5502 bytes --]
next prev parent reply other threads:[~2019-03-13 1:38 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-06 21:39 [bitcoin-dev] " Matt Corallo
2019-03-07 10:44 ` Luke Dashjr
2019-03-07 19:44 ` Matt Corallo
2019-03-07 15:03 ` [bitcoin-dev] OP_CODESEPARATOR " Russell O'Connor
2019-03-07 19:50 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-08 18:35 ` Matt Corallo
2019-03-09 18:29 ` Russell O'Connor
2019-03-10 3:25 ` Jacob Eliosoff
2019-03-11 17:49 ` Russell O'Connor
2019-03-12 21:08 ` Matt Corallo
2019-03-12 22:39 ` Jacob Eliosoff
2019-03-13 0:54 ` Gregory Maxwell
2019-03-13 1:34 ` Russell O'Connor
2019-03-08 19:12 ` Sjors Provoost
2019-03-08 20:14 ` Matt Corallo
2019-03-10 14:25 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:24 ` Moral Agent
2019-03-12 7:34 ` LORD HIS EXCELLENCY JAMES HRMH
2019-03-10 18:28 ` Dustin Dettmer
2019-03-11 19:15 ` Russell O'Connor
2019-03-12 2:23 ` Matt Corallo
2019-03-13 1:38 ` Russell O'Connor [this message]
2019-03-09 18:29 ` Russell O'Connor
[not found] ` <PS2P216MB0179EFBEF7BEEE1C3F251F719D4E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
2019-03-10 15:22 ` Russell O'Connor
2019-03-07 15:16 ` [bitcoin-dev] Sighash Type Byte; " Russell O'Connor
2019-03-07 19:57 ` Matt Corallo
2019-03-08 15:57 ` Russell O'Connor
2019-03-13 1:34 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMZUoK=NKfxMpDs18R1VUGg5YcwiTXUaTcE+H7RSArn0fBMjDw@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox