📅 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
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 23:14:26
in reply to nevent1q…76vd
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 23:14:26Event JSON
{
"id": "89a5b1ee7ce3bf05950ced67072ebad07dd72f326dacaaf9267d15bd3eefe7ce",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686179666,
"kind": 1,
"tags": [
[
"e",
"946b9a8231803f73c278c08ca74b58bc34d6ba681eae8ff2a82e75b78f2e09ab",
"",
"root"
],
[
"e",
"fca85c9a233547eada0564ddaef1e375fc0ed493363f510c220744fdfd257c7e",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-10-07\n📝 Original message:On Friday 07 October 2022 16:20:49 Dario Sneidermanis via bitcoin-dev wrote:\n\u003e At the time, we understood we had at least a year from the initial opt-in\n\u003e deployment until opt-out was deployed, giving us enough time to adapt Muun\n\u003e to the new policies.\n\nPolicies are a per-node decision, and cannot be relied on in general.\nFull RBF has been the default in Bitcoin Knots for years, and de facto viable \nfor use on the network even longer.\n\n\u003e However, when reviewing the 24.0 release candidate just \n\u003e a few days ago, we realized that zero-conf apps (like Muun) must\n\u003e *immediately turn off* their zero-conf features.\n\nRBF deals with UNconfirmed transactions, not zero-confirmed (Lightning).\n\n\u003e I understand this wasn't the intention when designing the opt-in deployment\n\u003e mechanism. Given this new information, do you see a path where we can delay\n\u003e the opt-in deployment and find a safer way to deploy full-RBF?\n\nFull RBF has been available for users on an opt-in basis since at least 2013, \nlong before BIP 125 was even conceived of.\n\n\u003e We call zero-conf applications to entities that accept on-chain payments\n\u003e from\n\u003e *untrusted parties* and will sometimes deliver the paid-for product or\n\u003e service\n\u003e without waiting for the transaction to be included in a block.\n\nThis is unsafe period. RBF does not make it any less unsafe.\n\n\u003e All of these applications are receiving incoming on-chain transactions for\n\u003e which\n\u003e they don't control the inputs, and performing a risk analysis to decide\n\u003e whether\n\u003e they are ok with accepting the payment without confirmation.\n\nThis is nothing but a false sense of security.\n\nLuke",
"sig": "38e6c9009e123c08f16507017f875109970a4855f58c240b2a814de32c8df89a25d8b4ad4961061cd2213cc62878f790f9b6cc8ad55bd5af3dfbf4e746b896aa"
}