Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 12, 2018 2:36 PM, Rusty Russell <ru...@rustcorp.com.au>
> ZmnSCPxj zmnsc...@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.
Lightning-dev mailing list