Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5402BC002D for ; Tue, 13 Dec 2022 14:08:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 1F706408A7 for ; Tue, 13 Dec 2022 14:08:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1F706408A7 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=eEaoSn8k 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGFGtL9gMsXS for ; Tue, 13 Dec 2022 14:08:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8C0C440425 Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8C0C440425 for ; Tue, 13 Dec 2022 14:08:22 +0000 (UTC) Received: by mail-il1-x131.google.com with SMTP id d10so311383ilc.12 for ; Tue, 13 Dec 2022 06:08:22 -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=ARhSKazQVra9ZghMDfVKgLyQO6EZPkYHtnXW1IMl3CM=; b=eEaoSn8kygcMFYbFMBEGsEePJWwLii4WyuKvLCCdlvIT+vX/JTVg3OvE3YpGDyM58D kVFBrz54tlBf83cSYBJmoEsYAr7nFL99rAFcXIv4bxERI4k1p1bynP7+Se+UqNhwpPRM 9wuxeEwRcNI86V7iiGosgnzGHtUDYFHlmePP+RlyshrCN+QPR59tvOiXYuCEkXANo4gP zX7Z67V8bSrIP3bJPX1NWUrB7nATJDrO2m3qYtyoDuEf0jp944WxeYoDjKyPhxOAy8b3 rAFhv39/cNIt2mkjYh4dWahOf60GmmRQmb5kcCfD+LnAo13B/IAIy9Sv3XVRXPD/oN8M 2ZYw== 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=ARhSKazQVra9ZghMDfVKgLyQO6EZPkYHtnXW1IMl3CM=; b=r8hlIvq8kxZOxUx+1sVN3SKE/Vcvl5eBmnF2Fw+phfTIU+k41MPkDbnntdull4rFmB 8CFNcQBmSPVVt2fC6ZcJC7RdjHEr+Kqprga/F0n9RbQKRJ09aC9ex4kxf65udRAbP36o MbdF0uCLAnBHO208Ne6yXMKd2Ms+8f3QuxocBwpjZqDCR2CxOYRHUxEbRujQAnw3I+Em qG1cr4EKImCoBC4BFOvdTwl3RCsPCfcighjLs0q9BvYE0JOdFQgqsar2BWIa1Xro40V8 5DIcgNH09BDuFDvIUg9WNg4LlU8gm3h2f4JOQIfDb7P6js3cW+JuLILGV5VKSOT+VaKs se5g== X-Gm-Message-State: ANoB5pmyKR0Wn2taDaDgfmXutJH/Bt9eqlypYT+e/45DwYfdWjF8nfP+ L8ZCc1ou0AfbaybCORrbzO0zB0RI2sLr9U4UAEXl7g== X-Google-Smtp-Source: AA0mqf5hTKFmo9tN9UHm5yWI+KRh511Obko0rOjha/f6+FiAmJA9116dal+w71dCdg7YjfJNj7nKd4JF97YNPS7DK0U= X-Received: by 2002:a92:6e0a:0:b0:302:4d37:9e69 with SMTP id j10-20020a926e0a000000b003024d379e69mr39698714ilc.160.1670940501434; Tue, 13 Dec 2022 06:08:21 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Lipshitz Date: Tue, 13 Dec 2022 16:08:10 +0200 Message-ID: To: Lucas Ontivero Content-Type: multipart/alternative; boundary="000000000000077e9c05efb62778" X-Mailman-Approved-At: Tue, 13 Dec 2022 16:19:36 +0000 Cc: Bitcoin Protocol Discussion , John Carvalho 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 14:08:24 -0000 --000000000000077e9c05efb62778 Content-Type: text/plain; charset="UTF-8" This would not effect optinrbf only fullRBF On Tue, 13 Dec 2022 at 16:00 Lucas Ontivero wrote: > Some wallets like Electrum would be affected by that because they use RBF > to batch transactions so, outputs cannot be exactly the same as before. > > On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> 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 >>>>> >>>> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > -- ________________________________ Daniel Lipshitz GAP600 www.Gap600.com --000000000000077e9c05efb62778 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This would not effect optinrbf only fullRBF=C2=A0

On = Tue, 13 Dec 2022 at 16:00 Lucas Ontivero <lucasontivero@gmail.com> wrote:
Some wallets like Electrum woul= d be affected by that because they use RBF to batch transactions so, output= s cannot be exactly the same as before.

On Tue, Dec 13, 2022 at 10:09 AM Daniel Lipshitz via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
I dont think there was anything tec= hnical with the implementation and as far as I can tell this is well develo= ped and ready.

The reasons I can find for not being adop= ted are listed here -=C2=A0https://bitcoincore.org/en/faq/optin_rbf/ under= - Why not First-seen-safe Replace-by-fee=C2=A0

= =C2=A0Those reasons do not seem pertinent=C2=A0here - given OptinRBF alread= y exists as an option and the added benefit of continuing=C2=A0to be able t= o support 0-conf.

___________= _____________________

Daniel Lipshitz=
GAP600|=C2=A0www.gap600.com
Phone:=C2=A0+44 113 4900 117<= /span>
Skype: daniellipshitz123
Twitter: @= daniellipshitz

On Tue, = Dec 13, 2022 at 11:59 AM John Carvalho <john@synonym.to> wrote:
Why wasn't this so= lution put in=C2=A0place back then? Are there problems with the design?
While I still think there are unhealthy side-effects of Ful= l-RBF (like more doublespending at unknowing=C2=A0merchants, after years of= FSS protection) I think discussion of this FSS-RBF feature is worth consid= ering.

<= span style=3D"color:rgb(34,34,34)">--
John Car= valho
CEO,=C2=A0Synonym.to


On Tue, Dec 1= 3, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> wrote:
Thank you for bringing= 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/piperma= il/bitcoin-dev/2015-May/008248.html=C2=A0 by Peter Todd=C2=A0 seems to be a very suit= able option and route which=C2=A0balances FullRBF while retaining=C2=A0 the= significant=C2=A00-conf use case.

This would seem= like a good way forward.



=
________________________________



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--
________________________________
Dani= el Lipshitz
GAP600
www.Gap600.com


--000000000000077e9c05efb62778--