<oembed><type>rich</type><version>1.0</version><title>David A. Harding [ARCHIVE] wrote</title><author_name>David A. Harding [ARCHIVE] (npub16d…x4wrd)</author_name><author_url>https://yabu.me/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2020-04-04&#xA;📝 Original message:&#xA;On Fri, Apr 03, 2020 at 02:51:15AM +0000, ZmnSCPxj via Lightning-dev wrote:&#xA;&gt; Ah, right, E knows the revocation for the unilateral close of EE,&#xA;&gt; because it is a self-channel, sigh.  And by this revocation clause it&#xA;&gt; can claim the money immediately and put it into a channel as well.&#xA;&#xA;If it&#39;s a self channel, E can also just RBF replace the close&#xA;transaction with a minimally-sized 1-input, 1-output transaction.&#xA;&#xA;In addition, if typical mempools are full and the closing transaction&#xA;feerate is very low (i.e. because anchor outputs are meant to be used)&#xA;E may also be able to create a close transaction that will be&#xA;dropped from typical mempools in the near future and may never &#xA;confirm, allowing E to continue using the channel in attacks against its&#xA;other peers.&#xA;&#xA;-Dave&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 833 bytes&#xA;Desc: not available&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200404/9350d3a0/attachment.sig&gt;</html></oembed>