add 08-08

_posts/2024-04-18-#8545.md

@@ -6,7 +6,7 @@ pr: 8545
 authors: [ziggie1984]
 components: ["utxo sweeping"]
 host: ziggie1984
-status: upcoming
+status: past
 commit:
 ---
 

_posts/2024-08-08-#8512.md

@@ -0,0 +1,26 @@
+---
+layout: pr
+date: 2024-08-08    
+title: "[3/4] - lnwallet/chancloser: add new protofsm based RBF chan closer"
+pr: 8512
+authors: [roasbeef]
+components: ["utxo sweeping"]
+host: ProofOfKeags
+status: upcoming
+commit:
+---
+
+## Questions
+
+- When considering the existing coop-close protocol, who pays the closing fees?
+- ⁠What are some of the failure modes that can arise from fee negotiation?
+- ⁠What are the incentives for the the following party/scenario: initiator/initiator closes, target/initiator closes, initiator/target closes, target/target closes?
+- ⁠Ideally who should pay the fees during a coop close and why?
+- In coop close v2 who pays the coop close fees?
+- ⁠What are the different intermediate states a closing negotiation can be in?
+- ⁠How can we use this new protocol state machine to do fee bumping?
+- ⁠Which party can fee bump the closing transaction?
+- ⁠What are some practical benefits of RBF'ing a coop close transaction?
+- ⁠SWE: What does the new protofsm library do?
+- ⁠SWE: What are some advantages of using protofsm here?
+- ⁠SWE: What are some potential drawbacks of using protofsm here?