我可以在閃電網路中發送/接收付款但阻止轉發付款嗎？
假設我正在使用一個計算能力非常有限的設備（例如感測器），它使用閃電網路發送/接收付款。但是，由於計算受到限制，它不想轉發實際用於其他節點的收款。原因可能是轉發支付將需要它轉發 htlc、完成它以及計算洋蔥以路由到下一個節點，這可能會消耗計算量。但是，發送錯誤只是解析洋蔥後的一項操作。
每次感測器節點解析洋蔥並看到付款不適合它時，它都會發送一條
temporary_node_failure或temporary_channel_failure錯誤消息。在閃電軟體使用一些數據分析工具（如自動駕駛儀）的情況下，其他節點可能會因為該感測器節點的高故障率而完全避開該感測器節點轉發付款。這是否可以通過對目前的閃電實現（如 LND 或 c-lightning）進行輕微調整來實現？如果失敗率太高，是否有其他節點保留的類似banscore 的東西可能會阻止該感測器節點將來接收/發送付款？
是的，基本上有兩種方法可以避免成為轉發節點：
- 不要公佈您的頻道，並將其保密
- 拒絕任何不適合您的傳入 HTLC
第一個由協議本身支持，是一種主動措施，可防止轉發任何不適合您的付款，而後者是一種被動措施，允許您根據每個 HTLC 決定是否要轉發它或者現在。
該協議允許通道保持私有而不在更廣泛的網路中公佈：
目前僅定義了 channel_flags 的最低有效位：announce_channel。這表明資金流的發起者是否希望公開向網路宣傳該渠道，如 BOLT #7 中所述。
這意味著該頻道不會包含在八卦中，並且節點不會了解該頻道的存在。然後為了接收付款，這需要發件人通過該未通知的渠道計算到您的路線，您可以使用路線提示（即
r發票中的欄位）選擇性地告訴發件人發票中的渠道。上面提到的第二種方法涉及檢測節點，使其接受 HTLC，但立即拒絕您不是目的地的任何 HTLC。這有幾個缺點，其中一個事實是，您要宣布從根本上不能用於轉發的通道，並且您仍然必須處理所有 HTLC，因為您無法提前將它們過濾掉。這對應於Rene Pickhardt提到的場景。計算成本包括：
- 更多消息要處理，包括有線加密/解密，如果您在低功率設備上執行，可能會喚醒您的 CPU
- 解密洋蔥，這是一項非常昂貴的操作，因為它通過生成偽隨機流來解密/加密 2600 字節的數據。此外，洋蔥為最終的下一跳做好了準備。
- 需要處理 HTLC 本身（數據庫查找，…）
這兩種方法都在某些實現中實現：eclair 的移動版本預設不公佈其通道，lnd 計劃對已證明不可靠且 c-lightning 允許的通道和節點實施偏差（儘管不是完全排除）您可以使用
htlc_accepted鉤子將任何您想要的轉發策略作為外掛實現。此外，修改 lnd 和 c-lightning 以使頻道的公告可配置是微不足道的。（免責聲明：我是規範作者之一，從事 c-lightning 工作）