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 03341C000B; Sat, 19 Jun 2021 13:38:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CF62B4025C; Sat, 19 Jun 2021 13:38:34 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.234 X-Spam-Level: * X-Spam-Status: No, score=1.234 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, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org 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 2cTYvQwsnQjy; Sat, 19 Jun 2021 13:38:33 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from newmail.dtrt.org (newmail.dtrt.org [IPv6:2600:3c03::f03c:91ff:fe7b:78d1]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3CF4140217; Sat, 19 Jun 2021 13:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org; s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bPIF4IUllPsKJbp6HSlkUi0gaAQmV2COFZOA33FakrA=; b=o3UiDVDRI3xi+0v0w+BV3tpnSh Hz3Sbf2mefJBuAqF6CWhgWRN5cm4+oYzYYDlvgzwl1YRpKz0wAV7R0ZRcOlL3Kfo5vHT8+i2u9zmP 79FYnvATIqh5Pg/U2Qx/gwoMukZbgKsIZnP61/Jmva8tQCxqDCbN8GI9CsoNlaahgyjc=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1lubB9-0007iF-IZ; Sat, 19 Jun 2021 03:38:31 -1000 Date: Sat, 19 Jun 2021 03:36:53 -1000 From: "David A. Harding" To: Antoine Riard Message-ID: <20210619133653.m2272jgna5geuuki@ganymede> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="rzkc565rjzyfsifh" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Bitcoin Protocol Discussion , "lightning-dev\\\\@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] [Lightning-dev] Waiting SIGHASH_ANYPREVOUT and Packing Packages 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: Sat, 19 Jun 2021 13:38:35 -0000 --rzkc565rjzyfsifh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote: > 2) Solving the Pre-Signed Feerate problem : Package-Relay or > SIGHASH_ANYPREVOUT >=20 > For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able = to > solve the pre-signed feerate issue [3] > > [...] > > [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT > solves pinnings beyond those LN meetings logs: > https://gnusha.org/lightning-dev/2020-06-08.log For anyone else looking, the most relevant line seems to be: 13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here - assuming a lot of complicated logic in core to do so, you could imagine blind-cpfp-bumping *any* commitment tx without knowing its there or which one it is all with one tx.......in theory) That might work for current LN-penalty, but I'm not sure it works for eltoo. If Bitcoin Core can rewrite the blind CPFP fee bump transaction to refer to any prevout, that implies anyone else can do the same. Miners who were aware of two or more states from an eltoo channel would be incentivized to rewrite to the oldest state, giving them fee revenue now and ensuring fee revenue in the future when a later state update is broadcast. If the attacker using pinning is able to reuse their attack at no cost, they can re-pin the channel again and force the honest user to pay another anyprevout bounty to miners. Repeat this a bunch of times and the honest user has now spent more on fees than their balance from the closed channel. Even if my analysis above is wrong, I would encourage you or Matt or someone to write up this anyprevout idea in more detail and distribute it before you promote it much more. > package-relay sounds a reasonable, temporary "patch". Even if every protocol based on presigned transactions can magically allow dynamically adding inputs and modifying outputs for fees, and we also have a magic perfect transaction replacement protocol, package relay is still fundamentally useful for CPFP fee bumping very low feerate transactions received from an external party. E.g. Alice pays Bob, mempool min feerates increase and Alice's transaction is dropped, Bob still wants the money, so he submits a package with Alice's transaction plus his own high feerate spend of it. Package relay is a clear improvement now, and one I expect to be permanent for as long as we're using anything like the current protocol. =20 > # Deployment timeline >=20 > So what I believe as a rough deployment timeline. I don't think it's appropriate to be creating timelines like this that depend on the work of a large number of contributors who I don't believe you've consulted. For details on this point of view, please see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.ht= ml Stuff will get done when it gets done. -Dave --rzkc565rjzyfsifh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmDN8vUACgkQ2dtBqWwi adMBXg//dk/8r3qubbw1Un64QAH7uk6SrY+F0HAuz5P1ddYOqhrI5DXVYtoVBCz7 mB60+hBRKFh/pFy1znVYehBD31wGj80KnIsGvkqlj1gcKg2SK1iGqTjejogvbF6h 9Au83yQWoaTtiK5AHYxuTk1Tjy0jV0tWkZjNQUjv/nI41Q27MR3v67B43VxUDImT s7LENIkWmVK+xnewa3No461jG6apVkTp3iRGVXtsnwGCbHwEmZ0+3KZ5cMamCaOY xeeVH1VT85I3ZFRyEo/stUd7t7jp5cLzsmFNmaAPrmzxEg2+wMzYDUf+Df08+nnS MHryfHw9nJhgEq9U4Opcq4IpRoulplUTblM4ZOtf3hqEASDZQFg0DKzOp1Poeh22 jnGXZYYiQRcTgjEM80DH1GPv5R7T2//60YVYyB5SNx1YvjMuiTq4cC5Cg/4R/J9C Ghtxy4Wp3KnBgXtuAhI2vjVxJJg+pF0MjM+xce5A4qgVv+lNKmo+h9UgCC1bSbRh g231lJFkbh0SvbmVd9ynZCZYqDweLrm0A02jVh00y+mkrDHEbMctgDzY9h6e7C6S arwHBtog7Y5n7VoHBrHmmWTX3TPAut1BNFasAmJW6DVn6WbPDvLocIEbzq26hVB/ 6/Wt0p/Ul2dpL5dCbSb62ew4NGsERl2Di/Ezcbiz38jyeymkNiU= =LTcF -----END PGP SIGNATURE----- --rzkc565rjzyfsifh--