From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id CA0F9C0037 for ; Tue, 30 Jan 2024 04:12:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8C12D417F8 for ; Tue, 30 Jan 2024 04:12:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C12D417F8 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=bvhBiDN8 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQQnuEDpaQbQ for ; Tue, 30 Jan 2024 04:12:32 +0000 (UTC) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) by smtp4.osuosl.org (Postfix) with ESMTPS id AB34A41795 for ; Tue, 30 Jan 2024 04:12:32 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org AB34A41795 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1706587944; x=1706847144; bh=CvE06e12BjIkt/XKkr5ICljPz1z2Sp+yHmGa/WofCsA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=bvhBiDN8YgI37T1eKhoGjTiXaXLtbFB90B4x4aj360XspLgww3+of7RDMZx+wKXAV 6J/OEos6zH4Hfnm9xsdNAI+ehrEOYtABG+6XsgsqmjWhzIlL1TVZDkMhxXUNFhsHfc tp2sVURvwfoO96LYngpYG3TrqTBaZuJdIa6npGSmfUhpZb/+2ESV8AzPS65zgwpBYo 4hjkKZVu6gTUS4istJ78IGDkEj1ippBKOJsQ0uwcmNLfXi8ayJbuFYuzcNLBIdK4K7 +zeAks4HZL1DXlFET71kiaO4O4Z2moeJLyglqKVo6c2gThCiq+3PedFlvBpr3QbLM2 YNluxvDL4PFCQ== Date: Tue, 30 Jan 2024 04:12:07 +0000 To: Michael Folkson From: ZmnSCPxj Message-ID: <9tVZA3A4x-GZB5wQ1kMUoyyYXqvGS4MP4iDrLx1FCFHly-MU--II8evpgdcf2Xb9JZWDsY0kEB8r9dClzPrOk_V8EiWtHms8fvlunZQNGrA=@protonmail.com> In-Reply-To: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com> References: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: bitcoin-dev@lists.linuxfoundation.org, Lightning Dev Subject: Re: [bitcoin-dev] [Lightning-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2024 04:12:34 -0000 Good morning Michael et al, >=20 > I assume that a CTV based LN-Symmetry also has this drawback when compare= d to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry = could change the fees in every channel update based on what the current mar= ket fee rate was at the time of the update. In today's pre LN-Symmetry worl= d you are always going to have justice transactions for revoked states that= were constructed when the market fee rate was very different from the pres= ent day's market fee rate. This is the same in the future Decker-Russell-Osuntokun ("eltoo" / "LN-Symm= etry") world as in the current Poon-Dryja ("LN-punishment"). Every *commitment* transaction in Poon-Dryja commits to a specific fee rate= , which is why it it problematic today. The *justice* transaction is single-signed and can (and SHOULD!) be RBF-ed = (e.g. CLN implements an aggressive *justice* transaction RBF-ing written by= me). However, the issue is that every *commitment* transaction commits to a spec= ific feerate today, and if the counterparty is offline for some time, the m= arket feerate may diverge tremendously from the last signed feerate. The same issue will still exist in Decker-Russell-Osuntokun --- the latest = pair of update and state transactions will commit to a specific feerate. If the counterparty is offline for some time, the market feerate may diverg= e tremendously from the last signed feerate. Anchor commitments Fixes This by adding an otherwise-unnecessary change out= put (called "anchor output") for both parties to be able to attach a CPFP t= ransaction. However, this comes at the expense of increased blockspace usage for the an= chor outputs. Peter Todd proposes to sign multiple versions of offchain transactions at v= arying feerates. However, this proposal has the issue that if you are not the counterparty p= aying for onchain fees (e.g. the original acceptor of the channel, as per "= initiator pays" principle), then you have no disincentive to just use the h= ighest-feerate version always, and have a tiny incentive to only store the = signature for the highest-feerate version to reduce your own storage costs = slightly. In addition, it is also incentive-incompatible for the party that pays onch= ain fees to withhold signatures for the higher-fee versions, because if you= are the party who does not pay fees and all you hold are the complete sign= atures for the lowest-fee version (because the counterparty does not want t= o trust you with signatures for higher-fee versions because you will just a= buse it), then you will need anchor outputs again to bump up the fee. The proposal from Peter Todd might work if both parties share the burden fo= r paying the fees. However, this may require that both parties always bring in funds on all ch= annel opens, i.e. no single-sided funding. I have also not considered how this game would play out, though naively, it= seems to me that if both parties pay onchain fees "fairly" for some defini= tion of "fair" (how to define "fair" may be problematic --- do they pay equ= al fees or proportional to their total funds held in the channel?) then it = seems to me okay to have multi-feerate-version offchain txes (regardless of= using Poon-Dryja or Decker-Russell-Osuntokun). However, there may be issues with hosting HTLCs; technically HTLCs are nest= ed inside a larger contract (the channel) and if so, do you need a separate= transaction to resolve them (Poon-Dryja does!) and do you also have to mul= ti-feerate *in addition to* multi-feerate the outer transaction (e.g. commi= tment transaction in Poon-Dryja) resulting in a O(N * N) transactions for N= feerates? Regards, ZmnSCPxj