Delivery-date: Sun, 14 Apr 2024 08:16:53 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rw1bA-0001qc-KU for bitcoindev@gnusha.org; Sun, 14 Apr 2024 08:16:53 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-dd1395fd1bfsf4216693276.0 for ; Sun, 14 Apr 2024 08:16:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713107806; x=1713712606; 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:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=96/MbssXwchVrzi+43l9jjNHgd9rYGuC4Bt0MOziXwE=; b=NPdkBu4apFXuOyUxFYooy4WAZPFxzd2B8/jKTLJIstT9W90ZoUNzRqEkXFERP2o9FI Cux+v+hkO1Ta+l47MuvwMCqEkPq4aGoc3z+p2agF96Z97g1TpABkIuXfYAxj3Ou3Y282 BNvVvtA0V80S5/frFT1vdrb32uTnyHV5IWoi2VqM2MW38ET2hgFEJao9+ftjhTXjnO1Z eLPLtdn/1UqzUE5jSoxNt8g1o2TmCks9AVvf2TstWcLUXJpQCmqUd5jzyNd66mdZSWfa 1ICP5Eo34/iMy3fx2lqTbZwiEzuD3BhTw1EM8gbxqIxh5LR9au03ruc8w1CZoQJ3Gj86 g9ag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713107806; x=1713712606; 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:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=96/MbssXwchVrzi+43l9jjNHgd9rYGuC4Bt0MOziXwE=; b=Q9CQOiF4nu150oCiqrj2eE/euPxlcgDygkKVh248f6YUEBQcxnrtzfZsceXcADw0GV 3dd5uxRjsKX2MfBGb+S21OVB4oJ9Rj/YAUg7slGnmD9oZKMikGyHDgqNKn+x79K5yKXK +Ju/K77UL4o+s+pJwYWZR71430bfyEITemJZzbYNp2dCfS27z2Theb6H4FFaU5bu6M6+ 8g7kVhQ1gVzbtw+lpK/11wiVZbS2WIzluku4NsDGsR6q28Oew6wUyx6CUNgqfCJoU8bH K+2b+aR50sAQLHQI1VJKdtn6jYFaq1IGQoLwvgmnSUWULTHb2tcGKc0MZeexSF+NbLKA YxwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713107806; x=1713712606; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=96/MbssXwchVrzi+43l9jjNHgd9rYGuC4Bt0MOziXwE=; b=QSuhMJgGaWpJ0wVSOGr6kOMvT9dPhlDRPyMaekYbxh7EOuWlQXdljO1+C7hc3g7QPr AAl4IDjUrvTZt6g5oxIdlFciKwqk7+WxBhwT5To4GLjFWlsEHJIlAnHWc+eCFEnXMBfz xv+VCweIr6a69RM4MPBfx9BoBTahQQ8XCrCcNL0XNArdZJCFhrzXQRbvwlyoLz63mj/n rITd28DZZW+W74l1ybYqYVc7N7wK+q33Yb26MUfWE3txWc74maQHf7+BdArw1UXXGU/Y OOCCXwAsWkvBWbSj5p+Sl1c62tOsjpFXBUMTca65+colAxv5R4BbJPZeTTjoqnUqXrxQ fypA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWM80eb2TZKnqKiaxY7lpouj0pzyaezTYlzxczoo9QE+tYgfmOxOEAeuwxvdReLBxjmMmSm/Cur6hwHSlMTvqmN8XQh91U= X-Gm-Message-State: AOJu0YyK5FImA16gbfkHlyDLzFKrcPy9Y0yO/HRA0kqeF5Okp12sgc5j 5h4tNKpAFX6zZ+4K2CMUQH9Jz5kXvHw/0B6symRnbpNMobNWdaY+ X-Google-Smtp-Source: AGHT+IE1UrbCXKwO0Xpdy3zczpFEdCoElDLa/eztzMzEQKcNyRLf3LuvGx+isyTt7b0C2dfNTYY/TQ== X-Received: by 2002:a25:9e0b:0:b0:de0:df15:b372 with SMTP id m11-20020a259e0b000000b00de0df15b372mr7080361ybq.63.1713107805920; Sun, 14 Apr 2024 08:16:45 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:d047:0:b0:dcb:bfe0:81b8 with SMTP id h68-20020a25d047000000b00dcbbfe081b8ls167552ybg.0.-pod-prod-09-us; Sun, 14 Apr 2024 08:16:44 -0700 (PDT) X-Received: by 2002:a05:690c:6e01:b0:61a:bda3:a78c with SMTP id jb1-20020a05690c6e0100b0061abda3a78cmr587393ywb.0.1713107804832; Sun, 14 Apr 2024 08:16:44 -0700 (PDT) Received: by 2002:a05:690c:fd6:b0:615:6ba5:7389 with SMTP id 00721157ae682-61841905692ms7b3; Sun, 14 Apr 2024 08:09:52 -0700 (PDT) X-Received: by 2002:a81:4ed8:0:b0:618:6480:a4c9 with SMTP id c207-20020a814ed8000000b006186480a4c9mr2004780ywb.9.1713107391479; Sun, 14 Apr 2024 08:09:51 -0700 (PDT) Date: Sun, 14 Apr 2024 08:09:51 -0700 (PDT) From: Bitcoin Error Log To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_427350_1896543598.1713107391072" X-Original-Sender: bitcoinerrorlog@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_427350_1896543598.1713107391072 Content-Type: multipart/alternative; boundary="----=_Part_427351_428296076.1713107391072" ------=_Part_427351_428296076.1713107391072 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable *Posted here:*=20 https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-0013= 8.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 policy= =20 with new transaction signaling mechanisms, including Do-Not-Replace (DNR)= =20 and Replace-by-Fee (RBF), to enhance control over transaction handling and= =20 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 transaction= =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 transaction= =20 may be replaced by another transaction with a higher fee. This mechanism= is=20 used to increase the likelihood of a transaction being picked up by mine= rs=20 in conditions of high network congestion, ensuring timely processing.=20 =20 Encoding The new flag signal, DNR, could be encoded similarly to existing RBF flags,= =20 with complementary mempool handling and conflict-resolution logic for=20 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 and= =20 handling. It is assumed that any local policy that enforces preferred=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 DNR = to=20 facilitate specific goals of transactors. The primary tradeoff is that= =20 these flags are suggestions and can be overridden by miners, which means= =20 they are not enforceable but serve as strong hints to improve transactio= n=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 here i= s=20 the potential fracturing of the mempool and private, mining-pool-centric= =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 base= d=20 on transaction fees or other out-of-band terms. This approach simplifies= =20 the network at the cost of significantly reducing the utility for users = 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 greater= =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 markets= =20 and network congestion patterns: -=20 =20 DNR potentially improves next-block fee competition and improves network= =20 throughput by providing clearer signals about transaction permanence and= =20 relevance. -=20 =20 RBF allows for dynamic fee adjustments that can enhance the certainty of= =20 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 pre= vent=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 that= =20 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 canceled= ,=20 ensuring employees receive the exact intended amounts. -=20 =20 Automated Payments for Services: -=20 =20 Example: Subscription services where automated payments are scheduled= =20 and should not be subject to change once initiated. -=20 =20 Usage: DNR can be applied to ensure that automated recurring payments= =20 are processed without the risk of being replaced, thus simplifying=20 financial planning and contract enforcement.=20 =20 Replace-by-Fee (RBF) Use Cases RBF is essential for transactions where timing and confirmation speed are= =20 more critical than the immediacy of finality. Here are applicable scenarios= : -=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 ti= mely=20 executions in response to market movements. -=20 =20 Emergency Service Payments: -=20 =20 Example: Payments for time-sensitive services, such as premium fast= =20 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 confirmation= =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 transaction= =20 fees to outpace other transactions in times of network congestion, se= curing=20 their winning bids. -=20 =20 Dynamic Fee Management for Wallets: -=20 =20 Example: Users sending non-urgent transactions who want to minimize= =20 fees but are willing to increase them if network conditions change. -=20 =20 Usage: RBF provides flexibility, allowing users to start with a lower= =20 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 for= =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 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/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.com. ------=_Part_427351_428296076.1713107391072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Posted here: https://github.com/BitcoinAndLightning= LayerSpecs/balls/blob/main/balls-00138.md

