Date: Wed, 09 May 2018 23:07:49 -0400
To: Luke Dashjr <luke@dashjr.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <YOfgzjDA6blassXxfjPMCeNNE77y-Cuyp8rtc2eOdjj6NVPSOrZfa4a6clTE96-Val-IBHKlQteiVrI9vObgFh9SphENQwLRbf2-AKqUXeM=@protonmail.com>
In-Reply-To: <201805100227.42217.luke@dashjr.org>
References: <87po25lmzs.fsf@rustcorp.com.au>
	<201805100227.42217.luke@dashjr.org>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
Precedence: list

Good morning Luke and list,


> An OP_TRUE-only script with a low value seems like a good example of wher=
e the
>=20
> weight doesn't reflect the true cost: it uses a UTXO forever, while only
>=20
> costing a weight of 4.
>=20
> I like Johnson's idea to have some template (perhaps OP_2-only, to preser=
ve
>=20
> expected behaviour of OP_TRUE-only) that when combined with a 0-value is
>=20
> always valid only if spent in the same block.

I understand the issue.  On Lightning side, if this rule is used, we would =
have the two options below:

1.  Commitment transactions always use the minimum feerate, but always have=
 the above OP_TRUE output.  Then to confirm the commitment transaction we w=
ould have to always spend the OP_TRUE output in CPFP transaction that pays =
for actual fee at unilateral close.  This consumes more blockchain space fo=
r unilateral closes, as the second transaction is always mandatory.
2.  We store two commitment transactions and associated paraphernalia (furt=
her transactions to claim the HTLCs).  One version has a negotiated feerate=
 without the OP_TRUE output.  The other version has a slightly increased fe=
erate and an OP_TRUE output as above.  At unilateral close, we see if the n=
egotiated feerate is enough and use that version if possible, but if not we=
 RBF it with other version and in addition also CPFP on top.  As mentioned =
before, we do not have transaction packages, so we need to RBF with higher =
feerate the commitment transaction, then submit the CPFP transaction which =
makes the first transaction valid to include in a block as per the rule.  T=
his requires that the fallback always have both an RBF bump and a CPFP bump=
.

>=20
>(Maybe it should be the first output
>=20
> instead of the last... Is there any legitimate reason one would have mult=
iple
>=20
> such dummy outputs?)

It seems there are indeed none.

Regards,
ZmnSCPxj