Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2CA89CC2 for ; Tue, 12 Mar 2019 22:39:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f45.google.com (mail-io1-f45.google.com [209.85.166.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A6EDF829 for ; Tue, 12 Mar 2019 22:39:41 +0000 (UTC) Received: by mail-io1-f45.google.com with SMTP id x3so3587613ior.6 for ; Tue, 12 Mar 2019 15:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I/TIwsJ1t0mR9LCUdLNkAsOco86Yaof7cS4aqa/bbYI=; b=K+Yqsd8IfIrsC8hqyfyuk9z5A0R8rYeIWN6HO4LY2VfYN3VnO4scAfL8bv+ejgOczO w11gKvxOKYmfQReGkZ+iWSUZSZVNPWzmFbOUdGfpgla0+SlVVPuMyQ0VJIzQlDR8dgD+ xd/kmDcPJd3ZI5g2+JRMXlvOttdr0LU3qS74cFEKj1k5BqJed/XdXCsDWMlDScenUwng qBu79yDEfxGpthbVXOxj+EbjvIpcj+tjN0nJulPR1Z878M/2bx/92hXpgilLh9ndI8lE +L92i5u/zmQA2nn/SdrooSwMSz619X5y4vfv933BeyVRanJd6rLsjiEE7xiKW09EMACf 7kPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I/TIwsJ1t0mR9LCUdLNkAsOco86Yaof7cS4aqa/bbYI=; b=FJsO5S+gso1SxulffT9lk28xlsfmis3e3rVdcUEC8MdWZ0l4YKGs8ZQs5We2RvjWpp r24+EYmfToQTmsVd0lYaKS6K/s7mNvpyCs2WS9M+2Uk4XTHlNgXwnwYZuTZhLivvRO41 oEz55jC/Z5jT9qVbbZ87aPnGRgBSezQHA4GXLIfW2MbaqXAwijLPlaUg2G1XzWcly7ye Jxqlz7CEpBN759D7kHlR/VHGyc0q/kv1Dv9ByQEKtc972+ZIec/SZfeC4pJ0ckTX4+hR fbD7NygRLv27xdOkvTelGZSAXn9e+mQeBozgZg8WnFaIHfkkRXyEmOYNaV9ZYra35n9I M1YQ== X-Gm-Message-State: APjAAAWywQHBEBIpVXD4pEGmkwhf0MPHLtSGFlDq/mhZfkq5Y7mpg5DU wSm/r+n2zuUKhhc8Mnhi9RmsYKR09pjisAv7r7ewBQ== X-Google-Smtp-Source: APXvYqzxGoxtzckjky7RmHrtFLKQHeJUBQmSCVC70eAHT6sZFK0SwFQLe8qLYd2EBIPwcbVmYmky5e/1S7Ds8GAHd9Q= X-Received: by 2002:a6b:e418:: with SMTP id u24mr13251312iog.128.1552430380823; Tue, 12 Mar 2019 15:39:40 -0700 (PDT) MIME-Version: 1.0 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> <88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com> In-Reply-To: <88C160CE-F2CE-4D6E-BA1F-40E219A1659E@mattcorallo.com> From: Jacob Eliosoff Date: Tue, 12 Mar 2019 18:39:28 -0400 Message-ID: To: Matt Corallo , Bitcoin Dev Content-Type: multipart/alternative; boundary="0000000000006339fe0583ed5d14" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 13 Mar 2019 00:41:46 +0000 Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 22:39:42 -0000 --0000000000006339fe0583ed5d14 Content-Type: text/plain; charset="UTF-8" Also, if future disabling isn't the point of making a tx type like OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite support of these oddball features, what do we gain by making them hard to use/mine? I see questions like "Is it possible someone's existing tx relies on this?" as overly black-and-white. We all agree it's possible: the question is how likely, vs the harms of continued support - including not just security risks but friction on other useful changes, safety/correctness analyses, etc. It is so easy to say stuff like this when one's own money isn't what is at risk. Stepping back for a second here: I dispute this framing. My money *is* at risk, because the value of my bitcoins depends on adoption and feature growth. And I've long viewed an absolutist, actual-known-user-indifferent approach to backwards compatibility as the #1 impediment to Bitcoin's adoption and growth. Again, the point being not to throw caution to the wind, but that a case like this where extensive research unearthed zero users, is taking caution too far. On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Note that even your carve-outs for OP_NOP is not sufficient here - if you > were using nSequence to tag different pre-signed transactions into > categories (roughly as you suggest people may want to do with extra sighash > bits) then their transactions could very easily have become > un-realistically-spendable. The whole point of soft forks is that we > invalidate otherwise-unused bits of the protocol. This does not seem > inconsistent with the proposal here. > > > On Mar 9, 2019, at 13:29, Russell O'Connor > wrote: > > Bitcoin has *never* made a soft-fork, since the time of Satoishi, that > invalidated transactions that send secured inputs to secured outputs > (excluding uses of OP_NOP1-OP_NOP10). > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --0000000000006339fe0583ed5d14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also, if future disabling isn't the point of making a= tx type like OP_CODESEPARATOR non-standard - what is?=C2=A0 If we're c= ommitted to indefinite support of these oddball features, what do we gain b= y making them hard to use/mine?

I see questions like "Is it possible someone's existing tx relie= s on this?" as overly black-and-white.=C2=A0 We all agree it's pos= sible: the question is how likely, vs the harms of continued support - incl= uding not just security risks but friction on other useful changes, safety/= correctness analyses, etc.

It is so easy to say stuff like this when one's own money i= sn't what is at risk.
<= /div>

Stepping back for a seco= nd here:=C2=A0 I dispute this framing.=C2=A0 My money is at risk, be= cause the value of my bitcoins depends on adoption and feature growth.=C2= =A0 And I've long viewed an absolutist, actual-known-user-indifferent a= pproach to backwards compatibility as the #1 impediment to Bitcoin's ad= option and growth.

Again, the = point being not to throw caution to the wind, but that a case like this whe= re extensive research unearthed zero users, is taking caution too far.
<= div dir=3D"auto">

On Tue, Mar 12, 2019, 5:48 PM Matt Corallo vi= a bitcoin-dev <= bitcoin-dev@lists.linuxfoundation.org> wrote:
Note that even your carve-outs for OP_NOP is not sufficie= nt here - if you were using nSequence to tag different pre-signed transacti= ons into categories (roughly as you suggest people may want to do with extr= a sighash bits) then their transactions could very easily have become un-re= alistically-spendable. The whole point of soft forks is that we invalidate = otherwise-unused bits of the protocol. This does not seem inconsistent with= the proposal here.

> On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@block= stream.io> wrote:
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that= invalidated transactions that send secured inputs to secured outputs (excl= uding uses of OP_NOP1-OP_NOP10).

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev

--0000000000006339fe0583ed5d14--