📅 Original date posted:2021-06-19
📝 Original message:
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
>
> 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.
> # Deployment timeline
>
> 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.html
Stuff will get done when it gets done.
-Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210619/cfff070b/attachment.sig>;
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-09 12:40:12
in reply to nevent1q…fdns
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 12:40:12Event JSON
{
"id": "5d8539d35d58b6d0e45794711706f0d983dec30b202256c244c8dadf23048657",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686314412,
"kind": 1,
"tags": [
[
"e",
"ee8fa505d6c5bf7dee5f1332f98c16556e36c2b090a07f3908434b989382a124",
"",
"root"
],
[
"e",
"83829065b3d38ee65719f75600effd118d948656c1b6b69d4b02c218a490a15e",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2021-06-19\n📝 Original message:\nOn Fri, Jun 18, 2021 at 06:11:38PM -0400, Antoine Riard wrote:\n\u003e 2) Solving the Pre-Signed Feerate problem : Package-Relay or\n\u003e SIGHASH_ANYPREVOUT\n\u003e \n\u003e For Lightning, either package-relay or SIGHASH_ANYPREVOUT should be able to\n\u003e solve the pre-signed feerate issue [3]\n\u003e\n\u003e [...]\n\u003e\n\u003e [3] I don't think there is a clear discussion on how SIGHASH_ANYPREVOUT\n\u003e solves pinnings beyond those LN meetings logs:\n\u003e https://gnusha.org/lightning-dev/2020-06-08.log\n\nFor anyone else looking, the most relevant line seems to be:\n\n 13:50 \u003c BlueMatt\u003e (sidenote: sighash_no_input is *really* elegant here\n - assuming a lot of complicated logic in core to do so, you could\n imagine blind-cpfp-bumping *any* commitment tx without knowing its\n there or which one it is all with one tx.......in theory)\n\nThat might work for current LN-penalty, but I'm not sure it works for\neltoo. If Bitcoin Core can rewrite the blind CPFP fee bump transaction\nto refer to any prevout, that implies anyone else can do the same.\nMiners who were aware of two or more states from an eltoo channel would\nbe incentivized to rewrite to the oldest state, giving them fee revenue\nnow and ensuring fee revenue in the future when a later state update is\nbroadcast.\n\nIf the attacker using pinning is able to reuse their attack at no cost,\nthey can re-pin the channel again and force the honest user to pay\nanother anyprevout bounty to miners. Repeat this a bunch of times and\nthe honest user has now spent more on fees than their balance from the\nclosed channel.\n\nEven if my analysis above is wrong, I would encourage you or Matt or\nsomeone to write up this anyprevout idea in more detail and distribute\nit before you promote it much more.\n\n\u003e package-relay sounds a reasonable, temporary \"patch\".\n\nEven if every protocol based on presigned transactions can magically\nallow dynamically adding inputs and modifying outputs for fees, and we\nalso have a magic perfect transaction replacement protocol, package\nrelay is still fundamentally useful for CPFP fee bumping very low\nfeerate transactions received from an external party. E.g. Alice pays\nBob, mempool min feerates increase and Alice's transaction is dropped,\nBob still wants the money, so he submits a package with Alice's\ntransaction plus his own high feerate spend of it.\n\nPackage relay is a clear improvement now, and one I expect to be\npermanent for as long as we're using anything like the current protocol.\n \n\u003e # Deployment timeline\n\u003e \n\u003e So what I believe as a rough deployment timeline.\n\nI don't think it's appropriate to be creating timelines like this that\ndepend on the work of a large number of contributors who I don't believe\nyou've consulted. For details on this point of view, please see\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html\n\nStuff will get done when it gets done.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210619/cfff070b/attachment.sig\u003e",
"sig": "2f5bd30988df1e35014d62b2eab1e6aa48418cebca267dce7d1c5f1a5a94336d1e41260da0bb6626c16173f18aab3caedb4ab3eafebef0706b3ee5168a385b93"
}