Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0F5F9C002D for ; Sat, 15 Oct 2022 04:21:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DE88760BAD for ; Sat, 15 Oct 2022 04:21:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DE88760BAD Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=synonym-to.20210112.gappssmtp.com header.i=@synonym-to.20210112.gappssmtp.com header.a=rsa-sha256 header.s=20210112 header.b=OjpmmhP/ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW7-YRqLyeTY for ; Sat, 15 Oct 2022 04:21:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 87E9460BDB Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) by smtp3.osuosl.org (Postfix) with ESMTPS id 87E9460BDB for ; Sat, 15 Oct 2022 04:21:07 +0000 (UTC) Received: by mail-qt1-x833.google.com with SMTP id g11so4913654qts.1 for ; Fri, 14 Oct 2022 21:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=synonym-to.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=zPrc1ZzCH/ukrCySX19vr24yUvPqrTf/UFIaAaS/gqM=; b=OjpmmhP/oYq5if7LeLqnCzirFZDnhc7uE5cZZ7vihVt8iabP29CpAUaONpiDHkmIMl 3d2y8P4r2bttNTPYPUHJ1fYmyx02y3mCUHg63wHH17SVQ20t4z8SEJnVWX2DB148ROJz jqeg+FDnKtrJr7JBpirEN2jZmSJElKPwg62FugD+kypC4btOZ4V7f1627PSzS/7HwVEl S3u4WIsVNd8aRxXNWZSCEfdIfQmjIWuVCct6nGMMaRBB4zCH0jmTnzRv2gGFZ6khMiyT cZuGG+ML/0a9iSFoba5DFz3WGi7b3cciRzc0+0T1vyouqn9fbAZqYct/yAi5ulhX3yvq ZE7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=zPrc1ZzCH/ukrCySX19vr24yUvPqrTf/UFIaAaS/gqM=; b=jQu8x1tGvgE2xbX1raZsVSaP5igHIv+Ys5Vy5n0jwEbHH3IG+ahYhS2nSatsaJ5ysa e9ctEj6uyll8gbuhaKB38AVRjF/QytgLtBHQnxjauaQsampXfAZz1MwZCQsJeAWALw8I GkRaZlmgL865d7/ja37MBwMtjRhaWZIBEWAHfDYfIbzyLKd9klLA2lHZZpbpxlXcb4lJ tbEmfd5Xcxa/jgWF8yX7Yc5RQbNQmmsQc7FcL7S4vqXDCbXoI9qqdq/U3N2+3HFCmkzG 5y+AfcamZsNnKuPK8FyrYRtoMm6uwpb49sR9taQeB+BhED3LJfUQ+kF8lxpYvy8hCUVX E8HA== X-Gm-Message-State: ACrzQf2YASfiDMS6VOvfhENmO2ABNKuW3FXnFESS/Mng+29d7LtCfvD/ c5FysLDvzFoCox+bHva+sWSZ/dsCFGMXTaQjuI2TaMqMq5ipcg== X-Google-Smtp-Source: AMsMyM67Csyd/y2XsT35Myi4fg66cjAYFWb+CLDpDncv98xN7B1QumlKyDvHy8GorblZYJq7oJsYo8Y1988i9SSvBBo= X-Received: by 2002:ac8:594d:0:b0:35c:ba75:c1dc with SMTP id 13-20020ac8594d000000b0035cba75c1dcmr726146qtz.286.1665807666106; Fri, 14 Oct 2022 21:21:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Carvalho Date: Sat, 15 Oct 2022 06:20:55 +0200 Message-ID: To: Bitcoin Protocol Discussion , Peter Todd Content-Type: multipart/alternative; boundary="00000000000033e39605eb0b1292" X-Mailman-Approved-At: Sat, 15 Oct 2022 14:36:44 +0000 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: Sat, 15 Oct 2022 04:21:09 -0000 --00000000000033e39605eb0b1292 Content-Type: text/plain; charset="UTF-8" Peter, Your argument is totally hypocritical and loses when comparing quantities. Enforcing RBF is observably more "harmful to Bitcoin" (whatever that means...) when it tries to "risk-manage propagation" of replacements, as there more Bitcoiners that want to mutually utilize 0conf than users that want to replace transactions. Spending bitcoin is a use case, so replacing txns reduces utility and makes commitments less certain. No one here arguing for 0conf is suggesting reorgs, so please do not sensationalize with claims of reorgs or "harm." Take note that it is RBF proponents that have changed Bitcoin code and seek to continue to change Bitcoin, RBF that seeks to reduce commercial utility -- but 0conf proponents are not asking for changes to Bitcoin, not suggesting soft or hard forks, etc. We are asking you to stop breaking things by adding features for minority speculative interests. -John On Fri, Oct 14, 2022 at 5:04 PM Peter Todd wrote: > On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev > wrote: > > In support of Dario's concern, I feel like there is a degree of > gaslighting > > happening with the advancement of RBF somehow being okay, while merchants > > wanting to manage their own 0conf risk better being not okay. > > The way merchants try to manage 0conf risk is quite harmful to Bitcoin. > Connecting to large numbers of nodes to try to risk-manage propagation > _is_ an > attack, albeit a mild one. Everyone doing that is very harmful; only a few > merchants being able to do it is very unfair/centralized. > > ...and of course, in the past this has lead to merchants trying to make > deals > with miners directly, even going as far as to suggest reorging out > double-spends. I don't need to explain why that is obviously extremely > harmful. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- -- John Carvalho CEO, Synonym.to Schedule: https://calendly.com/bitcoinerrorlog Chat: https://t.me/bitcoinerrorlog Social: https://twitter.com/bitcoinerrorlog --00000000000033e39605eb0b1292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter,

Your argument is totally hypocritical and loses when comparing quantities.= =C2=A0

Enforcing RBF is = observably more "harmful to Bitcoin" (whatever that means...) whe= n it tries to "risk-manage propagation" of replacements, as there= more Bitcoiners that want to mutually utilize 0conf than users that want t= o replace transactions.=C2=A0

Spending bitcoin is a use case, so replacing txns reduces utility and= makes commitments less certain.

No one here arguing for 0conf is suggesting reorgs, so please do = not sensationalize with claims of reorgs or "harm."

Take note that it is RBF proponents t= hat have changed Bitcoin code and seek to continue to change Bitcoin, RBF t= hat seeks to reduce commercial utility -- but 0conf proponents are not aski= ng for changes to Bitcoin, not suggesting soft or hard forks, etc. We are a= sking you to stop breaking things by adding features for minority speculati= ve interests.

-John=C2= =A0

On Fri, Oct 14, 2022 at 5:04 PM Peter Tod= d <pete@petertodd.org> wrot= e:
On Fri, Oct 14, 2022 at 12:03:21PM +0200, John= Carvalho via bitcoin-dev wrote:
> In support of Dario's concern, I feel like there is a degree of ga= slighting
> happening with the advancement of RBF somehow being okay, while mercha= nts
> wanting to manage their own 0conf risk better being not okay.

The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
Connecting to large numbers of nodes to try to risk-manage propagation _is_= an
attack, albeit a mild one. Everyone doing that is very harmful; only a few<= br> merchants being able to do it is very unfair/centralized.

...and of course, in the past this has lead to merchants trying to make dea= ls
with miners directly, even going as far as to suggest reorging out
double-spends. I don't need to explain why that is obviously extremely = harmful.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--
--00000000000033e39605eb0b1292--