Full text here:

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

Abstract

T= his BIP introduces a utility-optimized strategy for Bitcoin mempool policy = with new transaction signaling mechanisms, including Do-Not-Replace (DNR) a= nd Replace-by-Fee (RBF), to enhance control over transaction handling and i= mprove the network's economic efficiency.

Motivation

= Specification Transaction Signals

  • Do-N= ot-Replace (DNR): Ensures transactions are not replaced onc= e 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 th= at 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 conditions of high network congestion, ensuring time= ly processing.

Encoding

The ne= w flag signal, DNR, could be encoded similarly to existing RBF flags, with = complementary mempool handling and conflict-resolution logic for default lo= cal enforcement.


Rationale

Addresses the need for predictab= le transaction handling while respecting the decentralized, incentive-drive= n 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 h= ardware limits is out of scope and remains separately necessary.

Strategic Options for Mempool Evolution=

There are three strategic options for evolving the Bitcoin m= empool management, where only one should be optimized:


    =

  • User-defined (The ideal, optimistic option): This approach= involves creating and default-obeying various transaction flags like RBF a= nd DNR to facilitate specific goals of transactors. The primary tradeoff is= that these flags are suggestions and can be overridden by miners, which me= ans they are not enforceable but serve as strong hints to improve transacti= on predictability and network efficiency.


  • Node-defined (The chaotic, centralizing option): This strategy would encourage third-party mempool providers to implem= ent their subjective preferences on transaction facilitation. The significa= nt tradeoff here is the potential fracturing of the mempool and private, mi= ning-pool-centric inclusion requirements, which could lead to increased cen= tralization and censorship.


    • =

  • Miner-defined (The rational, pessimistic option): The fina= l strategy involves removing all policies and flags, allowing miners to dec= ide based on transaction fees or other out-of-band terms. This approach sim= plifies the network at the cost of significantly reducing the utility for u= sers who may need special handling for their transactions.

