rich1.0npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nhttps://nostr.ae/npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nnjumphttps://nostr.ae📅 Original date posted:2022-10-07 📝 Original message:On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote: > At the time, we understood we had at least a year from the initial opt-in > deployment until opt-out was deployed, giving us enough time to adapt Muun > to the new policies. Policies are a per-node decision, and cannot be relied on in general. Full RBF has been the default in Bitcoin Knots for years, and de facto viable for use on the network even longer. > However, when reviewing the 24.0 release candidate just > a few days ago, we realized that zero-conf apps (like Muun) must > *immediately turn off* their zero-conf features. RBF deals with UNconfirmed transactions, not zero-confirmed (Lightning). > I understand this wasn't the intention when designing the opt-in deployment > mechanism. Given this new information, do you see a path where we can delay > the opt-in deployment and find a safer way to deploy full-RBF? Full RBF has been available for users on an opt-in basis since at least 2013, long before BIP 125 was even conceived of. > We call zero-conf applications to entities that accept on-chain payments > from > *untrusted parties* and will sometimes deliver the paid-for product or > service > without waiting for the transaction to be included in a block. This is unsafe period. RBF does not make it any less unsafe. > All of these applications are receiving incoming on-chain transactions for > which > they don't control the inputs, and performing a risk analysis to decide > whether > they are ok with accepting the payment without confirmation. This is nothing but a false sense of security. Luke