path: root/0d/b2c57638c0fea9614b720368a36aae5b6be9ab

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 <bitcoindev+bncBC3PT7FYWAMRBOHU7GYAMGQEXFM5AUY@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <acf8b209-0c7c-4885-8fcc-8f79c2c4d045n@googlegroups.com>
In-Reply-To: <CALeFGL3Vu_RLvUjfHUec3M6aYdBND0Nf4=Ddm2zEn=20DtZxqg@mail.gmail.com>
References: <cc812488-9da0-4595-be3b-bcfd7ab41106n@googlegroups.com>
 <CALeFGL3Vu_RLvUjfHUec3M6aYdBND0Nf4=Ddm2zEn=20DtZxqg@mail.gmail.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <bitcoin...@gma=
il.com>=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
>> <https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bc=
fd7ab41106n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>> .
>>
>

--=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,<div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></d=
iv><div>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.</div><d=
iv><br /></div><div>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.</div><div>=C2=A0</=
div><div>Best,</div><div>Antoine</div><div><br /></div><div>[0]=C2=A0https:=
//github.com/lightning/bolts/issues/783</div><div>[1]=C2=A0https://github.c=
om/bitcoin/bitcoin/issues/29454<br /><br /></div><div class=3D"gmail_quote"=
><div dir=3D"auto" class=3D"gmail_attr">Le lundi 15 avril 2024 =C3=A0 23:00=
:59 UTC+1, Keagan McClelland a =C3=A9crit=C2=A0:<br/></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(=
204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr">Gaming this out a few =
iterations, I&#39;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.<div><br></d=
iv><div>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.</div><div><br></div><div>Ke=
ags</div></div><br><div class=3D"gmail_quote"></div><div class=3D"gmail_quo=
te"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Apr 14, 2024 at 9:16=E2=
=80=AFAM Bitcoin Error Log &lt;<a href data-email-masked rel=3D"nofollow">b=
itcoin...@gmail.com</a>&gt; wrote:<br></div></div><div class=3D"gmail_quote=
"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><b>Posted here:</b> <a =
href=3D"https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/ba=
lls-00138.md" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/BitcoinAndLight=
ningLayerSpecs/balls/blob/main/balls-00138.md&amp;source=3Dgmail&amp;ust=3D=
1713316762197000&amp;usg=3DAOvVaw0Eig6M0uGzQo9wD0ZBISZr">https://github.com=
/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00138.md</a><br><div><=
br></div><div><b>Full text here:</b></div><div><br></div><div><p dir=3D"ltr=
" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=
=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background=
-color:transparent;font-variant-numeric:normal;font-variant-east-asian:norm=
al;font-variant-alternates:normal;vertical-align:baseline">BIP: XXXX</span>=
<span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0)=
;background-color:transparent;font-variant-numeric:normal;font-variant-east=
-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><br><=
/span><span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(=
0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian=
t-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"=
>Title: User-Defined Transaction Flags Policy &amp; Strategy</span><span st=
yle=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);backgro=
und-color:transparent;font-variant-numeric:normal;font-variant-east-asian:n=
ormal;font-variant-alternates:normal;vertical-align:baseline"><br></span><s=
pan style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);b=
ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a=
sian:normal;font-variant-alternates:normal;vertical-align:baseline">Author:=
 John Carvalho</span><span style=3D"font-size:11pt;font-family:Arial,sans-s=
erif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:nor=
mal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-=
align:baseline"><br></span><span style=3D"font-size:11pt;font-family:Arial,=
sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numer=
ic:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ver=
tical-align:baseline">Type: Standards Track</span><span style=3D"font-size:=
11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transpa=
rent;font-variant-numeric:normal;font-variant-east-asian:normal;font-varian=
t-alternates:normal;vertical-align:baseline"><br></span><span style=3D"font=
-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:t=
ransparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-=
variant-alternates:normal;vertical-align:baseline">Created: Apr 15, 2024</s=
pan><span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,=
0,0);background-color:transparent;font-variant-numeric:normal;font-variant-=
east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><=
br></span><span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:=
rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-va=
riant-east-asian:normal;font-variant-alternates:normal;vertical-align:basel=
ine">Status: Draft

</span></p><span dir=3D"ltr" style=3D"line-height:1.38;margin-top:16pt;marg=
in-bottom:4pt"><span style=3D"font-size:14pt;font-family:Arial,sans-serif;c=
olor:rgb(67,67,67);background-color:transparent;font-weight:700;font-varian=
t-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:nor=
mal;vertical-align:baseline">Abstract</span></span><p dir=3D"ltr" style=3D"=
line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size=
:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transp=
arent;font-variant-numeric:normal;font-variant-east-asian:normal;font-varia=
nt-alternates:normal;vertical-align:baseline">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&#39;s eco=
nomic efficiency.

</span></p><span dir=3D"ltr" style=3D"line-height:1.38;margin-top:16pt;marg=
in-bottom:4pt"><span style=3D"font-size:14pt;font-family:Arial,sans-serif;c=
olor:rgb(67,67,67);background-color:transparent;font-weight:700;font-varian=
t-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:nor=
mal;vertical-align:baseline">Motivation</span></span><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-=
size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:tr=
ansparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-v=
ariant-alternates:normal;vertical-align:baseline">Enhancing user autonomy a=
nd network efficiency through precise, user-defined transaction signals tha=
t integrate seamlessly with Bitcoin&#39;s decentralized nature and existing=
 economic models.

</span></p><span dir=3D"ltr" style=3D"line-height:1.38;margin-top:16pt;marg=
in-bottom:4pt"><span style=3D"font-size:14pt;font-family:Arial,sans-serif;c=
olor:rgb(67,67,67);background-color:transparent;font-weight:700;font-varian=
t-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:nor=
mal;vertical-align:baseline">Specification
</span></span><span dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;m=
argin-bottom:4pt"><span style=3D"font-size:12pt;font-family:Arial,sans-seri=
f;color:rgb(102,102,102);background-color:transparent;font-variant-numeric:=
normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertic=
al-align:baseline">Transaction Signals</span></span><ul style=3D"margin-top=
:0px;margin-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:disc;font-=
size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:tr=
ansparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-v=
ariant-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><p d=
ir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=
=3D"presentation"><span style=3D"font-size:11pt;background-color:transparen=
t;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:norma=
l;font-variant-alternates:normal;vertical-align:baseline">Do-Not-Replace (D=
NR)</span><span style=3D"font-size:11pt;background-color:transparent;font-v=
ariant-numeric:normal;font-variant-east-asian:normal;font-variant-alternate=
s:normal;vertical-align:baseline">: 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.</span></p=
></li><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-fam=
ily:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-var=
iant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:=
normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation=
"><span style=3D"font-size:11pt;background-color:transparent;font-weight:70=
0;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a=
lternates:normal;vertical-align:baseline">Replace-by-Fee (RBF): </span><spa=
n style=3D"font-size:11pt;background-color:transparent;font-variant-numeric=
:normal;font-variant-east-asian:normal;font-variant-alternates:normal;verti=
cal-align:baseline">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.

</span></p></li></ul><span dir=3D"ltr" style=3D"line-height:1.38;margin-top=
:14pt;margin-bottom:4pt"><span style=3D"font-size:12pt;font-family:Arial,sa=
ns-serif;color:rgb(102,102,102);background-color:transparent;font-variant-n=
umeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal=
;vertical-align:baseline">Encoding</span></span><p dir=3D"ltr" style=3D"lin=
e-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11=
pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transpare=
nt;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-=
alternates:normal;vertical-align:baseline">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.</span></p=
><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"=
><span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><br>=
</span></p><span dir=3D"ltr" style=3D"line-height:1.38;margin-top:16pt;marg=
in-bottom:4pt"><span style=3D"font-size:14pt;font-family:Arial,sans-serif;c=
olor:rgb(67,67,67);background-color:transparent;font-weight:700;font-varian=
t-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:nor=
mal;vertical-align:baseline">Rationale</span></span><p dir=3D"ltr" style=3D=
"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-siz=
e:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:trans=
parent;font-variant-numeric:normal;font-variant-east-asian:normal;font-vari=
ant-alternates:normal;vertical-align:baseline">Addresses the need for predi=
ctable transaction handling while respecting the decentralized, incentive-d=
riven nature of network participants.</span></p><br><p dir=3D"ltr" style=3D=
"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-siz=
e:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:trans=
parent;font-style:italic;font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-variant-alternates:normal;vertical-align:baseline">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.

</span></p><span dir=3D"ltr" style=3D"line-height:1.38;margin-top:14pt;marg=
in-bottom:4pt"><span style=3D"font-size:12pt;font-family:Arial,sans-serif;c=
olor:rgb(102,102,102);background-color:transparent;font-variant-numeric:nor=
mal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-=
align:baseline">Strategic Options for Mempool Evolution</span></span><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);backg=
round-color:transparent;font-variant-numeric:normal;font-variant-east-asian=
:normal;font-variant-alternates:normal;vertical-align:baseline">There are t=
hree strategic options for evolving the Bitcoin mempool management, where o=
nly one should be optimized:</span></p><br><ul style=3D"margin-top:0px;marg=
in-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:none;font-size:11pt=
;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent=
;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-al=
ternates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr=
" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"prese=
ntation"><span style=3D"font-size:11pt;background-color:transparent;font-we=
ight:700;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline">User-defined (The ideal, o=
ptimistic option): </span><span style=3D"font-size:11pt;background-color:tr=
ansparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-v=
ariant-alternates:normal;vertical-align:baseline">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.</span></p></li><li dir=3D"ltr" style=3D"list-=
style-type:none;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0=
);background-color:transparent;font-variant-numeric:normal;font-variant-eas=
t-asian:normal;font-variant-alternates:normal;vertical-align:baseline;white=
-space:pre-wrap"><br></li><li dir=3D"ltr" style=3D"list-style-type:none;fon=
t-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:=
transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font=
-variant-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><p=
 dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" ro=
le=3D"presentation"><span style=3D"font-size:11pt;background-color:transpar=
ent;font-weight:700;font-variant-numeric:normal;font-variant-east-asian:nor=
mal;font-variant-alternates:normal;vertical-align:baseline">Node-defined (T=
he chaotic, centralizing option): </span><span style=3D"font-size:11pt;back=
ground-color:transparent;font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-variant-alternates:normal;vertical-align:baseline">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.</span></p></li><li dir=3D"ltr" style=3D"list-style-type:none;fo=
nt-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color=
:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;fon=
t-variant-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><=
br></li><li dir=3D"ltr" style=3D"list-style-type:none;font-size:11pt;font-f=
amily:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-v=
ariant-numeric:normal;font-variant-east-asian:normal;font-variant-alternate=
s:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation=
"><span style=3D"font-size:11pt;background-color:transparent;font-weight:70=
0;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a=
lternates:normal;vertical-align:baseline">Miner-defined (The rational, pess=
imistic option): </span><span style=3D"font-size:11pt;background-color:tran=
sparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-var=
iant-alternates:normal;vertical-align:baseline">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.

</span></p></li></ul><span dir=3D"ltr" style=3D"line-height:1.38;margin-top=
:14pt;margin-bottom:4pt"><span style=3D"font-size:12pt;font-family:Arial,sa=
ns-serif;color:rgb(102,102,102);background-color:transparent;font-variant-n=
umeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal=
;vertical-align:baseline">Arguments for User-Definition</span></span><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span =
style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);backg=
round-color:transparent;font-variant-numeric:normal;font-variant-east-asian=
:normal;font-variant-alternates:normal;vertical-align:baseline">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</span></p><br><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans=
-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:n=
ormal;font-variant-east-asian:normal;font-variant-alternates:normal;vertica=
l-align:baseline">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.</span></p><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0=
pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-=
serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:no=
rmal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical=
-align:baseline"><br></span></p><span dir=3D"ltr" style=3D"line-height:1.38=
;margin-top:14pt;margin-bottom:4pt"><span style=3D"font-size:12pt;font-fami=
ly:Arial,sans-serif;color:rgb(102,102,102);background-color:transparent;fon=
t-variant-numeric:normal;font-variant-east-asian:normal;font-variant-altern=
ates:normal;vertical-align:baseline">Economic Implications</span></span><p =
dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><sp=
an style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);ba=
ckground-color:transparent;font-variant-numeric:normal;font-variant-east-as=
ian:normal;font-variant-alternates:normal;vertical-align:baseline">The intr=
oduction of these signals could influence transaction fee markets and netwo=
rk congestion patterns:</span></p><ul style=3D"margin-top:0px;margin-bottom=
:0px"><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-fam=
ily:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-var=
iant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:=
normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=
=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation=
"><span style=3D"font-size:11pt;background-color:transparent;font-variant-n=
umeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal=
;vertical-align:baseline">DNR potentially improves next-block fee competiti=
on and improves network throughput by providing clearer signals about trans=
action permanence and relevance.</span></p></li><li dir=3D"ltr" style=3D"li=
st-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,=
0,0);background-color:transparent;font-variant-numeric:normal;font-variant-=
east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;wh=
ite-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt=
;margin-bottom:0pt" role=3D"presentation"><span style=3D"font-size:11pt;bac=
kground-color:transparent;font-variant-numeric:normal;font-variant-east-asi=
an:normal;font-variant-alternates:normal;vertical-align:baseline">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.

</span></p></li></ul><span dir=3D"ltr" style=3D"line-height:1.38;margin-top=
:16pt;margin-bottom:4pt"><span style=3D"font-size:14pt;font-family:Arial,sa=
ns-serif;color:rgb(67,67,67);background-color:transparent;font-weight:700;f=
ont-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alte=
rnates:normal;vertical-align:baseline">Do-Not-Replace (DNR) Use Cases</span=
></span><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bott=
om:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-serif;color:rg=
b(0,0,0);background-color:transparent;font-variant-numeric:normal;font-vari=
ant-east-asian:normal;font-variant-alternates:normal;vertical-align:baselin=
e">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:

</span></p><ul style=3D"margin-top:0px;margin-bottom:0px"><li dir=3D"ltr" s=
tyle=3D"list-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;co=
lor:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;fon=
t-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:b=
aseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=3D"font-siz=
e:11pt;background-color:transparent;font-variant-numeric:normal;font-varian=
t-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"=
>Point-of-Sale Transactions:</span></p><ul style=3D"margin-top:0px;margin-b=
ottom:0px"><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;fon=
t-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;fon=
t-variant-numeric:normal;font-variant-east-asian:normal;font-variant-altern=
ates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" st=
yle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentat=
ion"><span style=3D"font-size:11pt;background-color:transparent;font-varian=
t-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:nor=
mal;vertical-align:baseline">Example: Retailers or service providers accept=
ing Bitcoin in a face-to-face setting need transactions to be final immedia=
tely to prevent fraud.</span></p></li><li dir=3D"ltr" style=3D"list-style-t=
ype:disc;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);backg=
round-color:transparent;font-variant-numeric:normal;font-variant-east-asian=
:normal;font-variant-alternates:normal;vertical-align:baseline;white-space:=
pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bo=
ttom:0pt" role=3D"presentation"><span style=3D"font-size:11pt;background-co=
lor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;=
font-variant-alternates:normal;vertical-align:baseline">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=
.</span></p></li></ul></li><li dir=3D"ltr" style=3D"list-style-type:disc;fo=
nt-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color=
:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;fon=
t-variant-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><=
p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" r=
ole=3D"presentation"><span style=3D"font-size:11pt;background-color:transpa=
rent;font-variant-numeric:normal;font-variant-east-asian:normal;font-varian=
t-alternates:normal;vertical-align:baseline">Wage Payments:</span></p><ul s=
tyle=3D"margin-top:0px;margin-bottom:0px"><li dir=3D"ltr" style=3D"list-sty=
le-type:disc;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);b=
ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a=
sian:normal;font-variant-alternates:normal;vertical-align:baseline;white-sp=
ace:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margi=
n-bottom:0pt" role=3D"presentation"><span style=3D"font-size:11pt;backgroun=
d-color:transparent;font-variant-numeric:normal;font-variant-east-asian:nor=
mal;font-variant-alternates:normal;vertical-align:baseline">Example: Employ=
ers paying salaries in Bitcoin require certainty that the transaction amoun=
ts cannot be altered once sent.</span></p></li><li dir=3D"ltr" style=3D"lis=
t-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0=
,0);background-color:transparent;font-variant-numeric:normal;font-variant-e=
ast-asian:normal;font-variant-alternates:normal;vertical-align:baseline;whi=
te-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;=
margin-bottom:0pt" role=3D"presentation"><span style=3D"font-size:11pt;back=
ground-color:transparent;font-variant-numeric:normal;font-variant-east-asia=
n:normal;font-variant-alternates:normal;vertical-align:baseline">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.</span></p></li></ul></li><li dir=3D"ltr" styl=
e=3D"list-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;color=
:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-v=
ariant-east-asian:normal;font-variant-alternates:normal;vertical-align:base=
line;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-=
top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=3D"font-size:1=
1pt;background-color:transparent;font-variant-numeric:normal;font-variant-e=
ast-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Au=
tomated Payments for Services:</span></p><ul style=3D"margin-top:0px;margin=
-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;f=
ont-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;f=
ont-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alte=
rnates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" =
style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"present=
ation"><span style=3D"font-size:11pt;background-color:transparent;font-vari=
ant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:n=
ormal;vertical-align:baseline">Example: Subscription services where automat=
ed payments are scheduled and should not be subject to change once initiate=
d.</span></p></li><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:1=
1pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transpar=
ent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant=
-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"=
ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"pr=
esentation"><span style=3D"font-size:11pt;background-color:transparent;font=
-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alterna=
tes:normal;vertical-align:baseline">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.

