Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id EDAF2C002D for ; Mon, 5 Dec 2022 21:14:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B4E1B60BF4 for ; Mon, 5 Dec 2022 21:14:18 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B4E1B60BF4 Authentication-Results: smtp3.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=ovXXqbD3 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9v6hYeO2ZOZ for ; Mon, 5 Dec 2022 21:14:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org BE2D0600B5 Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) by smtp3.osuosl.org (Postfix) with ESMTPS id BE2D0600B5 for ; Mon, 5 Dec 2022 21:14:17 +0000 (UTC) Received: by mail-ua1-x936.google.com with SMTP id n9so4328303uao.13 for ; Mon, 05 Dec 2022 13:14:17 -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=R11YVqzMCSJRK8vNw2PsfLDgG4iC1D7UyTcp2zXCH7E=; b=ovXXqbD3jiFkLX8f4/YC1J0gTfDVX1cRnbRu0hnDGqQ2b0E0FWqodMLtbUx+V97qDC JEhbhcTxH7CJnlApdwIjKHPydKmJ8PRn+X8uP5bMY6RVpfxHPbKnx0sef9hMJSEBWlSc 2MEXWPVOKmVK5hvPM1m1Tw0AH9O0ybC3VL2tmNWnE8NZs6hUEDwjjL+9GV1yYStymahP hKXtKqhSZfFwRlwEMOrYr9xZJWrOQbikIb/LUb41sWekQdSmYqGNbvLBYCQa1inUzAY3 HI31c25Br8RikY2aLEj2iw1Wh9C3o7o1uKaTlDZXEVYrqK0gXEL8/NsC+UIZcWdmbo6s PmgA== 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=R11YVqzMCSJRK8vNw2PsfLDgG4iC1D7UyTcp2zXCH7E=; b=zsGLaEIYUIeaUfDHxxvcNvGOOWB6jSP9yowZSGx3C3nwqV7eXztGxWI1vPEkIGsWeR ncwbxc/I+MTLei77uC3RUFqBHhhsAjyDcCtzGi0vBlAx0ai1UcppkLKtmc+pIV+v09CA rghlv8jFU5yqyfaqoY33Nn8LulnwXLyD9ykX18Jt6d1V967oa4vA3B0oGBPeZLRYkjM2 IX5zLHfVk9NX30HqCsbLRS3i2sRpW47jbojYZT9pBd0GeSLykS72d39QkGscDaMaGvr8 IBT+uB3GTn5J62a3TY1rxeEGn8ID+BvCZUbWxfZSwDDAuHJfr8/kMxM4p6WwOhWkoEKM /L2A== X-Gm-Message-State: ANoB5pm33ipas85iEuZCZoTBUdtqw0OzcfL9F2FvGx4LLkYmw6roImZ8 heHUOvhFsLMjpdN/GL8izoSz0foC+vuUQ408TuJdlClbGy8tIQ4= X-Google-Smtp-Source: AA0mqf7Y3jpdOrkeACCNRhLM3rrqVQLA9GgjqNBrLdJW7A+iPjyw2k6njIjiUmiwSesTAIW99sxUS33Be2FO93MxF+I= X-Received: by 2002:ab0:b8e:0:b0:404:3611:fb13 with SMTP id c14-20020ab00b8e000000b004043611fb13mr45369928uak.54.1670274855047; Mon, 05 Dec 2022 13:14:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Mon, 5 Dec 2022 16:14:03 -0500 Message-ID: To: John Carvalho , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000069996505ef1b2b43" X-Mailman-Approved-At: Tue, 06 Dec 2022 12:13:39 +0000 Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger (angus) 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: Mon, 05 Dec 2022 21:14:19 -0000 --00000000000069996505ef1b2b43 Content-Type: text/plain; charset="UTF-8" > > > > Many zero-conf proponents work on the bleeding edge of supporting > Lightning, including myself. Lightning is not risk-free and the base layer > should not be assuming it as a primary dependency for commercial payments. > for low-value payments, lightning is the only workable version because the current low-fee environment is not scalable and never will be for high valued payments, zero conf was never valuable or useful and never can be - it was always the beneficence of users you are relying on low fee/high fee double spends of a zero conf with no rbf flag has been demonstrated, repeatedly ad nauseum. ... so there is no long term scenario where zero conf is valuable. right *now* with low fees it might "seem nice", but really it just incentivises network-wide surveillance, increased peer burden on nodes, and unsustainable practices that are akin to a "mev" bounty hanging over merchant's heads. also, i've been using bitcoin for years without zero conf. selling and buying online. operating merchants with millions in transactions. the 20 minute wait before i ship is meaningless, and the only risk i take on is that a user replaces a transaction with a different destination. which i've never observed. even with the flag on (which i dont care about, and never have). and if i do observe it ... i just won't ship. it was easy to code up. the user will have to initiate a new tx. i have no objection to a user being able to cancel their order. why would i? > --00000000000069996505ef1b2b43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Many zero-conf = proponents work on the bleeding edge of supporting Lightning, including mys= elf. Lightning is not risk-free and the base layer should not be assuming i= t as a primary dependency for commercial payments.

for low-value payments, lightning is the only workable vers= ion because the current low-fee environment is not scalable and never will = be

for high valued payments, zero conf was never valuable or us= eful and never can be - it was always the beneficence of users you are rely= ing on=C2=A0 =C2=A0low fee/high fee double spends of a zero conf with no rb= f flag has been=C2=A0demonstrated, repeatedly ad nauseum.=C2=A0 =C2=A0
<= br>... so there is no long term scenario where zero conf is valuable.=C2=A0= =C2=A0

right *now* with low fees it might "seem nice", bu= t really it just incentivises network-wide surveillance, increased peer bur= den on nodes, and unsustainable practices that are akin to a "mev"= ; bounty hanging over merchant's heads.

also, i've been usin= g bitcoin for years without zero conf.=C2=A0 =C2=A0selling and buying onlin= e.=C2=A0 =C2=A0operating merchants with millions in transactions.=C2=A0 =C2= =A0the 20 minute wait before i ship is meaningless, and the only risk i tak= e on is that a user replaces a transaction with a different destination.=C2= =A0 =C2=A0which i've never observed.=C2=A0 =C2=A0even with the flag on = (which i dont care about, and never have).

and if i do observe it ..= . i just=C2=A0won't ship.=C2=A0 =C2=A0it was easy to code up.=C2=A0 =C2= =A0the user will have to initiate a new tx.=C2=A0 =C2=A0i have no objection= to a user being able to cancel their order.=C2=A0 =C2=A0why would i?

--00000000000069996505ef1b2b43--