From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 19014BC7 for ; Mon, 27 Nov 2017 21:06:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pl0-f43.google.com (mail-pl0-f43.google.com [209.85.160.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3CB614F for ; Mon, 27 Nov 2017 21:06:40 +0000 (UTC) Received: by mail-pl0-f43.google.com with SMTP id f6so9232756pln.12 for ; Mon, 27 Nov 2017 13:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Roh4lHs0D0vm91/LY0wnNPkAVF/lzi8/OlKC/+aYPFs=; b=LQ/AnLi+nnAd6mOSUFXOLIvuF6VlSHwPtyoLMO4TdqnV+rzZtCcJkTruYnOAb8e3k1 +Ayq99dz4zrnkAjaMAqBZaEKuxGE+MwaleglkwOM9qyi2cMRMDSqxAN5ZOgMowSpULjh YuA9uanMipOYny3IMhZ6hvSKxGgzZwdzGH10kZ8tNtRRcQowhkYM6hgmbJzvSWobRUqu tW7gnGQpAnkHsj71pGKCmPUED+WjAiP8OTKbVvyvv0fXTWkMIRyKKLLd6FmD2uRzgEr9 xJsajqvR+w7PVI+Mja6vjvdaJzaHUyE7iBQ0TcrcOVV+nzthbaBWMwZBbYkSfAcMhW2p S9kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Roh4lHs0D0vm91/LY0wnNPkAVF/lzi8/OlKC/+aYPFs=; b=IbXZC0pK5YcXYK5dhH51+oem9lrKsiIUOUjW5TaS0fshOsUHt6oWCLqlKFyqVVBFnj 106gI+zFgZJenZr0uz9aV33WCCOez5VGWWKNCLQDy9pswTN7s5MPVIK8tZSKi3bqbC7D l01txGSzLH/QheyDMX3rKVN11D26hesZT1A/mABCePP+spWrmCSqGQgoUD3fMhCKn2zK dzP/4ik/PFJG4Eh4DkWqXmlPyG5Pko8sdrkwdV0WwVKt1w5nj2m4eCIHjni7YxpZpJGs Nuzp6fzV2TNG9p9amZxitqh19Ho1LqC/xro8CYffKtqxum5ZJaHi6T4UPiCYanIu689l ijJw== X-Gm-Message-State: AJaThX5w0Tkm+rg5aDg/XWgt6bBZrXhwu1lnptmf1QOPeVUz0nz/oAP+ EvCCXOLtiaTuo0M/k4cjC0Iq3WzkzQY= X-Google-Smtp-Source: AGs4zMZMxLbub9rPZ/rSM8oqEOokmk/Uv92B6xxJzs0MkXr/s6bUQM6+Brt69QTj6xh5A1+a3cc9bg== X-Received: by 10.84.151.69 with SMTP id i63mr39084530pli.61.1511816800215; Mon, 27 Nov 2017 13:06:40 -0800 (PST) Received: from ?IPv6:2601:647:4600:9c66:d9f8:1b52:54ed:ee22? ([2601:647:4600:9c66:d9f8:1b52:54ed:ee22]) by smtp.gmail.com with ESMTPSA id w73sm45307275pfd.86.2017.11.27.13.06.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 13:06:39 -0800 (PST) From: Mark Friedenbach Message-Id: <44B74F02-D3D6-47B9-976E-A72042E5C84B@friedenbach.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_F8A26339-DF8B-4C5F-A071-51C2E85D7F16" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 27 Nov 2017 13:06:35 -0800 In-Reply-To: <56ca1248-6427-46f7-1645-84349cc8facc@mattcorallo.com> To: Matt Corallo References: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> <56ca1248-6427-46f7-1645-84349cc8facc@mattcorallo.com> X-Mailer: Apple Mail (2.3445.4.7) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Making OP_CODESEPARATOR and FindAndDelete in non-segwit scripts non-standard 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: Mon, 27 Nov 2017 21:06:42 -0000 --Apple-Mail=_F8A26339-DF8B-4C5F-A071-51C2E85D7F16 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It is relevant to note that BIP 117 makes an insecure form of = CODESEPARATOR delegation possible, which could be made secure if some = sort of CHECKSIGFROMSTACK opcode is added at a later point in time. It = is not IMHO a very elegant way to achieve delegation, however, so I hope = that one way or another this could be resolved quickly so it doesn=E2=80=99= t hold up either one of those valuable additions. I have no objections to making them nonstandard, or even to make them = invalid if someone with a better grasp of history can attest that = CODESEPARATOR was known to be entirely useless before the introduction = of P2SH=E2=80=94not the same as saying it was useless, but that it was = widely known to not accomplish what a early-days script author might = think it was doing=E2=80=94and the UTXO set contains no scriptPubKeys = making use of the opcode, even from the early days. Although a small = handful could be special cased, if they exist. > On Nov 27, 2017, at 8:33 AM, Matt Corallo = wrote: >=20 > I strongly disagree here - we don't only soft-fork out transactions = that > are "fundamentally insecure", that would be significantly too > restrictive. We have generally been willing to soft-fork out things > which clearly fall outside of best-practices, especially rather > "useless" fields in the protocol eg soft-forking behavior into = OP_NOPs, > soft-forking behavior into nSequence, etc. >=20 > As a part of setting clear best-practices, making things non-standard = is > the obvious step, though there has been active discussion of > soft-forking out FindAndDelete and OP_CODESEPARATOR for years now. I > obviously do not claim that we should be proposing a soft-fork to > blacklist FindAndDelete and OP_CODESEPARATOR usage any time soon, and > assume that it would take at least a year or three from when it was = made > non-standard to when a soft-fork to finally remove them was proposed. > This should be more than sufficient time for folks using such weird = (and > largely useless) parts of the protocol to object, which should be > sufficient to reconsider such a soft-fork. >=20 > Independently, making them non-standard is a good change on its own, = and > if nothing else should better inform discussion about the possibility = of > anyone using these things. >=20 > Matt >=20 > On 11/15/17 14:54, Mark Friedenbach via bitcoin-dev wrote: >> As good of an idea as it may or may not be to remove this feature = from >> the code base, actually doing so would be crossing a boundary that we >> have not previously been willing to do except under extraordinary >> duress. The nature of bitcoin is such that we do not know and cannot >> know what transactions exist out there pre-signed and making use of >> these features. >>=20 >> It may be a good idea to make these features non standard to further >> discourage their use, but I object to doing so with the justification = of >> eventually disabling them for all transactions. Taking that step has = the >> potential of destroying value and is something that we have only done = in >> the past either because we didn=E2=80=99t understand forks and best = practices >> very well, or because the features (now disabled) were fundamentally >> insecure and resulted in other people=E2=80=99s coins being = vulnerable. This >> latter concern does not apply here as far as I=E2=80=99m aware. >>=20 >> On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev >> > >> wrote: >>=20 >>> In https://github.com/bitcoin/bitcoin/pull/11423 I propose to >>> make OP_CODESEPARATOR and FindAndDelete in non-segwit scripts = non-standard >>>=20 >>> I think FindAndDelete() is one of the most useless and complicated >>> functions in the script language. It is omitted from segwit = (BIP143), >>> but we still need to support it in non-segwit scripts. Actually, >>> FindAndDelete() would only be triggered in some weird edge cases = like >>> using out-of-range SIGHASH_SINGLE. >>>=20 >>> Non-segwit scripts also use a FindAndDelete()-like function to = remove >>> OP_CODESEPARATOR from scriptCode. Note that in BIP143, only executed >>> OP_CODESEPARATOR are removed so it doesn=E2=80=99t have the >>> FindAndDelete()-like function. OP_CODESEPARATOR in segwit scripts = are >>> useful for Tumblebit so it is not disabled in this proposal >>>=20 >>> By disabling both, it guarantees that scriptCode serialized inside >>> SignatureHash() must be constant >>>=20 >>> If we use a softfork to remove FindAndDelete() and OP_CODESEPARATOR >>> from non-segwit scripts, we could completely remove FindAndDelete() >>> from the consensus code later by whitelisting all blocks before the >>> softfork block. The first step is to make them non-standard in the >>> next release. >>>=20 >>>=20 >>> =20 >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org = >>> > >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = >>=20 >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = --Apple-Mail=_F8A26339-DF8B-4C5F-A071-51C2E85D7F16 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = is relevant to note that BIP 117 makes an insecure form of CODESEPARATOR = delegation possible, which could be made secure if some sort of = CHECKSIGFROMSTACK opcode is added at a later point in time. It is not = IMHO a very elegant way to achieve delegation, however, so I hope that = one way or another this could be resolved quickly so it doesn=E2=80=99t = hold up either one of those valuable additions.

I have no objections to making them = nonstandard, or even to make them invalid if someone with a better grasp = of history can attest that CODESEPARATOR was known to be entirely = useless before the introduction of P2SH=E2=80=94not the same as saying = it was useless, but that it was widely known to not accomplish what a = early-days script author might think it was doing=E2=80=94and the UTXO = set contains no scriptPubKeys making use of the opcode, even from the = early days. Although a small handful could be special cased, if they = exist.

On Nov 27, 2017, at 8:33 AM, Matt Corallo = <lf-lists@mattcorallo.com> wrote:

I strongly disagree here - we = don't only soft-fork out transactions that
are "fundamentally insecure", = that would be significantly too
restrictive. We have generally = been willing to soft-fork out things
which clearly fall outside of = best-practices, especially rather
"useless" fields in the protocol = eg soft-forking behavior into OP_NOPs,
soft-forking behavior into = nSequence, etc.

As a part of setting clear = best-practices, making things non-standard is
the obvious step, though there has been active = discussion of
soft-forking out FindAndDelete and = OP_CODESEPARATOR for years now. I
obviously do not claim that we = should be proposing a soft-fork to
blacklist FindAndDelete and = OP_CODESEPARATOR usage any time soon, and
assume that it would take at = least a year or three from when it was made
non-standard to when a soft-fork to finally = remove them was proposed.
This should be more than = sufficient time for folks using such weird (and
largely useless) parts of the protocol to = object, which should be
sufficient to reconsider such a = soft-fork.

Independently, making them = non-standard is a good change on its own, and
if nothing else should better inform discussion = about the possibility of
anyone using these = things.

Matt
On 11/15/17 14:54, Mark Friedenbach via = bitcoin-dev wrote:
As good of an idea as it may or may not be to remove this = feature from
the code base, actually doing so would = be crossing a boundary that we
have not previously been = willing to do except under extraordinary
duress. The = nature of bitcoin is such that we do not know and cannot
know what transactions exist out there pre-signed and making = use of
these features.

It may = be a good idea to make these features non standard to further
discourage their use, but I object to doing so with the = justification of
eventually disabling them for all = transactions. Taking that step has the
potential of = destroying value and is something that we have only done in
the past either because we didn=E2=80=99t understand forks = and best practices
very well, or because the features (now = disabled) were fundamentally
insecure and resulted in = other people=E2=80=99s coins being vulnerable. This
latter = concern does not apply here as far as I=E2=80=99m aware.
On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>> = wrote:

In https://github.com/bitcoin/bitcoin/pull/11423 I = propose to
make OP_CODESEPARATOR and FindAndDelete in = non-segwit scripts non-standard

I think = FindAndDelete() is one of the most useless and complicated
functions in the script language. It is omitted from segwit = (BIP143),
but we still need to support it in non-segwit = scripts. Actually,
FindAndDelete() would only be triggered = in some weird edge cases like
using out-of-range = SIGHASH_SINGLE.

Non-segwit scripts also use = a FindAndDelete()-like function to remove
OP_CODESEPARATOR = from scriptCode. Note that in BIP143, only executed
OP_CODESEPARATOR are removed so it doesn=E2=80=99t have = the
FindAndDelete()-like function. OP_CODESEPARATOR in = segwit scripts are
useful for Tumblebit so it is not = disabled in this proposal

By disabling = both, it guarantees that scriptCode serialized inside
SignatureHash() must be constant

If we use a softfork to remove FindAndDelete() and = OP_CODESEPARATOR
from non-segwit scripts, we could = completely remove FindAndDelete()
from the consensus code = later by whitelisting all blocks before the
softfork = block. The first step is to make them non-standard in the
next release.


 
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
<mailto:bitcoin-dev@lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

= --Apple-Mail=_F8A26339-DF8B-4C5F-A071-51C2E85D7F16--