Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A4420C000B for ; Tue, 1 Feb 2022 19:44:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 8444760B1B for ; Tue, 1 Feb 2022 19:44:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=voskuil-org.20210112.gappssmtp.com 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 eQfchWGTLlNR for ; Tue, 1 Feb 2022 19:44:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) by smtp3.osuosl.org (Postfix) with ESMTPS id 898AB60AC2 for ; Tue, 1 Feb 2022 19:44:41 +0000 (UTC) Received: by mail-pg1-x534.google.com with SMTP id s16so16216409pgs.13 for ; Tue, 01 Feb 2022 11:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=uV/BcAEaeaSyouTRGSgV4OTDPXKc/20UZCsk9B7AAxM=; b=inztvWmzT9bDFRqsJWM7cW+3kc9xqglBh3pSbEMnb9PvNL47UEF+L09VEmRoyL8siK /7ykZ1803YjmCDXiZLE48m28wWMPMpU7I5OTVE5LnY5tzhA4Uk+ZJWAJF2zmgBkCyF6S BktZnReboNZGmamU3cUny6Gt1Fo8PZLxFxXZNMFgPp8c+ExDzm/oUPvayKb9pjDuXLKZ xK66PR4eRp1K5lJlBJjnlVOB75XeVpjTo9FOd0TFNkVosREqbaIosLmpCdiAS2dMRklY rrKEEyYf1A8dgDkEPothDwkB0Ix3GWLY+XeoGy2RLV/dIdnfDzMvfo6OIZlk9YhnxluV OhvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=uV/BcAEaeaSyouTRGSgV4OTDPXKc/20UZCsk9B7AAxM=; b=PxXT/6Pi/T1evXwu0nU9LgrixWGJXL9maMCGQQdab7MFZLAUCzdbl5ie/WGmOZwGp6 err5vAjzJv3EDMs1I2tECz1OjKIXwxBrGTJgXXAzfzBH5DcwJRHJ1T0+/vO3ErRuWZeh rMoPqilVBqcURxsTJWdtRpxXTbG2R0yLaTHIbfQPMb1H8I6rPu8syOfMSQHrHC474Gdk 9RlkzjtnMDQoKlUsILIu4bSYm5Hj3uYI1AMBgzBY0SlwcjwbBX4QpbQHLlwQ4lkd2m5t fz30dABJwAesbLBQ0UvDZdmS3T2cOmioRd4fWayA5+vf4w90drcej/Vxp0B/ZZEzI8Fd 64iA== X-Gm-Message-State: AOAM533kQa2KdpoVHl1JG25GXxFpz8bD3H+nAgnkKKV52yn1z/ruh+RC Cqlkz73tyEPkptgVvncMIlIOn4Zvf6I0XA== X-Google-Smtp-Source: ABdhPJxT4mozbfuWO1cY80tCEyPTyP0CdlYflYP16uXLAupPmpJG5Zw+UO1Upjsqa8mkuSCblHhMzQ== X-Received: by 2002:aa7:9989:: with SMTP id k9mr26212587pfh.23.1643744680670; Tue, 01 Feb 2022 11:44:40 -0800 (PST) Received: from smtpclient.apple ([2600:380:7078:729e:a86e:e357:856:18b3]) by smtp.gmail.com with ESMTPSA id s19sm9255206pfu.34.2022.02.01.11.44.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 01 Feb 2022 11:44:39 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27 Content-Transfer-Encoding: 7bit From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Tue, 1 Feb 2022 11:44:37 -0800 Message-Id: References: In-Reply-To: To: Bram Cohen X-Mailer: iPhone Mail (19C63) Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Improving RBF policy 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: Tue, 01 Feb 2022 19:44:42 -0000 --Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Feb 1, 2022, at 00:32, Bram Cohen wrote: >=20 >> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote: >>=20 >>=20 >>>> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev wrote: >>> Is it still verboten to acknowledge that RBF is normal behavior and disa= llowing it is the feature, and that feature is mostly there to appease some p= eople's delusions that zeroconf is a thing? It seems a bit overdue to disres= pect the RBF flag in the direction of always assuming it's on. >> What flag? >=20 > The opt-in RBF flag in transactions. Was being facetious. The =E2=80=9Cdisrespect=E2=80=9D referred to above assu= mes respect that some implementations have never given. >>> There are two different common regimes which result in different incenti= vized behavior. One of them is that there's more than a block's backlog in t= he mempool in which case between two conflicting transactions the one with t= he higher fee rate should win. In the other case where there isn't a whole b= lock's worth of transactions the one with higher total value should win. >> These are not distinct scenarios. The rational choice is the highest fee b= lock-valid subgraph of the set of unconfirmed transactions, in both cases (w= ithin the limits of what is computationally feasible of course). >=20 > It's weird because which of two or more conflicting transactions should wi= n can oscillate back and forth depending on other stuff going on in the memp= ool. The assumption of RAM storage is an error and unrelated to network protocol.= There is nothing =E2=80=9Cgoing on=E2=80=9D in a set of unconfirmed valid t= ransactions. They are logically unchanging. > There's already a bit of that with child pays but this is stranger and has= more oddball edge cases about which transactions to route. There=E2=80=99s really no such thing. The p2p network is necessarily permiss= ionless. A person can route whatever he wants. Presumably people will not ge= nerally waste their own bandwidth by routing what they believe to be unconfi= rmable. And whatever they would retain themselves is their presumption of co= nfirmable. This decision of what to retain one=E2=80=99s self is just a graph traversal= to determine the most valuable subset - an optimizing CSP (though generally= suboptimal due to the time constraint). Short of DoS, the most profitable model is to retain *all* valid transaction= s. [Note that a spend conflict is not an invalidity. Two valid transactions c= an be confirmed in sibling branch blocks - both valid in some context.] So the only consideration is low cost storage fill. The fee is a proof of sp= end, which like proof of work (for headers/blocks), is the basis of DoS prot= ection (for unconfirmed transactions). The issue with two conflicting subgra= phs is that one or the other is ultimately unspendable. As such the fee on e= ach is non-cumulative and therefore only one (the highest) is providing DoS p= rotection. Any subsequent conflicting subgraph must pay not only for itself,= but for all preceding conflicting subgraphs. This pays for the storage, which is a trade accepted by the owner of the nod= e in order to have a preview of confirmable transactions. This supports both= mining generation of candidate blocks and rapid validation/confirmation of b= locks. It=E2=80=99s a rather straightforward system when considered in terms of how= it actually works (ie from a consensus standpoint). The only p2p issue is t= he need to package transactions for consideration as a set, as otherwise par= ents may be discarded before children can pay for them. Any set up to a full= block is entirely reasonable for consideration. e= --Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Feb 1, 2022, at 00:32, B= ram Cohen <bram@chia.net> wrote:

