Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

[Rusty Russell]

Matt Corallo  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  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

Re: [Lightning-dev] Base AMP

[ZmnSCPxj via Lightning-dev]

Good morning Rusty,

Okay, I shall modify pull request as you suggested.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Thursday, November 22, 2018 6:50 AM, Rusty Russell  
wrote:

> ZmnSCPxj zmnsc...@protonmail.com writes:
>
> > Good morning Rusty,
> >
> > > And do not play with `amount_to_forward`, as it's an important
> > > signal to the final node that the previous node did not offer less value
> > > for the HTLC than it was supposed to. (You could steal the top bit to
> > > signal partial payment if you really want to).
> >
> > If `incomplete_payment` flag is set, then final nodes must claim HTLCs only 
> > if:
> >
> > sum(incoming_htlc_amt) >= amt_to_pay
> >
>
> No, because now you've lost assurance that thisparticular HTLC hasn't
> been skimmed by the previous node.
>
> ie. if I suspect a payment is using Base-AMP (and that's pretty clear if
> I see two identical payment_hashes), I can reduce the amount I offer in
> the outgoing HTLC to 1 satoshi: if it doesn't fail immediately, the next
> hop is the final destination.
>
> > Where `sum(incoming_htlc_amt)` is the total `incoming_htlc_amt` for all 
> > incoming HTLCs terminating at this final node with the same `payment_hash`.
>
> But it's unnecessary for the recipient to know the total amount I meant
> to pay; they just need to return the receipt once it exceeds the amount
> they want.
>
> Cheers,
> Rusty.


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