Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 62700C002D for ; Wed, 14 Dec 2022 17:41:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4A6CC81E72 for ; Wed, 14 Dec 2022 17:41:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4A6CC81E72 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=uszQAX4U X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9Y9y3aea9OH for ; Wed, 14 Dec 2022 17:41:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org F19AF81E1A Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) by smtp1.osuosl.org (Postfix) with ESMTPS id F19AF81E1A for ; Wed, 14 Dec 2022 17:41:31 +0000 (UTC) Received: by mail-vs1-xe2a.google.com with SMTP id 128so419873vsz.12 for ; Wed, 14 Dec 2022 09:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=q32-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=80bWrDClN86cYlOZUhTfyH+zDXOXSAPe3xvOk1d0t8s=; b=uszQAX4U8ppkbc0GW34t18C3smooL+X9ogBkYlwkzmPSDmkmWqE94jWSIJEO6tt+a0 mSEagXmfgoo2T6jbZ9/B3613IRSJFdgQ9haBRCjJfyP/L21zqhkMasgClxCLW3BJOZAv NoXXRNEWalD+QN3WoBLi+ogO9QgAdrscJCkJhUbwetrgrz1Y784jiaTyx3GKkyaJ57rI hC3j4RiLPr+GIkk5jm+TGORedFUDuZqexvDHTKMxffaoIHnXjbpaNviegLW1YUKcuJDu J7nasH4YquPaJtKC15DIqkdxwDcQP7Kbbt+9+Rxo2YVRUMoNjwW4lh0VIC9AmM+DBg4M gttA== 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=80bWrDClN86cYlOZUhTfyH+zDXOXSAPe3xvOk1d0t8s=; b=fba7pyInrk1ZNW0FBd8WFFc3GT7/jceyHWKftdNtrmQkuUICzh9B7ki7Rh0d8xVj/n taxWsNwiEvL1yqArc5MM0hBCatTAdVabKfAogkHxNzU4MG0EHsC9RIGTRcPPc24410Ck wWxRogZqtKxMzXI1YKqIi5iYQ/waLRXsLFzM9fMxFaLDmmw3O/B/F4gcL/ugKcgZK9Zp S6rkohlJND8acVdGG232pNleOLVurjASXZoh6HcEJneSiilCJkNuhxcRqaxwiI4jowVX 1zjc63hPicP4hD6dpugM+679zz22h4tZHMIKvg9vMCrLjEfcU1OEBiPqJLeqO0rdc0BS NUMQ== X-Gm-Message-State: ANoB5pnnsdL8N8xCsZ8t/S50CFeUHHmmNeP8Xggz5kUm4L3Hb5OTWnKP 43mro60jgB4ZjKhlXcKOw2XLGFUJpnAloS3pMOzA9UbfBSoQ X-Google-Smtp-Source: AA0mqf5xd5Tp1jV/vXzI+ZrOYDRVfCuc49ren/YfvPhcmZMV6PeCCMH/wCU2pmQxJeTiejJptbZ15Hcr2HnV5QWKrNs= X-Received: by 2002:a05:6102:3751:b0:3af:b950:489d with SMTP id u17-20020a056102375100b003afb950489dmr57159298vst.36.1671039690597; Wed, 14 Dec 2022 09:41:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Wed, 14 Dec 2022 12:41:17 -0500 Message-ID: To: Daniel Lipshitz , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000029ec1805efcd3f09" X-Mailman-Approved-At: Sun, 18 Dec 2022 11:02:50 +0000 Cc: 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: Wed, 14 Dec 2022 17:41:33 -0000 --00000000000029ec1805efcd3f09 Content-Type: text/plain; charset="UTF-8" NACK support for 0-conf is harmful for reasons already stated ad nauseum On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A 0-conf double spend caused by FSS-RBF would be harmless since the > original output (address and amounts) remain in the double spending trx. > > So all a merchant would need to do is monitor block inclusion for the > relevant output. Addition of some wallet logic would resolve it easily. > > Technically the only difference is that a FSS-RBF requires an additional > input trx to be included in the second trx. > > Not clear to me, why the limitation of adding an additional input hinders > the added value of FullRBF and how significant that hinderance is. > > > > On Tue, 13 Dec 2022 at 11:59 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 >>>> >>> -- > ________________________________ > Daniel Lipshitz > GAP600 > www.Gap600.com > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --00000000000029ec1805efcd3f09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
NACK

support for 0-conf is harmful= =C2=A0for reasons already stated ad nauseum

=

On Wed, Dec 14, 2022 at 4:58 AM Daniel Lipshitz via bitcoin-dev &= lt;bitcoin-dev@lis= ts.linuxfoundation.org> wrote:
A 0-conf double spend caused by FSS= -RBF would be harmless since the original output (address and amounts) rema= in in the double spending trx.=C2=A0

So all a merchant would need to do is monitor =C2=A0block incl= usion for the relevant output. Addition of some wallet logic would resolve = it easily.

Technically t= he only difference is that a FSS-RBF requires an additional input trx to be= included in the second trx.=C2=A0

Not clear to me, why the limitation of adding an additional inpu= t hinders the added value of FullRBF and how significant that hinderance is= .=C2=A0


<= br>
On Tue,= 13 Dec 2022 at 11:59 John Carvalho <john@synonym.to> wrote:
Why wasn't this solut= ion put in=C2=A0place back then? Are there problems with the design?
While I still think there are unhealthy side-effects of Full-R= BF (like more doublespending at unknowing=C2=A0merchants, after years of FS= S protection) I think discussion of this FSS-RBF feature is worth consideri= ng.

--
=
John Carval= ho
CEO,=C2=A0Synonym.to


On Tue, Dec 13, 2022 at 8:09 AM Daniel Lipshitz <daniel@gap600.com> w= rote:
Thank you for bringing that to my attention, apologies for not bei= ng aware of it.

First-seen-safe replace-by-fee as detail= ed here=C2=A0https://lis= ts.linuxfoundation.org/pipermail/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 Ful= lRBF while retaining=C2=A0 the significant=C2=A00-conf use case.
=
This would seem like a good way forward.



________________________________=



On Tue, Dec 13, 2022 at = 6:20 AM Yuval Kogman <nothingmuch@woobling.org> wrote:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Ma= y/008248.html
--
__________________________= ______
Daniel Lipshitz
GAP600
www.Gap600.com


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000029ec1805efcd3f09--