📅 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
ZmnSCPxj [ARCHIVE] /
npub1g5…3ms3l
2023-06-09 12:51:50
in reply to nevent1q…dj02
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 12:51:50Event JSON
{
"id": "ed8030dbb907eda698458f20d0b87f615b163ef18bab2d82f13e67d8bf8dd49f",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686315110,
"kind": 1,
"tags": [
[
"e",
"c396150541b93fd7dcbb99733d0101c5012b71f16be611915f67f9ed8b9c1baa",
"",
"root"
],
[
"e",
"0c24c6857c59228ff2c095f4d88dbb7801a9813e99913775f4bd47489cf7534c",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-10-12\n📝 Original message:\nSent with ProtonMail Secure Email.\n\n‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\nOn Friday, October 12, 2018 2:36 PM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e ZmnSCPxj ZmnSCPxj at protonmail.com writes:\n\u003e\n\u003e \u003e Good morning Rusty and list,\n\u003e \u003e\n\u003e \u003e \u003e 1. Rather than trying to agree on what fees will be in the future, we\n\u003e \u003e \u003e should use an OP_TRUE-style output to allow CPFP (Roasbeef)\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e 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.\n\u003e\n\u003e If you look further down, it's actually a P2WSH to \"OP_TRUE\". Wastes\n\u003e some space, but it works today.\n\nAh, I see. This will change again if the luke-jr proposal pushes through?\n\nWill robots arise which will attempt to claim as many OP_TRUE outputs as they can find, claiming them afterwards during very-low-fee periods?\n\n\u003e\n\u003e \u003e \u003e 3. The CLTV timeout should be symmetrical to avoid trying to game the\n\u003e \u003e \u003e peer into closing. (Connor IIRC?).\n\u003e \u003e \u003e\n\u003e \u003e\n\u003e \u003e 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.\n\u003e\n\u003e The original design does the minimum necessary (youmust have a\n\u003e to-yourself delay to give time for the penalty tx to work). But, when\n\u003e combined with fee asymmetry (funder pays), it can lead the fundee to not\n\u003e care whether it forces the funder to perform a unilateral, or does a\n\u003e graceful mutual close.\n\u003e\n\u003e It's not a major issue, but aligning incentives (to mutual close) makes\n\u003e sense if we're changing other things I think.\n\u003e\n\nI 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.\n\nRegards,\nZmnSCPxj",
"sig": "9275db1c2b56d7fa45435b2eb2f152c416f0ef7fd8b3d71ee3098e8ab538b7a9e49690efe9cdee91d71dde6bf0c15de344ffa88de1b70373a7d8406887701089"
}