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-li...@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.

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to