=
On Mon, Jan 31, 2022 at 4:08 PM Eric V= oskuil <eric@voskuil.org> wrot= e:


On Jan 31, 2022, at 15:15, Bram Coh= en via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Is it still verboten t= o acknowledge that RBF is normal behavior and disallowing it is the feature,= and that feature is mostly there to appease some people's delusions that ze= roconf is a thing? It seems a bit overdue to disrespect the RBF flag in the d= irection of always assuming it's on.
What flag?

The opt-in RB= F flag in transactions.

<= div>Was being facetious. The =E2=80=9Cdisrespect=E2=80=9D referred to above a= ssumes respect that some implementations have never given.
There are two different common regimes which resul= t in different incentivized behavior. One of them is that there's more than a= block's backlog in the mempool in which case between two conflicting transa= ctions the one with the higher fee rate should win. In the other case where t= here isn't a whole block's worth of transactions the one with higher total v= alue should win.
These are not dist= inct scenarios. The rational choice is the highest fee block-valid subgraph o= f the set of unconfirmed transactions, in both cases (within the limits of w= hat is computationally feasible of course).

It's weird because which of two or more conflicting transa= ctions should win can oscillate back and forth depending on other stuff goin= g on in the mempool.

The assumption of RAM storage is an error and unrelated to network protocol= . There is nothing =E2=80=9Cgoing on=E2=80=9D in a set of unconfirmed valid t= ransactions. They are logically unchanging.
There'= s already a bit of that with child pays but this is stranger and has more od= dball edge cases about which transactions to route.

There=E2=80=99s really no such thing. The p2p ne= twork is necessarily permissionless. A person can route whatever he wants. P= resumably people will not generally waste their own bandwidth by routing wha= t they believe to be unconfirmable. And whatever they would retain themselve= s is their presumption of confirmable.

This decisio= n of what to retain one=E2=80=99s self is just a graph traversal to determin= e the most valuable subset - an optimizing CSP (though generally suboptimal d= ue to the time constraint).

Short of DoS, the most p= rofitable model is to retain *all* valid transactions. [Note that a spend co= nflict is not an invalidity. Two valid transactions can be confirmed in sibl= ing branch blocks - both valid in some context.]

So= the only consideration is low cost storage fill. The fee is a proof of spen= d, which like proof of work (for headers/blocks), is the basis of DoS protec= tion (for unconfirmed transactions). The issue with two conflicting subgraph= s is that one or the other is ultimately unspendable. As such the fee on eac= h is non-cumulative and therefore only one (the highest) is providing DoS pr= otection. Any subsequent conflicting subgraph must pay not only for itself, b= ut for all preceding conflicting subgraphs.

This pa= ys for the storage, which is a trade accepted by the owner of the node in or= der to have a preview of confirmable transactions. This supports both mining= generation of candidate blocks and rapid validation/confirmation of blocks.=

It=E2=80=99s a rather straightforward system when c= onsidered in terms of how it actually works (ie from a consensus standpoint)= . The only p2p issue is the need to package transactions for consideration a= s a set, as otherwise parents may be discarded before children can pay for t= hem. Any set up to a full block is entirely reasonable for consideration.

e
= --Apple-Mail-D88799F9-5300-433F-A709-51F764E24D27--