Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:36 PM, Rusty Russell <> 

> ZmnSCPxj writes:
> > Good morning Rusty and list,
> >
> > > 1.  Rather than trying to agree on what fees will be in the future, we
> > >     should use an OP_TRUE-style output to allow CPFP (Roasbeef)
> > >
> >
> > My understanding is that this would require some base-layer changes at 
> > Bitcoin level first? At minimum IsStandard() modification, and I believe 
> > luke-jr suggested, to make a consensus rule that OP_TRUE would not be 
> > spendable beyond the block it appears in (i.e. it is used only for CPFP 
> > hooking) to reduce UTXO database size at lower layer.
> If you look further down, it's actually a P2WSH to "OP_TRUE". Wastes
> some space, but it works today.

Ah, I see.  This will change again if the luke-jr proposal pushes through?

Will robots arise which will attempt to claim as many OP_TRUE outputs as they 
can find, claiming them afterwards during very-low-fee periods?

> > > 3.  The CLTV timeout should be symmetrical to avoid trying to game the
> > >     peer into closing. (Connor IIRC?).
> > >
> >
> > I know this has been discussed before, but I wonder the rationale for the 
> > original asymmetric design, and the rationale for the new symmetric design.
> The original design does the minimum necessary (youmust have a
> to-yourself delay to give time for the penalty tx to work). But, when
> combined with fee asymmetry (funder pays), it can lead the fundee to not
> care whether it forces the funder to perform a unilateral, or does a
> graceful mutual close.
> It's not a major issue, but aligning incentives (to mutual close) makes
> sense if we're changing other things I think.

I understand.  I suppose this is minor improvement.  It is also enabled 
somewhat by item 1 above (OP_TRUE CPFP hook).  Currently, advantage of 
asymmetric is that the other side can CPFP the transaction.  Now, with both 
having a CSV delay, neither side can CPFP, but with the CPFP hook anyone 
(including robots which might want to opportunistically steal OP_TRUE outputs 
during low-fee eras) can CPFP the transaction.

Lightning-dev mailing list

Reply via email to