One recurring feedback is that the replacement cycling issue could have been better explained or presented. The author explains the dilemma faced by security researchers in terms of providing detailed explanations without exposing vulnerabilities to potential attackers. At the time of the full disclosure, some lightning implementations were still adding mitigations to their codebase. The author believes that when doing a full disclosure, it is wise to be conservative in the flow of information disclosed as they may have missed some observations or insights that could worsen the severity and practicality of exploitation.

The email also mentions an "unusual" security risk specific to Bitcoin second-layers called triggering winds of panic among lightning node operators. This risk involves manual force-closing of channels and congesting network mempools, which creates an opportunity for opportunistic exploitation. The author provides an example of how this risk can occur based on historical timelocks and mentions that they informed the core security list about this concern on October 5th. They highlight the importance of addressing security risks at the base-layer to make lightning more robust in the long term.

There have been voices questioning the author's sudden announcement to step down from lightning development. The author clarifies that their statement was distorted by non-specialized journalists but emphasizes that they intentionally raised concerns about the poor state of lightning security. They mention several major security risks, such as pinnings, channel jamming, replacement cycling, and time dilation, which could potentially harm lightning if exploited at scale. Additionally, there are minor risks such as dust HTLC exposure, fee or liquidity griefing, and denial-of-service attacks.

The author suggests that lightning security issues should be solved at the base-layer and expresses their reluctance to stay accountable for coordinating security issues in the lightning ecosystem. They believe that replacement cycling issues cannot be correctly solved on the lightning-side and that integrating serious mitigations on the base-layer would take years. They also mention the lack of standardized mechanisms for dynamic upgrades as a missing safety feature.

The author compares the security of critical software systems to medical practice and stresses the importance of accurately diagnosing vulnerabilities to provide adequate treatment. They believe that the severity of the replacement cycling attack is still underestimated by other Bitcoin developers, including lightning experts. They mention the concept of "package malleability" and its potential impact on lightning nodes, particularly in a post-package relay world. The author concludes by urging individuals and businesses to consider the safety of their funds when making technical decisions and expresses their enthusiasm for the bitcoin technical community's discussions on these issues.

In closing, the author mentions their plan to respond to public emails on these subjects in the coming weeks and months. They express their desire to demonstrate a real-world replacement cycling attack on the mainnet but state that it may not be possible until the second semester of 2024. They remain optimistic about seeing a lightning ecosystem that aligns with the p2p cypherpunk version outlined in the original paper.