Delivery-date: Tue, 16 Apr 2024 06:16:50 -0700 Received: from mail-yw1-f186.google.com ([209.85.128.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rwig5-0007r4-5Y for bitcoindev@gnusha.org; Tue, 16 Apr 2024 06:16:50 -0700 Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-618891b439esf71509297b3.3 for ; Tue, 16 Apr 2024 06:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713273403; x=1713878203; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=jF0fopBUVPcD1Z/b25/Gv1UDm8KfK+66LgGdwKwI5pY=; b=va1lxLUvvKtGQ2T/7UEOjqvlXvV/IOYYJj0YsiWO0V5KWdd4MLWS22wz/lUVdtSaUH Klhwqvqo0OJ0TwT+7aY09MebFAlAVY+fdnmf6+yM5A2NLWXE4g/U4nknnlBElg2EiA2Y +ncET1wGp8z+NjIR+XSbV7/yBDQn0PwcD3gCXrVYo+fqm4cBI0lB+GH3EjgI/aV6Hwul o5kjmV6ZnWay64o3qVNmXEo39mijkUZJpOWjTU32D6eJyGyRwaw3k2vXvNuHtR6nBfl/ /RGXebvpuJ0rRK1vA2TPcE5FaY1b3KS5pENTN6j64yIz9YSswx/HbnFqwrl7NwlBU6uH 1fMg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713273403; x=1713878203; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=jF0fopBUVPcD1Z/b25/Gv1UDm8KfK+66LgGdwKwI5pY=; b=UKnyE5WvW02Qr2Tn97XN/6ShtgeNAVEOZc0liG2Whp2wjMrR9T757xSpKZZx2BY4vm ihRZfx4eRXEheXHkPy6toWnYOWjr8iK9eJfKg5ZcKSDDXczcgFV4S9Bw0yiH+qczE407 CigaKlaTXZhTFe/pr144xwPeHF7sIRDMkXoV7KIyga6o1fpL5HW6s1vkoyXt+J5kpvDL xvgG4cd6baUouUTY0NaAQqBrhCvNIF4htIquk3gTupV6OeKZfvKZtJOKnk2871lEL2CR U8Lu1FZmxN8Zn1xDyq3OXxa4alCGYZQYj1LuFWOm2e5GmLKQjPCpFRj7IKozLJZGXOvs Gnmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713273403; x=1713878203; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=jF0fopBUVPcD1Z/b25/Gv1UDm8KfK+66LgGdwKwI5pY=; b=bpcCSuXu4Hvzmymjl+qJmcuK8ZlLNK7guORA68gij7NOlLgSJ0gVk3udzP8ZLTnA5O AQRKe3Vac/VD8MVh9yR/1+M+Gqoqs1MBfJ5Jjm286Lf/knR9KRgKdN8DfiDaH/lZMqOM dNqqJTpMyfZbpXcBAtg7i6UhSjdeOEKp94dDhAyLhio1bR6NgMepR5VMt1cZsWns4FDm O+VHFU0StIcM64XKlfnfAceWVon37mzV4zTUxF+Oq/MuiuxI2IyztAdJfK4BYSVWDxGp TYURb9V9FytpodbaCQ37G5RDYmCSj9q7UvKdptDzKZTDT2jsgvZKH1rHEJAYKbH41+7e CX8g== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW1EyVoUltvC0Eoa17oDQfFscWdvfrysx4DZ/80V8QecOhR1pobevHTGIE8J2DMbN9UQ4EG/cn63f6s+kjxsA1KUZAxouE= X-Gm-Message-State: AOJu0Ywnixp+FjHz4UjtmfHXg4WAPomYwdmNrmAt62a/mUNU/vVYiShO OlQH5Q7PlOt7FmGx4ODCQd4CoXHYUCyW7FlbaUy9BefY8jAOSz6t X-Google-Smtp-Source: AGHT+IGp8v1GhZ0AErbNtcDuZBMrGEVd5HdLAlht4/JsFKR4d//S02sKfFrrT3tB7h8ZzErcdh35JA== X-Received: by 2002:a25:dc92:0:b0:dc2:2041:fc49 with SMTP id y140-20020a25dc92000000b00dc22041fc49mr12552803ybe.5.1713273401107; Tue, 16 Apr 2024 06:16:41 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:3156:0:b0:dcc:4059:deae with SMTP id x83-20020a253156000000b00dcc4059deaels96246ybx.2.-pod-prod-01-us; Tue, 16 Apr 2024 06:16:39 -0700 (PDT) X-Received: by 2002:a81:5253:0:b0:61a:c438:6bc4 with SMTP id g80-20020a815253000000b0061ac4386bc4mr1431116ywb.3.1713273399715; Tue, 16 Apr 2024 06:16:39 -0700 (PDT) Received: by 2002:a05:690c:86:b0:611:2a20:d0cc with SMTP id 00721157ae682-618419219e7ms7b3; Mon, 15 Apr 2024 19:01:05 -0700 (PDT) X-Received: by 2002:a05:6902:1502:b0:dc7:49a9:6666 with SMTP id q2-20020a056902150200b00dc749a96666mr3872138ybu.3.1713232864517; Mon, 15 Apr 2024 19:01:04 -0700 (PDT) Date: Mon, 15 Apr 2024 19:01:04 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_20078_1244308087.1713232864136" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_20078_1244308087.1713232864136 Content-Type: multipart/alternative; boundary="----=_Part_20079_952834049.1713232864136" ------=_Part_20079_952834049.1713232864136 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Few years ago, while discussing mitigations for mempool pinning at the=20 commitment and second-stage transaction-level, we went to consider=20 deploying new transaction-relay infrastructure directly connecting=20 Lightning nodes and miners mempools over LN gossips [0]. This idea was=20 disregarded, as you're introducing miners / Lightning nodes incentives=20 misalignment (quid if your LSP who is your channel counterparty drops your= =20 gossip with a HTLC-preimage transaction within). Additionally, mempool=20 partitioning in the miners mempools can be always tried by your=20 counterparty with another commitment transaction. However, one should note that since then privileged transaction-relay API= =20 for Bitcoin applications with time-sensitive traffic requirements have=20 become more frequent with the "so-branded" transaction accelerators, where= =20 the inclusion of a boosted transaction is only relying on the reputation of= =20 mining pools. With seeing more private / staged transaction-relay API or=20 protocols, there is indeed a concern of loosing the notion of a common=20 blockspace market feerate that can be estimated by all full-nodes operators= . On delegating policy-choice to the transaction-issuer themselves, I did=20 myself an experiment "transaction-issuer selected policy limits" (e.g=20 selecting the max standard tx weight that is accepted for a transaction=20 version) [1]. The signaling opt-in mechanism was hacked in the nSequence=20 field, which I found a bit gross and they are issues with this approach. Finally, I would observe that still today's mainstream Internet packets=20 (IPv4 - RFC 794) fields have a defined meaning (e.g type of service with=20 priorities) even if they're not often respected by ISPs due to local BGP=20 routing policy. In practice, I think any user-defined transaction flags=20 proposal like that relies on respecting the finality or dynamic transaction= =20 size limits shall come with a security model relying on miners economic=20 incentives to have the flag semantics validated. =20 Best, Antoine [0] https://github.com/lightning/bolts/issues/783 [1] https://github.com/bitcoin/bitcoin/issues/29454 Le lundi 15 avril 2024 =C3=A0 23:00:59 UTC+1, Keagan McClelland a =C3=A9cri= t : > Gaming this out a few iterations, I'm pretty sure a widely deployed DNR= =20 > policy will result in a proliferation of direct-to-miner transaction=20 > submissions and will result in less network-wide visibility of the=20 > transaction set that is staged for confirmation. At first it seems=20 > reasonable to assume that users can help block the propagation of a=20 > hypothetical DNR replacement, but the miners ultimately are unlikely to= =20 > make this choice in practice. The only argument you can fall back on here= =20 > is that Miners openly defying user desires will ultimately result in=20 > stagnant or negative BTC growth which is bad for their long term, but I= =20 > think that argument is pretty weak in this context. > > Relying on DNR type behavior in applications will definitely be insecure,= =20 > but I think fighting to do it anyway has even more distortion effects tha= t=20 > we are unlikely to want in the long run. > > Keags > > On Sun, Apr 14, 2024 at 9:16=E2=80=AFAM Bitcoin Error Log =20 > wrote: > >> *Posted here:*=20 >> https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-0= 0138.md >> >> *Full text here:* >> >> BIP: XXXX >> Title: User-Defined Transaction Flags Policy & Strategy >> Author: John Carvalho >> Type: Standards Track >> Created: Apr 15, 2024 >> Status: Draft=20 >> Abstract >> >> This BIP introduces a utility-optimized strategy for Bitcoin mempool=20 >> policy with new transaction signaling mechanisms, including Do-Not-Repla= ce=20 >> (DNR) and Replace-by-Fee (RBF), to enhance control over transaction=20 >> handling and improve the network's economic efficiency.=20 >> Motivation >> >> Enhancing user autonomy and network efficiency through precise,=20 >> user-defined transaction signals that integrate seamlessly with Bitcoin'= s=20 >> decentralized nature and existing economic models.=20 >> Specification Transaction Signals >> =20 >> -=20 >> =20 >> Do-Not-Replace (DNR): Ensures transactions are not replaced once=20 >> broadcast. This flag is encoded using a specific bit in the transacti= on=E2=80=99s=20 >> version field, similar to RBF, but with inverse logic. >> -=20 >> =20 >> Replace-by-Fee (RBF): Allows the sender to signal that the=20 >> transaction may be replaced by another transaction with a higher fee.= This=20 >> mechanism is used to increase the likelihood of a transaction being p= icked=20 >> up by miners in conditions of high network congestion, ensuring timel= y=20 >> processing.=20 >> =20 >> Encoding >> >> The new flag signal, DNR, could be encoded similarly to existing RBF=20 >> flags, with complementary mempool handling and conflict-resolution logic= =20 >> for default local enforcement. >> >> >> Rationale >> >> Addresses the need for predictable transaction handling while respecting= =20 >> the decentralized, incentive-driven nature of network participants. >> >> Note: This proposal only discusses subjective, arbitrary mempool policy= =20 >> and handling. It is assumed that any local policy that enforces preferre= d=20 >> hardware limits is out of scope and remains separately necessary.=20 >> Strategic Options for Mempool Evolution >> >> There are three strategic options for evolving the Bitcoin mempool=20 >> management, where only one should be optimized: >> >> >> -=20 >> =20 >> User-defined (The ideal, optimistic option): This approach involves= =20 >> creating and default-obeying various transaction flags like RBF and D= NR to=20 >> facilitate specific goals of transactors. The primary tradeoff is tha= t=20 >> these flags are suggestions and can be overridden by miners, which me= ans=20 >> they are not enforceable but serve as strong hints to improve transac= tion=20 >> predictability and network efficiency. >> -=20 >> -=20 >> =20 >> Node-defined (The chaotic, centralizing option): This strategy would= =20 >> encourage third-party mempool providers to implement their subjective= =20 >> preferences on transaction facilitation. The significant tradeoff her= e is=20 >> the potential fracturing of the mempool and private, mining-pool-cent= ric=20 >> inclusion requirements, which could lead to increased centralization = and=20 >> censorship. >> -=20 >> -=20 >> =20 >> Miner-defined (The rational, pessimistic option): The final strategy= =20 >> involves removing all policies and flags, allowing miners to decide b= ased=20 >> on transaction fees or other out-of-band terms. This approach simplif= ies=20 >> the network at the cost of significantly reducing the utility for use= rs who=20 >> may need special handling for their transactions.=20 >> =20 >> Arguments for User-Definition >> >> Option 1 is favored here because it provides a balanced approach that=20 >> enhances user experience and network functionality without overly=20 >> complicating the Bitcoin protocol or risking centralization. By=20 >> standardizing flags that indicate user preferences, we can achieve great= er=20 >> harmony and utility within the Bitcoin network, supporting diverse user= =20 >> needs while maintaining decentralization.=20 >> >> More importantly, we may be able to prevent mempool fragmentation and=20 >> privatization to miners and pools for direct transaction inclusion by=20 >> intentionally supporting flags that better compete and match transaction= =20 >> use cases within the open mempool network instead of censoring them=20 >> arbitrarily. >> >> >> Economic Implications >> >> The introduction of these signals could influence transaction fee market= s=20 >> and network congestion patterns: >> >> -=20 >> =20 >> DNR potentially improves next-block fee competition and improves=20 >> network throughput by providing clearer signals about transaction=20 >> permanence and relevance. >> -=20 >> =20 >> RBF allows for dynamic fee adjustments that can enhance the certainty= =20 >> of transaction confirmations during peak times, benefiting users who = need=20 >> timely processing.=20 >> =20 >> Do-Not-Replace (DNR) Use Cases >> >> DNR is valuable in scenarios where transaction finality is crucial upon= =20 >> submission, without the risk of later alterations due to increased fees.= =20 >> Here are some specific use cases:=20 >> >> -=20 >> =20 >> Point-of-Sale Transactions: >> -=20 >> =20 >> Example: Retailers or service providers accepting Bitcoin in a=20 >> face-to-face setting need transactions to be final immediately to = prevent=20 >> fraud. >> -=20 >> =20 >> Usage: By using the DNR flag, merchants can ensure that once a=20 >> transaction is broadcast, it cannot be replaced, thereby securing = the=20 >> payment process at the point of sale. >> -=20 >> =20 >> Wage Payments: >> -=20 >> =20 >> Example: Employers paying salaries in Bitcoin require certainty=20 >> that the transaction amounts cannot be altered once sent. >> -=20 >> =20 >> Usage: DNR provides employers the confidence to execute payroll=20 >> transactions knowing that the payments cannot be replaced or cance= led,=20 >> ensuring employees receive the exact intended amounts. >> -=20 >> =20 >> Automated Payments for Services: >> -=20 >> =20 >> Example: Subscription services where automated payments are=20 >> scheduled and should not be subject to change once initiated. >> -=20 >> =20 >> Usage: DNR can be applied to ensure that automated recurring=20 >> payments are processed without the risk of being replaced, thus si= mplifying=20 >> financial planning and contract enforcement.=20 >> =20 >> Replace-by-Fee (RBF) Use Cases >> >> RBF is essential for transactions where timing and confirmation speed ar= e=20 >> more critical than the immediacy of finality. Here are applicable scenar= ios: >> >> -=20 >> =20 >> High-Frequency Trading: >> -=20 >> =20 >> Example: Traders on cryptocurrency exchanges who need to rapidly= =20 >> adjust their positions based on market conditions. >> -=20 >> =20 >> Usage: RBF allows traders to increase the fee on a transaction if= =20 >> it's not getting confirmed quickly enough, enabling them to ensure= timely=20 >> executions in response to market movements. >> -=20 >> =20 >> Emergency Service Payments: >> -=20 >> =20 >> Example: Payments for time-sensitive services, such as premium=20 >> fast delivery or emergency technical services. >> -=20 >> =20 >> Usage: When quick service delivery is critical, RBF enables the=20 >> sender to increase the transaction fee to speed up the confirmatio= n=20 >> process, ensuring that the transaction is prioritized by miners. >> -=20 >> =20 >> Bidding in Auctions: >> -=20 >> =20 >> Example: Participants in online auctions who need to ensure their= =20 >> payments go through before the auction closes. >> -=20 >> =20 >> Usage: Auction participants can use RBF to adjust their=20 >> transaction fees to outpace other transactions in times of network= =20 >> congestion, securing their winning bids. >> -=20 >> =20 >> Dynamic Fee Management for Wallets: >> -=20 >> =20 >> Example: Users sending non-urgent transactions who want to=20 >> minimize fees but are willing to increase them if network conditio= ns change. >> -=20 >> =20 >> Usage: RBF provides flexibility, allowing users to start with a=20 >> lower fee and only increase it if the transaction confirmation is = delayed,=20 >> optimizing their transaction fee expenditures.=20 >> =20 >> Adoption and Transition Strategy & Requirements >> >> It is implicit, until now, that within this strategy is a requirement fo= r=20 >> Core and other implementations to abandon strategies within Option 2, by= =20 >> specifically removing and rejecting policy tools like mempoolfullrbf, or= =20 >> other attempts to overrule, filter, or otherwise filter and hamper the= =20 >> propagation of valid, non-destructive transactions. >> >> This proposal is presented to the community for feedback, focusing on=20 >> gathering input from wallet developers, miners, and node operators to=20 >> ensure broad support and understanding of the benefits and implications = of=20 >> these new transaction signals. >> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion on the web visit=20 >> https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcf= d7ab41106n%40googlegroups.com=20 >> >> . >> > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/acf8b209-0c7c-4885-8fcc-8f79c2c4d045n%40googlegroups.com. ------=_Part_20079_952834049.1713232864136 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John,

Few years ago, while discussing mitigations f= or mempool pinning at the commitment and second-stage transaction-level, we= went to consider deploying new transaction-relay infrastructure directly c= onnecting Lightning nodes and miners mempools over LN gossips [0]. This ide= a was disregarded, as you're introducing miners / Lightning nodes incentive= s misalignment (quid if your LSP who is your channel counterparty drops you= r gossip with a HTLC-preimage transaction within). Additionally, mempool pa= rtitioning in the miners mempools can be always tried by your counterparty = with another commitment transaction.

However, on= e should note that since then privileged transaction-relay API for Bitcoin = applications with time-sensitive traffic requirements have become more freq= uent with the "so-branded" transaction accelerators, where the inclusion of= a boosted transaction is only relying on the reputation of mining pools. W= ith seeing more private / staged transaction-relay API or protocols, there = is indeed a concern of loosing the notion of a common blockspace market fee= rate that can be estimated by all full-nodes operators.

On delegating policy-choice to the transaction-issuer themselves, I= did myself an experiment "transaction-issuer selected policy limits" (e.g = selecting the max standard tx weight that is accepted for a transaction ver= sion) [1]. The signaling opt-in mechanism was hacked in the nSequence field= , which I found a bit gross and they are issues with this approach.

Finally, I would observe that still today's mainstream = Internet packets (IPv4 - RFC 794) fields have a defined meaning (e.g type o= f service with priorities) even if they're not often respected by ISPs due = to local BGP routing policy. In practice, I think any user-defined transact= ion flags proposal like that relies on respecting the finality or dynamic t= ransaction size limits shall come with a security model relying on miners e= conomic incentives to have the flag semantics validated.
=C2=A0
Best,
Antoine

[0]=C2=A0https:= //github.com/lightning/bolts/issues/783
[1]=C2=A0https://github.c= om/bitcoin/bitcoin/issues/29454

Le lundi 15 avril 2024 =C3=A0 23:00= :59 UTC+1, Keagan McClelland a =C3=A9crit=C2=A0:
Gaming this out a few = iterations, I'm pretty sure a widely deployed DNR policy will result in= a proliferation of direct-to-miner transaction submissions and will result= in less network-wide visibility of the transaction set that is staged for = confirmation. At first it seems reasonable to assume that users can help bl= ock the propagation of a hypothetical DNR replacement, but the miners ultim= ately are unlikely to make this choice in practice. The only argument you c= an fall back on here is that Miners openly defying user desires will ultima= tely result in stagnant or negative BTC growth which is bad for their long = term, but I think that argument is pretty weak in this context.

Relying on DNR type behavior in applications will definitely be ins= ecure, but I think fighting to do it anyway has even more distortion effect= s that we are unlikely to want in the long run.

Ke= ags

On Sun, Apr 14, 2024 at 9:16=E2= =80=AFAM Bitcoin Error Log <b= itcoin...@gmail.com> wrote:
Posted here: https://github.com= /BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00138.md
<= br>
Full text here:

BIP: XXXX=
<= /span>Title: User-Defined Transaction Flags Policy & Strategy
Author:= John Carvalho
Type: Standards Track
Created: Apr 15, 2024<= br>Status: Draft

Abstract

This BIP introduces a utility= -optimized strategy for Bitcoin mempool policy with new transaction signali= ng mechanisms, including Do-Not-Replace (DNR) and Replace-by-Fee (RBF), to = enhance control over transaction handling and improve the network's eco= nomic efficiency.

Motivation

Enhancing user autonomy a= nd network efficiency through precise, user-defined transaction signals tha= t integrate seamlessly with Bitcoin's decentralized nature and existing= economic models.

Specification Transaction Signals

  • Do-Not-Replace (D= NR): Ensures transactions are not replaced o= nce broadcast. This flag is encoded using a specific bit in the transaction= =E2=80=99s version field, similar to RBF, but with inverse logic.

  • Replace-by-Fee (RBF): Allows the sender to signal that the transaction may be= replaced by another transaction with a higher fee. This mechanism is used = to increase the likelihood of a transaction being picked up by miners in co= nditions of high network congestion, ensuring timely processing.

Encoding

The new flag signal, DNR, could = be encoded similarly to existing RBF flags, with complementary mempool hand= ling and conflict-resolution logic for default local enforcement.


=

Rationale

Addresses the need for predi= ctable transaction handling while respecting the decentralized, incentive-d= riven nature of network participants.


Note: This= proposal only discusses subjective, arbitrary mempool policy and handling.= It is assumed that any local policy that enforces preferred hardware limit= s is out of scope and remains separately necessary.

Strategic Options for Mempool Evolution

There are t= hree strategic options for evolving the Bitcoin mempool management, where o= nly one should be optimized:


  • User-defined (The ideal, o= ptimistic option): This approach involves cr= eating and default-obeying various transaction flags like RBF and DNR to fa= cilitate specific goals of transactors. The primary tradeoff is that these = flags are suggestions and can be overridden by miners, which means they are= not enforceable but serve as strong hints to improve transaction predictab= ility and network efficiency.


  • Node-defined (T= he chaotic, centralizing option): This strat= egy would encourage third-party mempool providers to implement their subjec= tive preferences on transaction facilitation. The significant tradeoff here= is the potential fracturing of the mempool and private, mining-pool-centri= c inclusion requirements, which could lead to increased centralization and = censorship.

  • <= br>

  • Miner-defined (The rational, pess= imistic option): The final strategy involves= removing all policies and flags, allowing miners to decide based on transa= ction fees or other out-of-band terms. This approach simplifies the network= at the cost of significantly reducing the utility for users who may need s= pecial handling for their transactions.

Arguments for User-Definition

Option 1 is= favored here because it provides a balanced approach that enhances user ex= perience and network functionality without overly complicating the Bitcoin = protocol or risking centralization. By standardizing flags that indicate us= er preferences, we can achieve greater harmony and utility within the Bitco= in network, supporting diverse user needs while maintaining decentralizatio= n.=C2=A0


More importantly, we may be able to prevent mempool fragm= entation and privatization to miners and pools for direct transaction inclu= sion by intentionally supporting flags that better compete and match transa= ction use cases within the open mempool network instead of censoring them a= rbitrarily.


Economic Implications

The intr= oduction of these signals could influence transaction fee markets and netwo= rk congestion patterns:

  • DNR potentially improves next-block fee competiti= on and improves network throughput by providing clearer signals about trans= action permanence and relevance.

  • RBF allow= s for dynamic fee adjustments that can enhance the certainty of transaction= confirmations during peak times, benefiting users who need timely processi= ng.

Do-Not-Replace (DNR) Use Cases

DNR is valuable in scenarios where transaction finality is crucial upon = submission, without the risk of later alterations due to increased fees. He= re are some specific use cases:

  • Point-of-Sale Transactions:

    • Example: Retailers or service providers accept= ing Bitcoin in a face-to-face setting need transactions to be final immedia= tely to prevent fraud.

    • Usage: By using the= DNR flag, merchants can ensure that once a transaction is broadcast, it ca= nnot be replaced, thereby securing the payment process at the point of sale= .

  • <= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" r= ole=3D"presentation">Wage Payments:

    • Example: Employ= ers paying salaries in Bitcoin require certainty that the transaction amoun= ts cannot be altered once sent.

    • Usage: DNR= provides employers the confidence to execute payroll transactions knowing = that the payments cannot be replaced or canceled, ensuring employees receiv= e the exact intended amounts.

  • Au= tomated Payments for Services:

    • Example: Subscription services where automat= ed payments are scheduled and should not be subject to change once initiate= d.

    • Usage: DNR can be applied to ensure tha= t automated recurring payments are processed without the risk of being repl= aced, thus simplifying financial planning and contract enforcement.

Replace-by-Fee (RBF) Use C= ases

RBF is essential for transactions where timing and confirmatio= n speed are more critical than the immediacy of finality. Here are applicab= le scenarios:

  • High-Frequency Trading:

    • Example: Traders on cryptocurrenc= y exchanges who need to rapidly adjust their positions based on market cond= itions.

    • Usage: RBF allows traders to incr= ease the fee on a transaction if it's not getting confirmed quickly eno= ugh, enabling them to ensure timely executions in response to market moveme= nts.

  • Emergency Service Payments:=

    • Example: Payments for time-sensitive services, such as premium fast delive= ry or emergency technical services.

    • Usage:= When quick service delivery is critical, RBF enables the sender to increas= e the transaction fee to speed up the confirmation process, ensuring that t= he transaction is prioritized by miners.

  • Bidding in Auctions:

    • Example: Participants in online auctions = who need to ensure their payments go through before the auction closes.

    • Usage: Auction participants can use RBF to ad= just their transaction fees to outpace other transactions in times of netwo= rk congestion, securing their winning bids.

  • Dynamic Fee Management for Wallets:

    • Example: Users sending non= -urgent transactions who want to minimize fees but are willing to increase = them if network conditions change.

    • Usage: = RBF provides flexibility, allowing users to start with a lower fee and only= increase it if the transaction confirmation is delayed, optimizing their t= ransaction fee expenditures.

Adoption and Transition Strategy & Req= uirements

It is implicit, until now,= that within this strategy is a requirement for Core and other implementati= ons to abandon strategies within Option 2, by specifically removing and rej= ecting policy tools like m= empoolfullrbf, or other attempts to overru= le, filter, or otherwise filter and hamper the propagation of valid, non-de= structive transactions.


This proposal is presented to the communit= y for feedback, focusing on gathering input from wallet developers, miners,= and node operators to ensure broad support and understanding of the benefi= ts and implications of these new transaction signals.


--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+...@googlegro= ups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-= bcfd7ab41106n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/acf8b209-0c7c-4885-8fcc-8f79c2c4d045n%40googlegroups.com.=
------=_Part_20079_952834049.1713232864136-- ------=_Part_20078_1244308087.1713232864136--