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: Thu, 7 Mar 2019 19:50:52 +0000	[thread overview]
Message-ID: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> (raw)
In-Reply-To: <CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>

Replies inline.

Matt

On 3/7/19 3:03 PM, Russell O'Connor wrote:
> 
>     * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation.
>     This includes OP_CODESEPARATORs in unexecuted branches of if
>     statements,
>     similar to other disabled opcodes, but unlike OP_RETURN.
> 
> 
> OP_CODESEPARATOR is the only mechanism available that allows users to 
> sign which particular branch they are authorizing for within scripts 
> that have multiple possible conditions that reuse the same public key.

This is true, and yet it does not appear to actually be practically 
usable. Thus far, despite a ton of effort, I have not yet seen a 
practical use-case for OP_CODESEPARATOR (except for one example of it 
being used to make SegWit scripts ever-so-slightly more effecient in 
TumbleBit, hence why this BIP does not propose disabling it for SegWit).

> Because of P2SH you cannot know that no one is currently using this 
> feature.  Activating a soft-fork as describe above means these sorts of 
> funds would be permanently lost.  It is not acceptable to risk people's 
> money like this.

(1) It has been well documented again and again that there is desire to 
remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in 
non-segwit scripts represents a rather significant vulnerability in 
Bitcoin today, and (3) lots of effort has gone into attempting to find 
practical use-cases for OP_CODESEPARATOR's specific construction, with 
no successes as of yet. I strongly, strongly disagree that the 
highly-unlikely remote possibility that someone created something before 
which could be rendered unspendable is sufficient reason to not fix a 
vulnerability in Bitcoin today.

> I suggest an alternative whereby the execution of OP_CODESEPARATOR 
> increases the transactions weight suitably as to temper the 
> vulnerability caused by it.  Alternatively there could be some sort of 
> limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be 
> executed per script, but that would require an argument as to why 
> exceeding that limit isn't reasonable.

You could equally argue, however, that any such limit could render some 
moderately-large transaction unspendable, so I'm somewhat skeptical of 
this argument. Note that OP_CODESEPARATOR is non-standard, so getting 
them mined is rather difficult in any case.


  reply	other threads:[~2019-03-07 19:50 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-06 21:39 [bitcoin-dev] BIP Proposal: The Great Consensus Cleanup 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 [this message]
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
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=6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com \
    --to=lf-lists@mattcorallo.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=roconnor@blockstream.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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