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