From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D3651C002D for ; Fri, 7 Oct 2022 21:04:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id A7E1340136 for ; Fri, 7 Oct 2022 21:04:22 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A7E1340136 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org header.a=rsa-sha256 header.s=zinan header.b=KawJb3mR X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdJbqN0NF8Mb for ; Fri, 7 Oct 2022 21:04:22 +0000 (UTC) X-Greylist: delayed 00:07:29 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D7837400AF Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp2.osuosl.org (Postfix) with ESMTP id D7837400AF for ; Fri, 7 Oct 2022 21:04:21 +0000 (UTC) Received: from ishibashi.lan (unknown [12.151.133.18]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 6B2F338A3113; Fri, 7 Oct 2022 20:56:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; t=1665176211; bh=uUfVnuZTe53h5/SMa7fHbNof30J3KL3vT6hCNryPJKs=; h=From:To:Subject:Date:References:In-Reply-To; b=KawJb3mRQBU5ztNjIMX2NJtOatfbyqilTqKcJbwAre6ILJ7tPEqkQRPrP7vyTjpaF uJFLSzwaR8XICDH6ZdhFWZk69FUA77st7elJEGwOCQoiFEvu6v7QOmOcu29Sx6sZ0G uA8qqIh/532lxRUkVKYubu6rX+dVba5wl/nrAxeE= X-Hashcash: 1:25:221007:bitcoin-dev@lists.linuxfoundation.org::44gX2xzZmM7P3SVf:azktN X-Hashcash: 1:25:221007:dario@muun.com::vC7u8==GkNEwyT4x:bBfZR From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Dario Sneidermanis Date: Fri, 7 Oct 2022 20:56:21 +0000 User-Agent: KMail/1.9.10 References: In-Reply-To: X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <202210072056.22296.luke@dashjr.org> Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2022 21:04:22 -0000 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