path: root/cf/c4618d9bd79a7d8e9f55b971bd2681a6d98a89

Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D106A727
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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: <xms:-VkNWj2t7qho036utMl5h9NLI1rJoTRq_CMioP23b_kBgtcShloffg>
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 <sjors@sprovoost.nl>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 =
<bitcoin-dev@lists.linuxfoundation.org> 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 =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>=20
>> In https://github.com/bitcoin/bitcoin/pull/11423 =
<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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Can =
you clarify what you mean by "whitelisting all blocks before the =
softfork block"?<div class=3D""><br class=3D""></div><div class=3D""><div =
class=3D""><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D""><br class=3D""></div><div class=3D"">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?</div><div class=3D""><br class=3D""></div><div =
class=3D"">Sjors&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">Op =
15 nov. 2017, om 20:54 heeft Mark Friedenbach via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; het volgende =
geschreven:</div><br class=3D"Apple-interchange-newline"><div =
class=3D""><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8" class=3D""><div dir=3D"auto" class=3D"">As good of an =
idea as it may or may not be to remove this feature from the code base, =
actually doing so&nbsp;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.<div class=3D""><br class=3D""></div><div class=3D"">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.<br =
class=3D""><div class=3D""><br class=3D"">On Nov 15, 2017, at 8:02 AM, =
Johnson Lau via bitcoin-dev &lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br =
class=3D""><br class=3D""></div><blockquote type=3D"cite" class=3D""><div =
class=3D""><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8" class=3D"">In&nbsp;<a =
href=3D"https://github.com/bitcoin/bitcoin/pull/11423" =
class=3D"">https://github.com/bitcoin/bitcoin/pull/11423</a>&nbsp;I =
propose to make&nbsp;OP_CODESEPARATOR and FindAndDelete in non-segwit =
scripts non-standard<div class=3D""><br class=3D""></div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D"">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</div><div class=3D""><br class=3D""></div><div =
class=3D"">By disabling both, it guarantees that scriptCode serialized =
inside SignatureHash() must be constant</div><div class=3D""><br =
class=3D""></div><div class=3D"">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.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">&nbsp;</div></div></blockquote><blockquote type=3D"cite" =
class=3D""><div class=3D""><span =
class=3D"">_______________________________________________</span><br =
class=3D""><span class=3D"">bitcoin-dev mailing list</span><br =
class=3D""><span class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a></span><br =
class=3D""><span class=3D""><a =
href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a></span><br =
class=3D""></div></blockquote></div></div>________________________________=
_______________<br class=3D"">bitcoin-dev mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br =
class=3D""></div></div></div></body></html>=

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