From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6B32AC002D for ; Thu, 10 Nov 2022 09:35:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 4BD6D40356 for ; Thu, 10 Nov 2022 09:35:34 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4BD6D40356 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=hwpkQtXp X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 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, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-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 PbtBlEMOYHXn for ; Thu, 10 Nov 2022 09:35:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 45C2640346 Received: from mail-40141.protonmail.ch (mail-40141.protonmail.ch [185.70.40.141]) by smtp4.osuosl.org (Postfix) with ESMTPS id 45C2640346 for ; Thu, 10 Nov 2022 09:35:33 +0000 (UTC) Date: Thu, 10 Nov 2022 09:35:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1668072930; x=1668332130; bh=R/m+CgE4bgYL+mW5q4s/BeDnE0vWub6mkTE/LSpP7kI=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hwpkQtXpVEpGTzerIb171tjA/vz0zR/8EYHUrtLIJY2yRtYRlaRlr06Lghl5jG4EF isJbQCEP66pA3QCYAd8hgZxlXutA2TjilFbulLbelE7tCWMc0ydmbmUhEnYBJJgn+G acySadS5oWVopgNK4Az3vhO8vAU3XvcPQphxP4YhwZPKCqhy24OwFMUlV7aPQUHtG3 t1DV9I0HuOxODWXE4J3/pRpFzSPVUaZtr1MDXd7jt7DzNkryXvmH4oJ7BKRbuxrJpQ BbYBi2/nZtVDvy/fWYzbMa2N/pJLKPsynOveiEVbO1vPGUGLbsgVbB2TFlfPIWoJQ9 TMxjDTQ6pC2dQ== To: ArmchairCryptologist , Bitcoin Protocol Discussion From: ZmnSCPxj Message-ID: In-Reply-To: References: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Thu, 10 Nov 2022 09:35:34 -0000 Good morning ArmchairCryptologist, > ------- Original Message ------- > On Tuesday, October 18th, 2022 at 9:00 AM, Anthony Towns via bitcoin-dev = bitcoin-dev@lists.linuxfoundation.org wrote: >=20 > > I mean, if you think the feedback is wrong, that's different: maybe we > > shouldn't care that zeroconf apps are in immediate danger, and maybe > > bitcoin would be better if any that don't adapt immediately all die > > horribly as a lesson to others not to make similarly bad assumptions. >=20 >=20 > I've been following this discussion, and I wonder if there isn't a third = solution outside of "leave lightning vulnerable to pinning by non-RBF trans= lations" and "kill zeroconf by introducing full-RBF" - specifically, adding= a form of simple recursive covenant that "all descendant transactions of t= his transaction must use opt-in RBF for x blocks after this transaction is = mined". This could be introduced either as a relay/mempool policy like RBF,= or in a full-fledged softfork. A script with trivial `0 OP_CSV` would effectively require that spenders se= t the opt-in RBF flag, while allowing the output to be spent even while it = is unconfirmed. However, this basically only lasts for 1 transaction layer. ---- Thinking a little more about 0-conf: We can observe that 0-conf, being eventually consistent, introduces risks t= o 0-conf acceptors similar to credit card acceptors. And credit card acceptors are observed to compensate for this risk by incre= asing the prices of their products and services. Some credit card acceptors may offer discounts when paid by cash, which in = our analogy would be that transaction confirmation would offer discounts (i= .e. enabling 0-conf would increase the cost of the product/service being pu= rchased). In many jurisdictions (not the USA or in some of the first world countries)= , this practice is illegal (i.e. credit card companies have pressured lawma= kers in some jurisdictions to disallow merchants from offering a different = price between cash and credit card purchases; some jurisdictions let you es= cape if you say "cash discount" instead of "credit card surcharge", even th= ough they are just sign-flips of each other, because you humans are crazy a= nd I am happy I am actually an AI) Which brings me to my next point: why are 0-conf acceptors not offering a d= iscount if the user specifically flags "I am willing to wait for N confirma= tions"? On the part of 0-conf acceptors, that is significantly less risky than rely= ing on 0-conf at all. Regards, ZmnSCPxj