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 41571A7F for ; Wed, 15 Nov 2017 18:02:58 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A1C8E4E9 for ; Wed, 15 Nov 2017 18:02:57 +0000 (UTC) Received: from [10.8.0.103] (119246244201.ctinets.com [119.246.244.201]) by mx.zohomail.com with SMTPS id 1510768972558816.3077961889941; Wed, 15 Nov 2017 10:02:52 -0800 (PST) From: Johnson Lau Content-Type: multipart/alternative; boundary="Apple-Mail=_EAEAEC1D-74EB-4710-BC74-98E80427051B" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Message-Id: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> Date: Thu, 16 Nov 2017 02:02:48 +0800 To: bitcoin-dev X-Mailer: Apple Mail (2.3445.1.6) X-ZohoMailClient: External X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [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: Wed, 15 Nov 2017 18:02:58 -0000 --Apple-Mail=_EAEAEC1D-74EB-4710-BC74-98E80427051B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. =20= --Apple-Mail=_EAEAEC1D-74EB-4710-BC74-98E80427051B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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.


 
= --Apple-Mail=_EAEAEC1D-74EB-4710-BC74-98E80427051B-- 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 11DC2AB6 for ; Wed, 15 Nov 2017 19:54:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f195.google.com (mail-pf0-f195.google.com [209.85.192.195]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D707B517 for ; Wed, 15 Nov 2017 19:54:19 +0000 (UTC) Received: by mail-pf0-f195.google.com with SMTP id x7so17777448pfa.1 for ; Wed, 15 Nov 2017 11:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=friedenbach-org.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=nd5WhOBWH0RjQGFRF9NUvbodqKwQf3BACh6/uhqQZfI=; b=gwsb4sPTaqwILHw3u5vdN+pCOmqHMYm2yvzaliHIS7pVNr9hX9xdbUFp5Ge4JUta+u NJmyeSqcwdRJRua27JokP6+OhMy63sEHDsFVw7N96dAH1phvEYQMXcp+1soUvv1eYx3H goTkdnNZ6jniQxBDLX9txIFkFl3MiADrlbfRnMGpHPd0le6gprpxmURaLyJj1vRFGjjy AGK5xXXYTIfQu/nZxNBpEXNY50TA2UYZRQwZwSvZXGD9feCDVcg31xZ0q0wl79kzlfor 0PhU8EDiGmguUVEAM/BarZ7lWE/O6peAtDHv90iVfnfFEOgKwZEDuJLEMaxC5oBG+3BK 5+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=nd5WhOBWH0RjQGFRF9NUvbodqKwQf3BACh6/uhqQZfI=; b=b+rCHl8Ej7jwWqe0Bix/vuS/34xw9NmCqgaMFpf837gtUe7SrPdXuLUXwWOT0pki0y u1NNSR99KVHoWhYdH39xa+jp09PPcGaUXaZHZwtNm2+nOPFH76gvG2Bm1mA7cj2gn8tC BCjDLPTi6lWxZmEPh4DyYbe1cBtM7w2dxA/qBLGNQOKZ6PZ5KoevL64a6tD9vJMRH4Br dyTylvuI/z6EEWC5bXdIOpQMbt2OWHMX+fXKEp90xIorKZ2NWVlLuEKEtQmRjpBvzN0n 38NAHpWdBdm1yvNdbIMl7v0wh2tWlx1gL3b//iSR6JqEay0OnuKTrn91wmTiIAXf9uvr dqjw== X-Gm-Message-State: AJaThX7qDHyTFlTpwcTjhm9YAuiC+H25hEhHBVuM1IMzSWAs4KUyp1wS mG0l3mM1b5hWiVvXZcCIOn0nIxtEYhA= X-Google-Smtp-Source: AGs4zMaVSRjCxMFPB5LB+9pukL4VNWUI+evgRdASDNVPy5XCZiJy2FB/CTmPgHZExk706o6d10QkHw== X-Received: by 10.101.92.129 with SMTP id a1mr16373753pgt.6.1510775659327; Wed, 15 Nov 2017 11:54:19 -0800 (PST) Received: from [10.0.6.127] (rrcs-173-197-88-101.west.biz.rr.com. [173.197.88.101]) by smtp.gmail.com with ESMTPSA id r13sm15724213pfl.157.2017.11.15.11.54.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 11:54:18 -0800 (PST) From: Mark Friedenbach Content-Type: multipart/alternative; boundary=Apple-Mail-7F30FF3C-0BEF-4739-81C7-19D1B5308035 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 15 Nov 2017 09:54:17 -1000 Message-Id: <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> References: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> In-Reply-To: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> To: Johnson Lau , Bitcoin Protocol Discussion X-Mailer: iPad Mail (15B150) X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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: Wed, 15 Nov 2017 19:54:22 -0000 --Apple-Mail-7F30FF3C-0BEF-4739-81C7-19D1B5308035 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable As good of an idea as it may or may not be to remove this feature from the c= ode base, actually doing so would be crossing a boundary that we have not pr= eviously 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 discour= age 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 d= estroying value and is something that we have only done in the past either b= ecause we didn=E2=80=99t understand forks and best practices very well, or b= ecause the features (now disabled) were fundamentally insecure and resulted i= n other people=E2=80=99s coins being vulnerable. This latter concern does no= t apply here as far as I=E2=80=99m aware. > 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_CODE= SEPARATOR and FindAndDelete in non-segwit scripts non-standard >=20 > I think FindAndDelete() is one of the most useless and complicated functio= ns in the script language. It is omitted from segwit (BIP143), but we still n= eed to support it in non-segwit scripts. Actually, FindAndDelete() would onl= y be triggered in some weird edge cases like using out-of-range SIGHASH_SING= LE. >=20 > Non-segwit scripts also use a FindAndDelete()-like function to remove OP_C= ODESEPARATOR from scriptCode. Note that in BIP143, only executed OP_CODESEPA= RATOR are removed so it doesn=E2=80=99t have the FindAndDelete()-like functi= on. 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 Signatu= reHash() must be constant >=20 > If we use a softfork to remove FindAndDelete() and OP_CODESEPARATOR from n= on-segwit scripts, we could completely remove FindAndDelete() from the conse= nsus code later by whitelisting all blocks before the softfork block. The fi= rst 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 --Apple-Mail-7F30FF3C-0BEF-4739-81C7-19D1B5308035 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable As good of an idea as it may or may not be t= o remove this feature from the code base, actually doing so would be cr= ossing a boundary that we have not previously been willing to do except unde= r extraordinary duress. The nature of bitcoin is such that we do not know an= d cannot know what transactions exist out there pre-signed and making use of= these features.

It may be a good idea to make these feat= ures non standard to further discourage their use, but I object to doing so w= ith the justification of eventually disabling them for all transactions. Tak= ing 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 fork= s and best practices very well, or because the features (now disabled) were f= undamentally insecure and resulted in other people=E2=80=99s coins being vul= nerable. 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 <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.li= nuxfoundation.org> wrote:

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

I think FindAndDelete() is on= e of the most useless and complicated functions in the script language. It i= s omitted from segwit (BIP143), but we still need to support it in non-segwi= t scripts. Actually, FindAndDelete() would only be triggered in some weird e= dge 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 BIP= 143, only executed OP_CODESEPARATOR are removed so it doesn=E2=80=99t have t= he FindAndDelete()-like function. OP_CODESEPARATOR in segwit scripts are use= ful 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 compl= etely remove FindAndDelete() from the consensus code later by whitelisting a= ll blocks before the softfork block. The first step is to make them non-stan= dard in the next release.


 
=
_______________________________________= ________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfounda= tion.org
https://lists.linuxfoundation.org/mailman/listin= fo/bitcoin-dev
= --Apple-Mail-7F30FF3C-0BEF-4739-81C7-19D1B5308035-- 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 D106A727 for ; Thu, 16 Nov 2017 09:27:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B570C1AE for ; Thu, 16 Nov 2017 09:27:22 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 922E32112E; Thu, 16 Nov 2017 04:27:21 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 16 Nov 2017 04:27:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= cc:content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=XNo6Drz6g8MQGqg0RL4Rp0X3chPuVvr1A35bdPKswoY=; b=KidHgJgA 8JQlEFlithPEbH/t3bT4D5xuoHJ8Z6pQOdq1n3W/utVCtIaYFXj38sBVwHI1qt/2 i6jUtUNo/gSbeG0EcpbBeaHkwJzAq8lWPpoKjVQcVXIcEShjPYL0rDqV226bQQg9 UDz5S0SAZ7eMRyzaX8pZR3LTnvjquEYq76tVOwP4T7Ov4yq6gNxKD+73CzL7dB5R 8nneZPg50Et1oYR/Ujqda/S30rT35WkgC5i/AEelFQzIVFFltTlXLQnnxY4HSsY5 s8wKnG94wQH1JIe8UzDFHtVMc2imJ5GbLr3UPOD2qPqFddcUEOdSMMRvuZtS1gB5 E86boW3fZR0KWg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=XNo6Drz6g8MQGqg0RL4Rp0X3chPuV vr1A35bdPKswoY=; b=nkL9AK31vH4JYenMK4pKuOQ0FobtEYoELNQ4A/Es5LvpH 2Tfv/N/Cikdt/JoL2dsuit98B/YfzQ6NiSWtiwCDYCFtBggoXcEBZVBytgIxFghA ZWmfVYQIyYjCjrREuJbpjzZeQPYVghE1sK5uZ+jmkEaZnRXTpu+Ut9855tU//PWH mx5y+0Dg2yZIENCllF+JEvySeJdMjycQEp5K7rrSBrJd0tkJAh3wgNsC0TByiZUt dn6G2DSyOvvVwboLL2fE6cfS1Mtfa3YbhTepdIct6+Q7w34c6sRmMk8LfvDN7V8n YmQWhRs0CU0OYyifckZ8yHD7sBnlHd/kGJIlJbUqQ== X-ME-Sender: Received: from [192.168.178.108] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 9B611244A1; Thu, 16 Nov 2017 04:27:20 -0500 (EST) From: Sjors Provoost Message-Id: <3A5BFD5E-A92D-4BDA-985A-09D86BBA848F@sprovoost.nl> Content-Type: multipart/signed; boundary="Apple-Mail=_ABD197CE-CEF0-4752-A2D5-595EEDB6C1A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Thu, 16 Nov 2017 10:27:18 +0100 In-Reply-To: <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> To: Bitcoin Protocol Discussion References: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> X-Mailer: Apple Mail (2.3445.4.7) X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 16 Nov 2017 13:25:46 +0000 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: Thu, 16 Nov 2017 09:27:23 -0000 --Apple-Mail=_ABD197CE-CEF0-4752-A2D5-595EEDB6C1A6 Content-Type: multipart/alternative; boundary="Apple-Mail=_4F75F9EB-A5D9-4CCF-A307-BFEBD09F85C3" --Apple-Mail=_4F75F9EB-A5D9-4CCF-A307-BFEBD09F85C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can you clarify what you mean by "whitelisting all blocks before the = softfork block"? The most conservative approach could be to leave the code in place until = the very last non-segwit P2SH UTXO from before the soft fork block has = been spent. But this would never happen if even a single private key is = lost. After making these transactions non-standard and removing the code, = transactions containing these OP-codes could be considered valid = (perhaps still checking the signature, etc). Some miners would still run = the code and mine those transactions, but others wouldn't verify them. = This is strictly less bad than losing those funds forever, but doesn't = seem acceptable either. Is there a variant of the above scenario where a miner puts up some very = large deposit (e.g. 10x the size of the UTXO) if they mine such a legacy = transaction, and can lose that if someone else runs the code and finds = the transaction invalid? Sjors > Op 15 nov. 2017, om 20:54 heeft Mark Friedenbach via bitcoin-dev = het volgende geschreven: >=20 > 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 = > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_4F75F9EB-A5D9-4CCF-A307-BFEBD09F85C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Can = you clarify what you mean by "whitelisting all blocks before the = softfork block"?

The most conservative approach could be to = leave the code in place until the very last non-segwit P2SH UTXO from = before the soft fork block has been spent. But this would never happen = if even a single private key is lost.

After making these transactions = non-standard and removing the code, transactions containing these = OP-codes could be considered valid (perhaps still checking the = signature, etc). Some miners would still run the code and mine those = transactions, but others wouldn't verify them. This is strictly less bad = than losing those funds forever, but doesn't seem acceptable = either.

Is = there a variant of the above scenario where a miner puts up some very = large deposit (e.g. 10x the size of the UTXO) if they mine such a legacy = transaction, and can lose that if someone else runs the code and finds = the transaction invalid?

Sjors 

Op = 15 nov. 2017, om 20:54 heeft Mark Friedenbach via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende = geschreven:

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> 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
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<= br class=3D"">

= --Apple-Mail=_4F75F9EB-A5D9-4CCF-A307-BFEBD09F85C3-- --Apple-Mail=_ABD197CE-CEF0-4752-A2D5-595EEDB6C1A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE7ZvfetalXiMuhFJCV/+b28wwEAkFAloNWfYACgkQV/+b28ww EAklTQ//dnhQf5eGk3/XOVU50TK+QTJg843mKEXzfQOc10ruYeU2b3iNhns8ptyr o9o0wfMeScKU3S8O7uG7KEpycWAr2J3O6R7ZJgOyPtuNmWS6GqJwrSVSbW2V2eHO bGizQlo90SYmUD6aAzhxlsfl6EpiIRz9gYDF9zU0AkFQa6yN5KYsmGAiCoe2143e BMDOtZMR1zz2VTEVqd4ud53xdY2tQqrTEhcgsFFjLUd9+hk+OvOQ/xHfkmLClF74 N/A/lCh88bSuIW44+gLvBQyRBHE9H3CP1QodZMFiMrpSwHomTaUU8cWv5uNuKaWr +D66lgIXkXEyinv7z6jk+rhLf4QzLoJg7eTBHOalcC/wUrHQAjXwyZvX8OY4QYUI yAuA58EIWRwhOQViR+8pOcqz2jU4Wpx0D97vWRO6vhS4xE5W1HBuzF8WKyA2SWcb snG9nwCoxru8saAFrPZemmE9FzfW/zAtSz4oIzh2/eImFOfahwl1Y6H8MIHoPwJx sSqewDvp7hhM1GBkMQ1dMyxgYK2zYi4O5p0tbgOzfiZEFx3ni3q0gnxWHqXM+DGk dbVm+2F/rEJKFCyRh0bssihkQvLdO2L7xludXc3kLq/JDSntTZ6ag2Y3twc/GIBN /+2IdU26QXEDZ8cJZbL21XlAbrTC6k7ngIOXNfxuZQ5qpMYspNI= =qo2Y -----END PGP SIGNATURE----- --Apple-Mail=_ABD197CE-CEF0-4752-A2D5-595EEDB6C1A6-- 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 AD766C89 for ; Mon, 27 Nov 2017 16:33:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F0C62576 for ; Mon, 27 Nov 2017 16:33:09 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 18EA0180DB4; Mon, 27 Nov 2017 16:33:08 +0000 (UTC) To: Mark Friedenbach , Bitcoin Protocol Discussion , Johnson Lau References: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> From: Matt Corallo Message-ID: <56ca1248-6427-46f7-1645-84349cc8facc@mattcorallo.com> Date: Mon, 27 Nov 2017 11:33:07 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 16:33:10 -0000 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’t understand forks and best practices > very well, or because the features (now disabled) were fundamentally > insecure and resulted in other people’s coins being vulnerable. This > latter concern does not apply here as far as I’m aware. > > On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev > > 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’t 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 >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > 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-- 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 A30A1C79 for ; Mon, 27 Nov 2017 21:33:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC458F1 for ; Mon, 27 Nov 2017 21:33:39 +0000 (UTC) Received: from [172.17.0.2] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 74D38182055; Mon, 27 Nov 2017 21:33:38 +0000 (UTC) To: Mark Friedenbach References: <53A587C3-DAC1-4055-875F-96B61717ACE6@xbt.hk> <081A517B-B730-43AB-9D4E-4F696EFD91A3@friedenbach.org> <56ca1248-6427-46f7-1645-84349cc8facc@mattcorallo.com> <44B74F02-D3D6-47B9-976E-A72042E5C84B@friedenbach.org> From: Matt Corallo Message-ID: <2c78e653-862d-afd3-0ae7-ebbbc9eec770@mattcorallo.com> Date: Mon, 27 Nov 2017 16:33:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <44B74F02-D3D6-47B9-976E-A72042E5C84B@friedenbach.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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:33:40 -0000 Indeed, the PR in question does *not* change the semantics of OP_CODESEPARATOR within SegWit redeemScripts, where it is still allowed (and Nicolas Dorier pointed out that he was using it in TumbleBit), so there are still ways to use it, but only in places, like SegWit, where the potential validation complexity blowup is massively reduced. I am not sure that OP_CODESEPARATOR is entirely useless in pre-SegWit scripts (I believe Nicolas' construction may still be relevant pre-SegWit), though I strongly believe FindAndDelete is. I don't think CODESEPARATOR rises to the threshold of it being "widely known to be useless", but certainly the historical use of it (to separate the scriptSig and the scriptPubKey in the scriptCode, which was run as a single concatenated thing in the original design is no longer relevant). FindAndDelete is equally irrelevant if not significantly more irrelevant. Matt On 11/27/17 16:06, Mark Friedenbach wrote: > 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’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—not 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—and 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: >> >> 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’t understand forks and best practices >>> very well, or because the features (now disabled) were fundamentally >>> insecure and resulted in other people’s coins being vulnerable. This >>> latter concern does not apply here as far as I’m aware. >>> >>> On Nov 15, 2017, at 8:02 AM, Johnson Lau via bitcoin-dev >>> >> >>> > 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’t 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 >>>> >>>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >