From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 15 Apr 2024 11:01:23 -0700 Received: from mail-oi1-f183.google.com ([209.85.167.183]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rwQdu-00042I-74 for bitcoindev@gnusha.org; Mon, 15 Apr 2024 11:01:23 -0700 Received: by mail-oi1-f183.google.com with SMTP id 5614622812f47-3c70a58a729sf1526089b6e.0 for ; Mon, 15 Apr 2024 11:01:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1713204076; cv=pass; d=google.com; s=arc-20160816; b=SQK5AdJ1zhWUqGDA73DQuKO4/eeLHds1+ABO/UdE4EhaVdn7ge+FE37Pe7GxLa+y1q t+Ihd0AFY3myXkZQ6MWRdD6ljAXp/TZVzTRK3hHHaRZXYLI0ZYjGltAmp0w4cUAneb5D x2ofT78x8MDCUVa8gfPfLaoknfPUYFKYmLtZEPP3bYoOwyzvAIIQ0gTDArH+eSR6t4rE 0srxUxAXOnlDhteWFYOc0kNEwBa8d0kCUJzNh59jg3lOlhd39m6I3dopUlf7V2mouVyS MViHEl3dlJlSIqq2uwHcZOAk6EKhTxpsM1wVkmMotBBWMt6juh0K3oGEn7rOt87zE5Z1 Ts5g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=WuzMpJhKgwSBx2fWQRSEKG9iH0CUPI/7YC8TkmYb4E8=; fh=QYW2GxL1Oyz2Hcw/BbIc7lHvaHa2uIRxWUvbkhNZepY=; b=gXdWmWHpMruWvSLxZqHenv1hJicUKH5g7k5DCcBlJbSxbCEKSbUziezOVjVc7igCUm B8Oi6a2XgEUShhvZI2O5eprsUf4JvwwVCxvqJhXczNSI5dqDKOHDc/eu4u5p2DQ5o152 J2Pf5c+BPIzQxxH/WNC5egr8d5iJNKj+W2Zs1yN+jJ465nSSrkkfdhwzlDuIjDgOwQ4k cX5Ndkn1L9uGzdmZ/A60d5g/K2inlKqELdTZFNFe4IjQNCJ1duWmzZ4lno1AIdyYq6V9 j6LwP5xHwYjT1di2jwB9xiWe9A1tG9u+rUsSCfh8RrypIrnEkJFP31w60OJ78BLY5yjH Ih+w==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=cU0JiLPG; spf=pass (google.com: domain of eiter.isaac@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=eiter.isaac@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1713204076; x=1713808876; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=WuzMpJhKgwSBx2fWQRSEKG9iH0CUPI/7YC8TkmYb4E8=; b=OWEySJdOtSeLC8ck4r9pTY2cH2waMrD0lMWlyCdAqTHDV/hiXSIfmcic2fF8Bwc6Bg EsvSkVESx/DM0qOSxeGhuLDhmX7QCuy9M4Ljmapij+3vVOtP+rv3aCq8oMb40tZCIaSJ 40GfxkQf3FLvEPlr91TkNUyrsOSRNP9z7whqN93TrBm9ObrXCyZpDXoI6CYRkNIPPTpY IPcBf7BQlOYmrY4lvUqvUw+GAycDTdR3Jaf+V5WecbJECCotHjTOLq5SofSQ+Y3+uNPo w078FOS14YAMFycZwrsSF/if3ECH4lAc4QmjzkW2m+If/G2N99fzm/zEmD/ujKF09oMd xWfA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713204076; x=1713808876; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WuzMpJhKgwSBx2fWQRSEKG9iH0CUPI/7YC8TkmYb4E8=; b=BeNvcxymJlSw5/ihbFvHixppuvxUjRyZjZu3AM7RUTTso4+V0MHlf4TWTeFluMyML3 XFdQ8CVNG/l0Tr1gIa+8LjeG8mqKBINMLnJ3e/pb0ucTPrBV0Azyu0FgsFmDfiLBxPO/ JKEvtVt/MdBydL5IspsaK1btQ7dkmNhuyJkNAI+lcSUtLmcAbPfp25LLVizX3bWJVkrN Qexe3Ma4bQ2NGz0mZdPHG6unViV4vFxvhPb6jtih06x4CZs1e8/3Xw9kwY9FJO1Xihin U1N4D+gh8gAf/9nP7qOU7vhRaC/OpTKyL1bH7V0Y3kyOmCvGZHlGSDtFq9cJYs5MQfT4 hl0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713204076; x=1713808876; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=WuzMpJhKgwSBx2fWQRSEKG9iH0CUPI/7YC8TkmYb4E8=; b=p3VjOi2Q+UrOuAzytFTdk9eGJ7d//dH4GWCZDo2mVQc4MTlq7R0N++zRV3LUvfWJUc zXuejnkEX59wJuXyeVMzDM12meiZqnMxqROnxpP2hIOHC4RSWbS61eAENjdWeYLIvPYu gOZChi+mtEe1rlGmXGWHVPHGXb3fAlVvlUbi/rXTBMNIbD33y2pnyJObdICVgprSgZQE h6BQvez8YuJyGVKJf1VTjvN1YmsbxE1Ai9HbmLT0ckF+ED89+t4s2jio8L+5V7fQUxIl AW4zeaV+eTWNC9BjcATE+wsNqvlJLzQx28Kzb1zdzEOTm4LzxYV/Y6zu9MC7ZZUPx4u5 vLHA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWyBqjxGSfBEbKCQV/6qgFJqVqyOpwDUSTTOb5Px5P+nQlFNiVjnWPoC1mD8A1gMx7D5iDzAEtrwjNc2T7FX3ZO0zNcyHg= X-Gm-Message-State: AOJu0YyoKyjsLkWcm37/vM3tSdHWAFnfW1g6uNnpDSXmgcjgEEq1f0vP Ff7aJ9jDziL6zlXJMCOB+0Mc9EX34xRFWlrbL00RJ5PKqwdTTgFN X-Google-Smtp-Source: AGHT+IE/RqqMyJGwfqQZxhe5LYqgJxpCFZ2yBgNTSpCWhq8mhoOslVJt9qy2N+JWGDeMYP2b5CQREA== X-Received: by 2002:a05:6808:1995:b0:3c7:ec8:8ef7 with SMTP id bj21-20020a056808199500b003c70ec88ef7mr5413382oib.11.1713204074431; Mon, 15 Apr 2024 11:01:14 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ac8:7f4c:0:b0:436:7115:70c1 with SMTP id g12-20020ac87f4c000000b00436711570c1ls4621099qtk.1.-pod-prod-08-us; Mon, 15 Apr 2024 11:01:13 -0700 (PDT) X-Received: by 2002:a05:620a:c42:b0:78e:e47b:d211 with SMTP id u2-20020a05620a0c4200b0078ee47bd211mr63006qki.11.1713204073309; Mon, 15 Apr 2024 11:01:13 -0700 (PDT) Received: by 2002:a05:620a:40c3:b0:78e:e8ae:bf9e with SMTP id af79cd13be357-78ee8aec701ms85a; Sun, 14 Apr 2024 13:12:28 -0700 (PDT) X-Received: by 2002:a2e:2c12:0:b0:2d8:6e04:47db with SMTP id s18-20020a2e2c12000000b002d86e0447dbmr4150776ljs.42.1713125545822; Sun, 14 Apr 2024 13:12:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1713125545; cv=none; d=google.com; s=arc-20160816; b=tSj0RZkbnVv+0NqY0nsRxlmmOAK9VKkGpxQVmKYE4uAYhGD9qnu3ZXkjUrQAfJC7vQ ta+5cPzrnHcdLRmQNTlq0l/aR04nqppmjkwJiu7mG8+uiEmc9ENJqNQWt6UorgDh7Jrb 5OJjEgk4Aco8bxfIEApVRcfcwgGj/l2DYAMMhb7PJb9M2Pv2AfsUAcOq2TQfqF/yNdiG EjKgnGfyBOgYvMV1zCN4cVO4GKUrafHWvGlRdGzQcUOvToM3xWxyuQHrIlf8vnSAtpbG UXGv/+59WW0Pcrtc1cWfyX3OP6tyQaLKzvShBdmStwLNzrmlFCuO/N8Lk0FsymKeRMjE fdVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=rU8hAhqvkfI9c4Q35tDwc8zoy5399GieZkzsYyh4R1U=; fh=roize3/Nsv4Auw8Ccya15pk+/cIq2QN3L3Gj0Di505I=; b=PEP+mXyyFRWjC73uE7JWSICOt9nrmmdYobZQTkhgELW60IQeGKQSunkEcI9RnH/kn1 PbNd2+NmHmaUXK642TMiDjis46sCLyc16/ohMOIVraxpHhU014hciMf3yJAfVhTrbBak AW0h9lUQ8JVem3eXTo6vMG7FjIpxHsm9a0DRAFgGgv3ZpeZjZQaZrsdQK0ZXKnHYPqmW IHDIipfDcDVKy4JzRY3V0+FxNnOFCdsH/FfKAFmRMxbh5Fl77KTL+WB7I1oIYigY2mKM RGTZMqu8RWx7LNA/kmiTPn04dcwkK0PrfY1nRnWnaUAxYsiw57aTv/Qw+NXrewZ0Tay8 T15w==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=cU0JiLPG; spf=pass (google.com: domain of eiter.isaac@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=eiter.isaac@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com. [2a00:1450:4864:20::432]) by gmr-mx.google.com with ESMTPS id x4-20020a2ea7c4000000b002d84d4df8e3si226171ljp.4.2024.04.14.13.12.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 14 Apr 2024 13:12:25 -0700 (PDT) Received-SPF: pass (google.com: domain of eiter.isaac@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) client-ip=2a00:1450:4864:20::432; Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-343d32aba7eso796763f8f.1 for ; Sun, 14 Apr 2024 13:12:25 -0700 (PDT) X-Received: by 2002:adf:e70a:0:b0:343:6310:6870 with SMTP id c10-20020adfe70a000000b0034363106870mr5170921wrm.7.1713125544818; Sun, 14 Apr 2024 13:12:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Isaac Eiter Date: Sun, 14 Apr 2024 15:12:13 -0500 Message-ID: Subject: Re: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy To: Bitcoin Error Log Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000008dfe8e0616141fe8" X-Original-Sender: eiter.isaac@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=cU0JiLPG; spf=pass (google.com: domain of eiter.isaac@gmail.com designates 2a00:1450:4864:20::432 as permitted sender) smtp.mailfrom=eiter.isaac@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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 (/) --0000000000008dfe8e0616141fe8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable "Example: Retailers or service providers accepting Bitcoin in a face-to-face setting need transactions to be final immediately to prevent fraud." - Transactions can't be final until included in a block. Pretending that adding a flag to the transaction makes it "final" is going to give a false sense of security for those accepting 0-conf transactions. On-chain point-of-sale payments will never be economically feasible in a bitcoinized world. And if the point-of-sale payment is large enough to justify using on-chain, then it's also worth waiting to see it in a block. "Automated payments for services" - If you are using recurring payments, time isn't of the essence. The guarantee of a "DNR" is pointless, there's no reason to rely on a transaction flag instead of waiting for confirmation via presence in a block. "DNR potentially improves next block fee competition" - I'm not sure this solves a real problem. On Sun, Apr 14, 2024 at 10:16=E2=80=AFAM Bitcoin Error Log < bitcoinerrorlog@gmail.com> wrote: > *Posted here:* > https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00= 138.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 > Abstract > > This BIP introduces a utility-optimized strategy for Bitcoin mempool > policy with new transaction signaling mechanisms, including Do-Not-Replac= e > (DNR) and Replace-by-Fee (RBF), to enhance control over transaction > handling and improve the network's economic efficiency. > Motivation > > Enhancing user autonomy and network efficiency through precise, > user-defined transaction signals that integrate seamlessly with Bitcoin's > decentralized nature and existing economic models. > Specification Transaction Signals > > - > > Do-Not-Replace (DNR): Ensures transactions are not replaced once > broadcast. This flag is encoded using a specific bit in the transactio= n=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 mechani= sm is > used to increase the likelihood of a transaction being picked up by mi= ners > in conditions of high network congestion, ensuring timely processing. > > Encoding > > The new flag signal, DNR, could be encoded similarly to existing RBF > flags, with complementary mempool handling and conflict-resolution logic > for default local enforcement. > > > Rationale > > Addresses the need for predictable transaction handling while respecting > the decentralized, incentive-driven 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 limits is out of scope and remains separately necessary. > Strategic Options for Mempool Evolution > > There are three strategic options for evolving the Bitcoin mempool > 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 and DN= R to > facilitate specific goals of transactors. The primary tradeoff is that > these flags are suggestions and can be overridden by miners, which mea= ns > they are not enforceable but serve as strong hints to improve transact= ion > predictability and network efficiency. > - > - > > Node-defined (The chaotic, centralizing option): This strategy would > encourage third-party mempool providers to implement their subjective > preferences on transaction facilitation. The significant tradeoff here= is > the potential fracturing of the mempool and private, mining-pool-centr= ic > inclusion requirements, which could lead to increased centralization a= nd > censorship. > - > - > > Miner-defined (The rational, pessimistic option): The final strategy > involves removing all policies and flags, allowing miners to decide ba= sed > on transaction fees or other out-of-band terms. This approach simplifi= es > the network at the cost of significantly reducing the utility for user= s who > may need special handling for their transactions. > > Arguments for User-Definition > > Option 1 is favored here because it provides a balanced approach that > enhances user experience and network functionality without overly > complicating the Bitcoin protocol or risking centralization. By > standardizing flags that indicate user preferences, we can achieve greate= r > harmony and utility within the Bitcoin network, supporting diverse user > needs while maintaining decentralization. > > More importantly, we may be able to prevent mempool fragmentation and > privatization to miners and pools for direct transaction inclusion by > intentionally supporting flags that better compete and match transaction > use cases within the open mempool network instead of censoring them > arbitrarily. > > > Economic Implications > > The introduction of these signals could influence transaction fee markets > and network congestion patterns: > > - > > DNR potentially improves next-block fee competition and improves > network throughput by providing clearer signals about transaction > permanence and relevance. > - > > RBF allows for dynamic fee adjustments that can enhance the certainty > of transaction confirmations during peak times, benefiting users who n= eed > timely processing. > > 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. > Here are some specific use cases: > > - > > Point-of-Sale Transactions: > - > > Example: Retailers or service providers accepting Bitcoin in a > face-to-face setting need transactions to be final immediately to p= revent > fraud. > - > > Usage: By using the DNR flag, merchants can ensure that once a > transaction is broadcast, it cannot be replaced, thereby securing t= he > payment process at the point of sale. > - > > Wage Payments: > - > > Example: Employers 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 cancel= ed, > ensuring employees receive the exact intended amounts. > - > > Automated Payments for Services: > - > > Example: Subscription services where automated payments are > scheduled and should not be subject to change once initiated. > - > > Usage: DNR can be applied to ensure that automated recurring > payments are processed without the risk of being replaced, thus sim= plifying > financial planning 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 scenari= os: > > - > > High-Frequency Trading: > - > > Example: Traders on cryptocurrency exchanges who need to rapidly > adjust their positions based 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 premium fast > delivery or emergency technical services. > - > > Usage: When quick service 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 auction closes. > - > > Usage: Auction participants can use RBF to adjust their transaction > fees to outpace other transactions in times of network 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 d= elayed, > optimizing their transaction fee expenditures. > > Adoption and Transition Strategy & Requirements > > It is implicit, until now, that within this strategy is a requirement for > Core and other implementations to abandon strategies within Option 2, by > specifically removing and rejecting policy tools like mempoolfullrbf, or > other attempts to overrule, filter, or otherwise filter and hamper the > propagation of valid, non-destructive 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 the benefits and implications o= f > these new transaction signals. > > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd= 7ab41106n%40googlegroups.com > > . > --=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/CAEQht-vBi65qfj1gNp7m1vBk%2B9C_2WDwSurni%3DFTmxdAT_Cbgw%40mail.g= mail.com. --0000000000008dfe8e0616141fe8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Example: Retaile= rs or service providers accepting Bitcoin in a face-to-face setting need tr= ansactions to be final immediately to prevent fraud." - Transactions can't be final until included in a= block. Pretending that adding a flag to the transaction makes it "fin= al" is going to give a false sense of security for those accepting 0-c= onf transactions. On-chain point-of-sale payments will never be economicall= y feasible in a bitcoinized world. And if the point-of-sale payment is larg= e enough to justify using on-chain, then it's also worth waiting to see= it in a block.

=
"Automated payments for serv= ices" - If you are using recurring payments, time isn't of the ess= ence. The guarantee of a "DNR" is pointless, there's no reaso= n to rely on a transaction flag instead of waiting for confirmation via pre= sence in a block.

"DNR potentially improves = next block fee competition" - I'm not sure this solves a real prob= lem.

On Sun, Apr 14, 2024 at 10:16=E2=80=AFAM Bitcoin Error Log <<= a href=3D"mailto:bitcoinerrorlog@gmail.com">bitcoinerrorlog@gmail.com&g= t; wrote:
Pos= ted here: https://github.com/Bitcoin= AndLightningLayerSpecs/balls/blob/main/balls-00138.md

Full text here:

BIP: XXXX
Title: U= ser-Defined Transaction Flags Policy & Strategy
Author: John Car= valho
Type: Standards Track
Created: Apr 15, 2024
Stat= us: 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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://g= roups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%4= 0googlegroups.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/msgid/bitcoindev/CAEQht-vBi65qfj1gNp7m1vBk%2B9C_2WDwSurni%3DFT= mxdAT_Cbgw%40mail.gmail.com.
--0000000000008dfe8e0616141fe8--