</span></p></li></ul></li></ul><span dir=3D"ltr" style=3D"line-height:1.38;=
margin-top:16pt;margin-bottom:4pt"><span style=3D"font-size:14pt;font-famil=
y:Arial,sans-serif;color:rgb(67,67,67);background-color:transparent;font-we=
ight:700;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline">Replace-by-Fee (RBF) Use C=
ases</span></span><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;m=
argin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans-seri=
f;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-ali=
gn:baseline">RBF is essential for transactions where timing and confirmatio=
n speed are more critical than the immediacy of finality. Here are applicab=
le scenarios:</span></p><ul style=3D"margin-top:0px;margin-bottom:0px"><li =
dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:Arial,=
sans-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numer=
ic:normal;font-variant-east-asian:normal;font-variant-alternates:normal;ver=
tical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-hei=
ght:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation"><span styl=
e=3D"font-size:11pt;background-color:transparent;font-variant-numeric:norma=
l;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-al=
ign:baseline">High-Frequency Trading:</span></p><ul style=3D"margin-top:0px=
;margin-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:disc;font-size=
:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transp=
arent;font-variant-numeric:normal;font-variant-east-asian:normal;font-varia=
nt-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=
=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=
=3D"presentation"><span style=3D"font-size:11pt;background-color:transparen=
t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a=
lternates:normal;vertical-align:baseline">Example: Traders on cryptocurrenc=
y exchanges who need to rapidly adjust their positions based on market cond=
itions.</span></p></li><li dir=3D"ltr" style=3D"list-style-type:disc;font-s=
ize:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:tra=
nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline;white-space:pre-wrap"><p di=
r=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=
=3D"presentation"><span style=3D"font-size:11pt;background-color:transparen=
t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a=
lternates:normal;vertical-align:baseline">Usage: RBF allows traders to incr=
ease the fee on a transaction if it&#39;s not getting confirmed quickly eno=
ugh, enabling them to ensure timely executions in response to market moveme=
nts.</span></p></li></ul></li><li dir=3D"ltr" style=3D"list-style-type:disc=
;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-co=
lor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;=
font-variant-alternates:normal;vertical-align:baseline;white-space:pre-wrap=
"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt=
" role=3D"presentation"><span style=3D"font-size:11pt;background-color:tran=
sparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-var=
iant-alternates:normal;vertical-align:baseline">Emergency Service Payments:=
</span></p><ul style=3D"margin-top:0px;margin-bottom:0px"><li dir=3D"ltr" s=
tyle=3D"list-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;co=
lor:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;fon=
t-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:b=
aseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;marg=
in-top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=3D"font-siz=
e:11pt;background-color:transparent;font-variant-numeric:normal;font-varian=
t-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"=
>Example: Payments for time-sensitive services, such as premium fast delive=
ry or emergency technical services.</span></p></li><li dir=3D"ltr" style=3D=
"list-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;color:rgb=
(0,0,0);background-color:transparent;font-variant-numeric:normal;font-varia=
nt-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline=
;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt" role=3D"presentation"><span style=3D"font-size:11pt;=
background-color:transparent;font-variant-numeric:normal;font-variant-east-=
asian:normal;font-variant-alternates:normal;vertical-align:baseline">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.</span></p></li></ul></li><li dir=
=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:Arial,san=
s-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:=
normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertic=
al-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height=
:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=
=3D"font-size:11pt;background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-ali=
gn:baseline">Bidding in Auctions:</span></p><ul style=3D"margin-top:0px;mar=
gin-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11p=
t;font-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparen=
t;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-a=
lternates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"lt=
r" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"pres=
entation"><span style=3D"font-size:11pt;background-color:transparent;font-v=
ariant-numeric:normal;font-variant-east-asian:normal;font-variant-alternate=
s:normal;vertical-align:baseline">Example: Participants in online auctions =
who need to ensure their payments go through before the auction closes.</sp=
an></p></li><li dir=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;fo=
nt-family:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;fo=
nt-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alter=
nates:normal;vertical-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" s=
tyle=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presenta=
tion"><span style=3D"font-size:11pt;background-color:transparent;font-varia=
nt-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:no=
rmal;vertical-align:baseline">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.</span></p></li></ul></li><li di=
r=3D"ltr" style=3D"list-style-type:disc;font-size:11pt;font-family:Arial,sa=
ns-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric=
:normal;font-variant-east-asian:normal;font-variant-alternates:normal;verti=
cal-align:baseline;white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-heigh=
t:1.38;margin-top:0pt;margin-bottom:0pt" role=3D"presentation"><span style=
=3D"font-size:11pt;background-color:transparent;font-variant-numeric:normal=
;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-ali=
gn:baseline">Dynamic Fee Management for Wallets:</span></p><ul style=3D"mar=
gin-top:0px;margin-bottom:0px"><li dir=3D"ltr" style=3D"list-style-type:dis=
c;font-size:11pt;font-family:Arial,sans-serif;color:rgb(0,0,0);background-c=
olor:transparent;font-variant-numeric:normal;font-variant-east-asian:normal=
;font-variant-alternates:normal;vertical-align:baseline;white-space:pre-wra=
p"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0p=
t" role=3D"presentation"><span style=3D"font-size:11pt;background-color:tra=
nsparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-va=
riant-alternates:normal;vertical-align:baseline">Example: Users sending non=
-urgent transactions who want to minimize fees but are willing to increase =
them if network conditions change.</span></p></li><li dir=3D"ltr" style=3D"=
list-style-type:disc;font-size:11pt;font-family:Arial,sans-serif;color:rgb(=
0,0,0);background-color:transparent;font-variant-numeric:normal;font-varian=
t-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline;=
white-space:pre-wrap"><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0=
pt;margin-bottom:0pt" role=3D"presentation"><span style=3D"font-size:11pt;b=
ackground-color:transparent;font-variant-numeric:normal;font-variant-east-a=
sian:normal;font-variant-alternates:normal;vertical-align:baseline">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.

