Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B6AF3C0032 for ; Thu, 2 Nov 2023 08:58:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 84DCF4EFFA for ; Thu, 2 Nov 2023 08:58:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 84DCF4EFFA Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=synonym-to.20230601.gappssmtp.com header.i=@synonym-to.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=dzWf387e 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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om3oxKhIPsbg for ; Thu, 2 Nov 2023 08:58:49 +0000 (UTC) Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by smtp4.osuosl.org (Postfix) with ESMTPS id 05A224F02A for ; Thu, 2 Nov 2023 08:58:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 05A224F02A Received: by mail-yb1-xb31.google.com with SMTP id 3f1490d57ef6-d9c7bba32beso695324276.1 for ; Thu, 02 Nov 2023 01:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=synonym-to.20230601.gappssmtp.com; s=20230601; t=1698915527; x=1699520327; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=SPAngvt89vF/2azbAEZzBt8/kgajwrxfOzF3wNFE6b0=; b=dzWf387eq6Cu3Fbj+n27KZYeqaXMgt2heB1Ej6niSPhKhCP0sy8Ed2Y5WpgC3gl8vp oayLxsWc3l9Krk151l52qqdqism0V9k7q5tOulVjRksDdln1J3QDDsdK+bH760QkUznF MVs4LT8Eh6Z6ILf1gMP8BkmkG4auybvltOxcVbbB0v7tQLvTxv4HoOPTRMj8/Ee9ZpHm A055l/1+ec70EHu1OWLeYQyWlLfidjlDx6n2FKUbCOcQGfk6RH04sgijGce4EJr3soGl NczF0dt/Qy4u30lTYHa8rTNJgBoFvJSysL5vQfFk5edOb5hvQ4vz9/+uzD7LN80IMF+y z3Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698915527; x=1699520327; 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=SPAngvt89vF/2azbAEZzBt8/kgajwrxfOzF3wNFE6b0=; b=vHTj6bNv7/8X50ViA/FFrWbm+3brWu2D9qW78TSUh+S0amAw6hGK386lS9cDK3aMqX FQD2D8FuwXR5FA7p3oj4CjBxooFX1q0i/hU9iCgc/KFEvE65CLzxYR1rkIg5PoJP20Jo V4fgqYG5a8biSGcD5gnH1TG+BeZ1tEPnUpKqHT/eSYbTHTQa4o73FoE5v3o7yWFJgn// KNDehWD5hK5WN855jf1XU7IyHfHPbPmun+147eE8kRIsfqFsagxoK0OK6/1vTsX44IBY m/LKoVtu6joMs9nxgdEVUpFU3ZGfmK/azgnrhtiTT20Tssrpt+6AnNnPP0Rpv3CKjp+H u82Q== X-Gm-Message-State: AOJu0Ywg77oD2hSasXR62iAgtz6iQ9JsXcXSeaGWAr66PNxmhD3ug9Jx ClvxKRj9heRVCm5MRIMKJkWEr4QI25yDzSGRjGk4xHs3ew9KjMH2EUU= X-Google-Smtp-Source: AGHT+IEhJs0apq61cwewi7i4qEzivs3VuuNTJ3QCkNZzWVgFPyIcVM3OrFs/dgo/LTFAYqJrtKeNXhPlxq8/bjInyNc= X-Received: by 2002:a25:30d:0:b0:d15:7402:f7cd with SMTP id 13-20020a25030d000000b00d157402f7cdmr19141608ybd.27.1698915527366; Thu, 02 Nov 2023 01:58:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: John Carvalho Date: Thu, 2 Nov 2023 08:58:36 +0000 Message-ID: To: Bitcoin-Dev Mailing List Content-Type: multipart/alternative; boundary="000000000000832e3006092798ab" X-Mailman-Approved-At: Thu, 02 Nov 2023 11:36:06 +0000 Subject: [bitcoin-dev] The Pinning & Replacement Problem Set 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, 02 Nov 2023 08:58:53 -0000 --000000000000832e3006092798ab Content-Type: text/plain; charset="UTF-8" Good morning, All layers and technologies "on" Bitcoin will fail in situations where miners misbehave or the blocks & mempool remain consistently, overly full. Consider this as a "law" of Bitcoin/blockchains. In hindsight (for you, not me) it was very unwise to start messing with mempool policies, like with RBF, mempoolfullrbf. First-seen policy brought a fragile harmony and utility to Bitcoin, which we were lucky to have for as long as we could. The engineers intentionally broke this. Mempoofullrbf washes away the ability for users to express their intent on whether to pin or replace a transaction, and now Lightning has BOTH pinning and replacement problems. You could argue this was inevitable. The point here is that layers have mempool and miner problems. Core has a few choices here, as I see it: 1. They can try to revert mempoolfullrbf and re-establish first-seen policy. Hard to say whether this would work, or whether it would be enough... 2. They can create additional policies that are enforced by default that allow people to flag how they want their txn handled, as in, a "pin this" vs "replace this" aspect to every txn. This is probably the best option, as it allows miners to know what people want and give it to them. This is utility, thus incentive-compatible. 3. Remove all policy and let the market evolve to deal with the chaos. Which is similar to the next option: do nothing. 4. Do nothing and allow a fractured mempool environment to evolve where large businesses form private contracts with miners and pools to support their own unsupported policies, so they can provide better experiences to customers and users. 5. Invent some miracle magical crypto cure that I am not capable of imagining at this time. I disclaim some ignorance to details of how other mempool research might affect these options and problems, but I am skeptical the dynamics discussed here can be removed entirely. --John Carvalho CEO, Synonym.to --000000000000832e3006092798ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= Good morning,=C2=A0

All layers and technologies "on" Bitcoin will fai= l in situations where miners misbehave or the blocks & mempool remain c= onsistently, overly full. Consider this as a "law" of Bitcoin/blo= ckchains.=C2=A0

In hindsight (for you, not me) it was very unwise to start mess= ing with mempool policies, like with RBF, mempoolfullrbf. First-seen policy= brought a fragile harmony and utility to Bitcoin, which we were lucky to h= ave for as long as we could.=C2=A0

The engineers intentionally broke this. Memp= oofullrbf washes away the ability for users to express their intent on whet= her to pin or replace a transaction, and now Lightning has BOTH pinning and= replacement problems. You could argue this was inevitable. The point here = is that layers have mempool and miner problems.

Core has a few choices here, as= I see it:=C2=A0

1. They can try to revert mempoolfullrbf and re-establish firs= t-seen policy. Hard to say whether this would work, or whether it would be = enough...=C2=A0

2. They can create additional policies that are enforced by def= ault that allow people to flag how they want their txn handled, as in, a &q= uot;pin this" vs "replace this" aspect to every txn. This is= probably the best option, as it allows miners to know what people want and= give it to them. This is utility, thus incentive-compatible.=C2=A0

3. Remove a= ll policy and let the market evolve to deal with the chaos. Which is simila= r to the next option: do nothing.=C2=A0
4. Do nothing and allow a fractured mem= pool environment to evolve where large businesses form private contracts wi= th miners and pools to support their own unsupported policies, so they can = provide better experiences to customers and users.=C2=A0

5. Invent some miracle= magical crypto cure that I am not capable of imagining at this time.
=

I disclaim some ignor= ance to details of how other mempool research might affect these options an= d problems, but I am skeptical the dynamics discussed here can be removed e= ntirely.

--John Carvalho
CEO,=C2=A0Synonym.to
<= /div>
--000000000000832e3006092798ab--