[Lightning-dev] Commitment Transaction Format Update Proposals?

[ZmnSCPxj]

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:36 PM, Rusty Russell <rusty at rustcorp.com.au> wrote:

> ZmnSCPxj ZmnSCPxj at protonmail.com 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.

Regards,
ZmnSCPxj