Arguments for User-Definition=

Option 1 is favored here because it provides a balanced appr= oach that enhances user experience and network functionality without overly= complicating the Bitcoin protocol or risking centralization. By standardiz= ing flags that indicate user preferences, we can achieve greater harmony an= d utility within the Bitcoin network, supporting diverse user needs while m= aintaining decentralization.=C2=A0


More importantly= , we may be able to prevent mempool fragmentation and privatization to mine= rs and pools for direct transaction inclusion by intentionally supporting f= lags that better compete and match transaction use cases within the open me= mpool network instead of censoring them arbitrarily.


Economic Implications

T= he introduction of these signals could influence transaction fee markets an= d network congestion patterns:

  • DNR potentially improves next-block fee competi= tion and improves network throughput by providing clearer signals about tra= nsaction permanence and relevance.

  • RBF allows for dynamic fee adjustments tha= t can enhance the certainty of transaction confirmations during peak times,= benefiting users who need timely processing.

Do-Not-Replace (DNR) = Use Cases

DNR is valuable in scenarios where transacti= on finality is crucial upon submission, without the risk of later alteratio= ns due to increased fees. Here are some specific use cases:

  • Po= int-of-Sale Transactions:

    • Example: Retailers or service providers accepting Bi= tcoin in a face-to-face setting need transactions to be final immediately t= o prevent fraud.

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

  • Wage Payments:

      =

    • Example: Employer= s paying salaries in Bitcoin require certainty that the transaction amounts= 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 receive the exact intended amounts.<= /p>

  • Automated 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 that automated recurring payments are = processed without the risk of being replaced, thus simplifying financial pl= anning and contract enforcement.

Replace-by-= Fee (RBF) Use Cases

RBF is essential for transactions = where timing and confirmation speed are more critical than the immediacy of= finality. Here are applicable scenarios:

  • High-Frequency Trading:

    Example: Trader= s on cryptocurrency exchanges who need to rapidly adjust their positions ba= sed on market conditions.

  • Usage: RBF allows traders to increase the fee on a = transaction if it's not getting confirmed quickly enough, enabling them to = ensure timely executions in response to market movements.

  • Emergency= Service Payments:

    • Example: Payments for time-sensitive services, such as pre= mium fast delivery or emergency technical services.

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

  • Bidding in Auctions:

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

    • Usage: Auction participants can use RBF to adjust their transac= tion fees to outpace other transactions in times of network congestion, sec= uring their winning bids.

  • Dynamic Fee Management for Wallets:

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

    • Usage: RBF provides flex= ibility, allowing users to start with a lower fee and only increase it if t= he transaction confirmation is delayed, optimizing their transaction fee ex= penditures.

Adoption and Transition Strat= egy & Requirements

It is implicit, until now, that within th= is strategy is a requirement for Core and other implementations to abandon = strategies within Option 2, by specifically removing and rejecting policy t= ools like mempoolfullrbf, or other attempts to overrule, fi= lter, or otherwise filter and hamper the propagation of valid, non-destruct= ive transactions.


This proposal is presented to the= community for feedback, focusing on gathering input from wallet developers= , miners, and node operators to ensure broad support and understanding of t= he benefits 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 bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.com.=
------=_Part_427351_428296076.1713107391072-- ------=_Part_427350_1896543598.1713107391072--