Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6EDAFC002D for ; Tue, 13 Dec 2022 11:33:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3D2014059E for ; Tue, 13 Dec 2022 11:33:14 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3D2014059E Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=BpfVeAAn X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=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 GZqmIWfie84n for ; Tue, 13 Dec 2022 11:33:13 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ECD8440598 Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) by smtp2.osuosl.org (Postfix) with ESMTPS id ECD8440598 for ; Tue, 13 Dec 2022 11:33:12 +0000 (UTC) Received: by mail-io1-xd2a.google.com with SMTP id h6so1511040iof.9 for ; Tue, 13 Dec 2022 03:33:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bP3qzM62ArnSUoMF3jLXqxJHKB8uClBvfaGD59pKgHU=; b=BpfVeAAnuJZ7pnGplu2m9Tv2HynW6aPBoasCy2l3z2EqAmwm/340+bhWlVRLRRb2Wb Fud354zZCln9r1IT/Oxy4Q7/77Sk1TpvpWXFewFDkSbSkCmFqGolWF+yGFqN1kn0dcal VrS1ILamSQcguahQGTbydTHGCqkwkuhB35u4xBx35i0Rs9TaTEkIPFraAEitcJ4UfE8K LLHw25z0/xiqecfEP1zM55/NEEXJtebREmlEl1wTDpA2EE8EfU09u6TIG1MAEI93ryQ8 bVWSkaGMrU6TeWjq1Q39imGYSMNHpcQZM7LLJz+8iU7yPku/6+m/m22t6hdltuFayPYI Qqig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bP3qzM62ArnSUoMF3jLXqxJHKB8uClBvfaGD59pKgHU=; b=SpcGPvbZbryYRme6Tyy/phlqQiWf0oJ+CLNLFK2H4C2BctsgT06D2oLqY98r0tE28r 6rbAt6ELRILp+gHOrf2NWFHhnNjRgZdjK4c9jESJUiffIZ6NzvCuZrFEYCwY2BhLGuu/ 5IvhGRoPGRy1VWck5U5BtXNeiuridclnTFaL+DNoCNTl2lRaiEzyzuWQoSzgg34KIDvK rSMWp7xLAL2hWOc/2wldD725MUkdMZzFYXP/Dh0YpMGkMRu+AVAIS3iGLyJYJZJ4kVQf Z4+PdhVfUrfdMxQoVA8S+LSC+nMlArscmK4CK7+NihPmRxy0gTg/xhx4q0ZxdqoqAoSm x2vg== X-Gm-Message-State: ANoB5pmfzyHpYbzU2cgwAO764+Cjh5J/cQ9gH6i6nC/9Bjpesi8MrhFO w45rGIkp5eALt07KrB4VNWL16t8bhrLcsugR0yaBJXnsORy1CV5J X-Google-Smtp-Source: AA0mqf5JAG7CKHe/3AQHyRv5zi1zydA7OxwaQC4dkCNkUbUo1HCjehuhdn2lnyK89SAbTVkF1AaEzp/EFXX4QGS5/M4= X-Received: by 2002:a05:6638:591:b0:38a:9192:2ba6 with SMTP id a17-20020a056638059100b0038a91922ba6mr1254826jar.76.1670931191750; Tue, 13 Dec 2022 03:33:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Tue, 13 Dec 2022 13:33:00 +0200 Message-ID: To: John Carvalho Content-Type: multipart/alternative; boundary="00000000000021004405efb3fcbe" X-Mailman-Approved-At: Tue, 13 Dec 2022 13:07:59 +0000 Cc: bitcoin-dev Subject: Re: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 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: Tue, 13 Dec 2022 11:33:14 -0000 --00000000000021004405efb3fcbe Content-Type: text/plain; charset="UTF-8" I dont think there was anything technical with the implementation and as far as I can tell this is well developed and ready. The reasons I can find for not being adopted are listed here - https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe Replace-by-fee Those reasons do not seem pertinent here - given OptinRBF already exists as an option and the added benefit of continuing to be able to support 0-conf. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz On Tue, Dec 13, 2022 at 11:59 AM John Carvalho wrote: > Why wasn't this solution put in place back then? Are there problems with > the design? > > While I still think there are unhealthy side-effects of Full-RBF (like > more doublespending at unknowing merchants, after years of FSS protection) > I think discussion of this FSS-RBF feature is worth considering. > > -- > John Carvalho > CEO, Synonym.to > > > On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz wrote: > >> Thank you for bringing that to my attention, apologies for not being >> aware of it. >> >> First-seen-safe replace-by-fee as detailed here >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >> by Peter Todd seems to be a very suitable option and route >> which balances FullRBF while retaining the significant 0-conf use case. >> >> This would seem like a good way forward. >> >> >> >> ________________________________ >> >> >> >> On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman >> wrote: >> >>> >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html >>> >> --00000000000021004405efb3fcbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I dont think there was anything technical with the impleme= ntation and as far as I can tell this is well developed and ready.

=
The reasons I can find for not being adopted are listed here -= =C2=A0https://bitcoin= core.org/en/faq/optin_rbf/ under - Why not First-seen-safe Replace-by-f= ee=C2=A0

=C2=A0Those reasons do not seem pertinent= =C2=A0here - given OptinRBF already exists as an option and the added benef= it of continuing=C2=A0to be able to support 0-conf.

________________________________

Daniel Lipshitz
GAP600|=C2=A0www.gap600.com
Ph= one:=C2=A0+44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Tue, Dec 13, 2022 at 11:59 AM John Carvalho <john@synonym.to> wrote:
Why wasn't = this solution put in=C2=A0place back then? Are there problems with the desi= gn?

While I still think there are unhealthy side-effects= of Full-RBF (like more doublespending at unknowing=C2=A0merchants, after y= ears of FSS protection) I think discussion of this FSS-RBF feature is worth= considering.

--
J= ohn Carvalho
CEO,=C2=A0Synonym.to

<= br>
On Tue,= Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> wrote:
Thank you for br= inging that to my attention, apologies for not being aware of it.

<= /div>
First-seen-safe replace-by-fee as detailed here=C2=A0https://lists.linuxfoundation.org/pi= permail/bitcoin-dev/2015-May/008248.html=C2=A0 by Peter Todd=C2=A0 seems to be a very= suitable option and route which=C2=A0balances FullRBF while retaining=C2= =A0 the significant=C2=A00-conf use case.

This wou= ld seem like a good way forward.


________________________________


=

On Tue, Dec 13, 2022 at 6:20 AM Yuval Kogman = <nothingmu= ch@woobling.org> wrote:
https://l= ists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html
--00000000000021004405efb3fcbe--