Return-Path: <jim.posen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id AB53987A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 May 2018 20:06:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com
	[209.85.216.173])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4FD8EA3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 May 2018 20:06:28 +0000 (UTC)
Received: by mail-qt0-f173.google.com with SMTP id e8-v6so7478275qth.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 17 May 2018 13:06:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=xxAK7/4AHPHemzeagjiVxViEQK6aTPon6QV2qJG9xno=;
	b=l41Htzc1MbXRZumGpF76e26IXkGLWfE/8kU3zTQ0MrORkQ91p6ejULTIsFx1eWQE9m
	lRSqGkPkpNTMk7maMwbnvmqJbYW7ZAo6zxBj1J6a5c0qcRKJ07uRRjFLCRE8+Vku1ThS
	6VF4RwjLJwhosGxkrb6ETA6TQOg7+/Me39TbuUx90Rgf5yfG4A3WsyR1p7+kKml5Eumd
	rma0YkGGhQUxQs5mvVWfXUHw86pL5qD9tKmykGSleduCaJUgMjblffxPoeKuK6yJuTqf
	AXcPlIKCT1B6z9RpvFQnvIV4+oKyTXF7vB9PuUUgt/hlTepT+plWMNmCIsnRHaq4lBn5
	FdCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=xxAK7/4AHPHemzeagjiVxViEQK6aTPon6QV2qJG9xno=;
	b=RUOLQlFqNIlYAzTUxIfYKOsTskavCs/bjMx+9rJg4tk5PoTTNRYrASjz34al5rgfH6
	YbDtIYjGz2Zn3Ew7IOoPAJkpv7c9Bw7dFXa0iIkEIiyb89bzm3OHPky/hDGacBl8Lsmh
	uoatrLv5vcfVG2cAKQkVTsMd3ykJj0mo7bR+Yrv2Sll9wZ0xtln5tW5bMnPwT32WO72N
	KjnO+DK9px5kLVOZF7rw09TyKB/u/xCjQh530ycKBqV6xcPK5riCmbtUNIx7IzDACMk1
	1mfGkFLrzOnNBNpXGvEqDyK5nlqImIVVwNTkHJrK+LTFHVliW8gHf1Zn6UBk/rZtkKfU
	cPbg==
X-Gm-Message-State: ALKqPwfUsDHEOXdtIT0lfv61ddv2OG9P7M1D8CHN0jh0N/z+FioEqNDi
	CMawBhQzAXh75hB/8Yes9hYOXOQ/PMRHZ2yVE7E=
X-Google-Smtp-Source: AB8JxZo/cmbBSlPHXuVXAc6clLmqm6HP0uoSZsmiAjhYwRz/KY/uP0qVGdUaGf3Kt3iehgNdRRLxDZCdCNdfqXL5bKA=
X-Received: by 2002:aed:3ccb:: with SMTP id
	e11-v6mr6980602qtf.131.1526587587311; 
	Thu, 17 May 2018 13:06:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.50.92 with HTTP; Thu, 17 May 2018 13:06:26 -0700 (PDT)
In-Reply-To: <87vabnq9ui.fsf@rustcorp.com.au>
References: <87po25lmzs.fsf@rustcorp.com.au>
	<201805100227.42217.luke@dashjr.org>
	<87vabnq9ui.fsf@rustcorp.com.au>
From: Jim Posen <jim.posen@gmail.com>
Date: Thu, 17 May 2018 13:06:26 -0700
Message-ID: <CADZtCShwOV+GuJ5__GMi9hd2_X=BztASPBihDXakU3Mjb39wcQ@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000dc3fa9056c6c5e7f"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 17 May 2018 20:11:38 +0000
Subject: Re: [bitcoin-dev] Making OP_TRUE 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, 17 May 2018 20:06:28 -0000

--000000000000dc3fa9056c6c5e7f
Content-Type: text/plain; charset="UTF-8"

>
> This brings us another theoretical problem: someone could spend our
> OP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to
> CPFP the tx.  It'd be hard to do, but possible.  I think the network
> benefits from using OP_TRUE (anyone can clean, and size, vs some
> only-known-to-me pubkey) outweighs the risk, but it'd be nice if OP_TRUE
> P2WSH spends were always considered RBF.
>

I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
on the spending tx?

--000000000000dc3fa9056c6c5e7f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">This brings us another theoretical problem: some=
one could spend our<br>
OP_TRUE with a low-fee non-RBF tx, and we&#39;d not be able to use it to<br=
>
CPFP the tx.=C2=A0 It&#39;d be hard to do, but possible.=C2=A0 I think the =
network<br>
benefits from using OP_TRUE (anyone can clean, and size, vs some<br>
only-known-to-me pubkey) outweighs the risk, but it&#39;d be nice if OP_TRU=
E<br>
P2WSH spends were always considered RBF.<br></blockquote><div><br></div><di=
v>I believe OP_CSV with a relative locktime of 0 could be used to enforce R=
BF on the spending tx?=C2=A0</div></div></div></div>

--000000000000dc3fa9056c6c5e7f--