From lf-lists at mattcorallo.com  Sun Nov 25 19:09:25 2018
From: lf-lists at mattcorallo.com (Matt Corallo)
Date: Sun, 25 Nov 2018 19:09:25 +0000
Subject: [Lightning-dev] [PATCH] First draft of
 option_simplfied_commitment
In-Reply-To: <8736rtn19l.fsf@rustcorp.com.au>
References: <87bm6jp42a.fsf@rustcorp.com.au>
	<e0c177b5-99ab-4ca9-81e3-3bb53d92d262@bluematt.me>
	<1ea6ecfd-0f17-4aab-44c8-3c3e457cc4d6@bluematt.me>
	<87va4qnj7g.fsf@rustcorp.com.au>
	<8027ECDC-1A1D-4372-856B-388A1A5C58CC@mattcorallo.com>
	<8736rtn19l.fsf@rustcorp.com.au>
Message-ID: <ef2a0524-b2ae-ea2a-34b7-af626b311812@mattcorallo.com>

Hmm, are we willing to consider CLTV sufficient? In case you have two 
HTLCs, one of medium-small value that has a low CLTV and one of high 
value that has a higher CLTV, you could potentially use the soon-CLTV to 
delay the commitment transaction somewhat further if you broadcast it 
right as the sooner HTLC expires. This may be a bit edge-case-y but to 
keep things symmetric and simplify analysis it seems simpler to just CSV 
everything by 1.

As for other RBF hacks, I think you may have a hard time convincing 
people to accept free relay :p.

Will kick off the discussion on bitcoin-dev once we're clear on our design.

Matt

On 11/22/18 5:12 AM, Rusty Russell wrote:
> Matt Corallo <lf-lists at mattcorallo.com> writes:
>> Ah, oops, indeed, that is much cleaner :). Still need a CSV of 1, though :(.
> 
> OK, let's walk through this:
> 
> Locally offered HTLC:
> - Local HTLC-Timeout tx is CLTV delayed, but remote can fulfill without delay.
> Remote offered HTLC:
> - Local HTLC-Success tx can be done without delay, but remote timeout is CLTV.
> 
> IOW:
> - HTLC output scripts get a `1 OP_CSV OP_DROP` in the non-revoked branch:
> 
>      OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
>      OP_IF
>          OP_CHECKSIG
>      OP_ELSE
>   +      1 OP_CHECKSEQUENCEVERIFY OP_DROP
>      ...
> - HTLC-Success tx needs nSequence = 1.
> - Similarly any self-generated fulfullment tx needs nSequence = 1.
> 
> Yech.
> 
> I still want a new RBF rule where if you pay twice the current package
> *feerate* your tx is accepted, overriding RBF rules 3, 4 & 5.  Probably
> need to increase the effective minrelay feerate for any txs adding to
> that package, similarly (using that double-previous-package-feerate).
> 
> That would mean we're back to a single P2WSH(OP_TRUE) with less
> blockchain spam, and life is simple.  But I'll debate this on
> bitcoin-dev :)
> 
> Cheers,
> Rusty.
>