public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matt Corallo <lf-lists@mattcorallo•com>
To: Russell O'Connor <roconnor@blockstream•io>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
Date: Mon, 11 Mar 2019 22:23:33 -0400	[thread overview]
Message-ID: <FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com> (raw)
In-Reply-To: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

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 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).

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.

Matt

> On Mar 11, 2019, at 15:15, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 
> Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (overhead for varints) = 572ish bytes should be enough to completely eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transactions without the need to remove it ever.  I think it is worth attempting to be a bit more clever than such a blunt rule, but it would be much better than eliminating OP_CODESEPARATOR within P2SH entirely.
> 
> Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulnerability associated with it.
> 
>> On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> What about putting it in a deprecated state for some time. Adjust the transaction weight so using the op code is more expensive (10x, 20x?) and get the word out that it will be removed in the future.
>> 
>> You could even have nodes send a reject code with the message “OP_CODESEPARATOR is depcrecated.”
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 4246 bytes --]

  reply	other threads:[~2019-03-12  2:23 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 [this message]
2019-03-13  1:38                 ` Russell O'Connor
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=FD3AE549-3DD4-48E0-9804-73BFBB30A9B0@mattcorallo.com \
    --to=lf-lists@mattcorallo$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=roconnor@blockstream$(echo .)io \
    /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