From: Christian Decker <decker.christian@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <bGnScyqXi6LMbsqtc8l3DDTfibYhKd30y-Urd28iImu-gK2hBKYPLpkkbit18RkYlmakzoJAVqKyqL5bw_By_AdXJJd1r3QrLjH1W6igKPM=@protonmail.com>
References: <87po25lmzs.fsf@rustcorp.com.au>
	<201805100227.42217.luke@dashjr.org>
	<87vabnq9ui.fsf@rustcorp.com.au>
	<bGnScyqXi6LMbsqtc8l3DDTfibYhKd30y-Urd28iImu-gK2hBKYPLpkkbit18RkYlmakzoJAVqKyqL5bw_By_AdXJJd1r3QrLjH1W6igKPM=@protonmail.com>
Date: Thu, 17 May 2018 13:35:53 -0400
Message-ID: <87h8n6i3ra.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
Precedence: list

ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:

> Good morning Rusty and list,
>
>> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is
>> interesting,
>> 
>> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need
>> this
>> 
>> at all (though others still might).
>
> We might still want this in general in Lightning; for instance we
> could make every funding transaction include such an output.  If it
> turns out, our initial feerate estimate for the funding transaction is
> low, we can use the `OP_TRUE` for fee-bumping.  This is a win for
> Lightning since the funding transaction ID remains the same (even in
> Decker-Russell-Osuntokun, the trigger transaction is signed with
> `SIGHASH_ALL`, and refers to a fixed funding transaction ID).
>
> Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a
> new different channel and RBF the old funding transaction with a new
> higher-feerate funding transaction, then keep track of which one gets
> confirmed deeply (there is a race where a miner discovers a block
> using the older funding transaction before our broadcast of the new
> funding transaction reaches it).
>
> (we could also feebump using the change output of the funding
> transaction, but such a change output might not exist for all funding
> transactions.)

This would only really help in the case of the funding tx not having a
change output, which I believe will be very rare. In the case of a
change output we can simply do a CPFP which includes the change output.