</span></p></li></ul></li></ul><span dir=3D"ltr" style=3D"line-height:1.38;=
margin-top:16pt;margin-bottom:4pt"><span style=3D"font-size:14pt;font-famil=
y:Arial,sans-serif;color:rgb(67,67,67);background-color:transparent;font-va=
riant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates=
:normal;vertical-align:baseline">Adoption and Transition Strategy &amp; Req=
uirements</span></span><p dir=3D"ltr" style=3D"line-height:1.38;margin-top:=
0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-family:Arial,sans=
-serif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:n=
ormal;font-variant-east-asian:normal;font-variant-alternates:normal;text-de=
coration-line:underline;vertical-align:baseline">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 </span><span style=3D"font-size:11pt;font-family:A=
rial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-weight:7=
00;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-=
alternates:normal;text-decoration-line:underline;vertical-align:baseline">m=
empoolfullrbf</span><span style=3D"font-size:11pt;font-family:Arial,sans-se=
rif;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:norm=
al;font-variant-east-asian:normal;font-variant-alternates:normal;text-decor=
ation-line:underline;vertical-align:baseline">, or other attempts to overru=
le, filter, or otherwise filter and hamper the propagation of valid, non-de=
structive transactions.</span></p><br><p dir=3D"ltr" style=3D"line-height:1=
.38;margin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:11pt;font-fa=
mily:Arial,sans-serif;color:rgb(0,0,0);background-color:transparent;font-va=
riant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates=
:normal;vertical-align:baseline">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.</span></p><br></div>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.=
com?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"no=
follow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3D=
https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7a=
b41106n%2540googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;s=
ource=3Dgmail&amp;ust=3D1713316762197000&amp;usg=3DAOvVaw3JXgr5aUqrhXu5fS3U=
XtST">https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-=
bcfd7ab41106n%40googlegroups.com</a>.<br>
</blockquote></div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/acf8b209-0c7c-4885-8fcc-8f79c2c4d045n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/acf8b209-0c7c-4885-8fcc-8f79c2c4d045n%40googlegroups.com</a>.=
<br />

------=_Part_20079_952834049.1713232864136--

------=_Part_20078_1244308087.1713232864136--