ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-12 📝 Original message: Sent with ProtonMail ...
📅 Original date posted:2018-10-12
📝 Original message:
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
📝 Original message:
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