* [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy
@ 2024-04-14 15:09 Bitcoin Error Log
2024-04-14 15:51 ` Peter Todd
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Bitcoin Error Log @ 2024-04-14 15:09 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9042 bytes --]
*Posted here:*
https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00138.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-Replace (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 transaction’s
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 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 DNR to
facilitate 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
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-centric
inclusion requirements, which could lead to increased centralization and
censorship.
-
-
Miner-defined (The rational, pessimistic option): The final strategy
involves removing all policies and flags, allowing miners to decide based
on transaction 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 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 greater
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 need
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 prevent
fraud.
-
Usage: By using the DNR flag, merchants can ensure that once a
transaction is broadcast, it cannot be replaced, thereby securing the
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 canceled,
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 simplifying
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 scenarios:
-
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 delayed,
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 of
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-bcfd7ab41106n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 44951 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy
2024-04-14 15:09 [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy Bitcoin Error Log
@ 2024-04-14 15:51 ` Peter Todd
2024-04-14 20:12 ` Isaac Eiter
2024-04-15 18:58 ` Keagan McClelland
2 siblings, 0 replies; 5+ messages in thread
From: Peter Todd @ 2024-04-14 15:51 UTC (permalink / raw)
To: Bitcoin Error Log; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]
On Sun, Apr 14, 2024 at 08:09:51AM -0700, Bitcoin Error Log wrote:
> 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.
For the record, I will continue to distribute both my Libre Relay¹ and Full-RBF
Peering² forks of Bitcoin Core, and they will continue to propagate full-rbf
replacements. I'd estimate roughly 30 nodes in total on the P2P network are
running one of those two forks. Bitcoin Knots also enables full-RBF by default,
and has something like 150 nodes.
90%+ of hash rate is running full-RBF because it's common for blocks to earn
thousands of dollars worth of fees from full-RBF replacements. The idea that
miners would give that up, en-mass, just because you asked nicely for the sake
of your broken, insecure, and unused ways of transacting bitcoin is laughable.
Miners regularly modify the Bitcoin Core codebase for their own needs;
commenting out the one line of code that prevents full-RBF replacements is
trivial.
You'd do well to stop wasting your time with this nonsense and work on
Lightning or something. As for Bitcoin Core, enabling full-RBF by default is
well overdue: https://github.com/bitcoin/bitcoin/pull/28132
1) https://github.com/petertodd/bitcoin/tree/libre-relay-v27.0rc1
2) https://github.com/petertodd/bitcoin/tree/full-rbf-v27.0rc1
--
https://petertodd.org 'peter'[:-1]@petertodd.org
--
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/Zhv7hp9aydx3KAQA%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy
2024-04-14 15:09 [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy Bitcoin Error Log
2024-04-14 15:51 ` Peter Todd
@ 2024-04-14 20:12 ` Isaac Eiter
2024-04-15 18:58 ` Keagan McClelland
2 siblings, 0 replies; 5+ messages in thread
From: Isaac Eiter @ 2024-04-14 20:12 UTC (permalink / raw)
To: Bitcoin Error Log; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 10772 bytes --]
"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 AM Bitcoin Error Log <
bitcoinerrorlog@gmail•com> wrote:
> *Posted here:*
> https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00138.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-Replace
> (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 transaction’s
> 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 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 DNR to
> facilitate 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
> 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-centric
> inclusion requirements, which could lead to increased centralization and
> censorship.
> -
> -
>
> Miner-defined (The rational, pessimistic option): The final strategy
> involves removing all policies and flags, allowing miners to decide based
> on transaction 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 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 greater
> 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 need
> 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 prevent
> fraud.
> -
>
> Usage: By using the DNR flag, merchants can ensure that once a
> transaction is broadcast, it cannot be replaced, thereby securing the
> 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 canceled,
> 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 simplifying
> 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 scenarios:
>
> -
>
> 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 delayed,
> 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 of
> 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-bcfd7ab41106n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEQht-vBi65qfj1gNp7m1vBk%2B9C_2WDwSurni%3DFTmxdAT_Cbgw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 40167 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy
2024-04-14 15:09 [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy Bitcoin Error Log
2024-04-14 15:51 ` Peter Todd
2024-04-14 20:12 ` Isaac Eiter
@ 2024-04-15 18:58 ` Keagan McClelland
2024-04-16 2:01 ` Antoine Riard
2 siblings, 1 reply; 5+ messages in thread
From: Keagan McClelland @ 2024-04-15 18:58 UTC (permalink / raw)
To: Bitcoin Error Log; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 10731 bytes --]
Gaming this out a few iterations, I'm pretty sure a widely deployed DNR
policy will result in a proliferation of direct-to-miner transaction
submissions and will result in less network-wide visibility of the
transaction set that is staged for confirmation. At first it seems
reasonable to assume that users can help block the propagation of a
hypothetical DNR replacement, but the miners ultimately are unlikely to
make this choice in practice. The only argument you can fall back on here
is that Miners openly defying user desires will ultimately result in
stagnant or negative BTC growth which is bad for their long term, but I
think that argument is pretty weak in this context.
Relying on DNR type behavior in applications will definitely be insecure,
but I think fighting to do it anyway has even more distortion effects that
we are unlikely to want in the long run.
Keags
On Sun, Apr 14, 2024 at 9:16 AM Bitcoin Error Log <bitcoinerrorlog@gmail•com>
wrote:
> *Posted here:*
> https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00138.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-Replace
> (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 transaction’s
> 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 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 DNR to
> facilitate 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
> 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-centric
> inclusion requirements, which could lead to increased centralization and
> censorship.
> -
> -
>
> Miner-defined (The rational, pessimistic option): The final strategy
> involves removing all policies and flags, allowing miners to decide based
> on transaction 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 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 greater
> 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 need
> 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 prevent
> fraud.
> -
>
> Usage: By using the DNR flag, merchants can ensure that once a
> transaction is broadcast, it cannot be replaced, thereby securing the
> 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 canceled,
> 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 simplifying
> 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 scenarios:
>
> -
>
> 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 delayed,
> 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 of
> 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-bcfd7ab41106n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CALeFGL3Vu_RLvUjfHUec3M6aYdBND0Nf4%3DDdm2zEn%3D20DtZxqg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 39384 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy
2024-04-15 18:58 ` Keagan McClelland
@ 2024-04-16 2:01 ` Antoine Riard
0 siblings, 0 replies; 5+ messages in thread
From: Antoine Riard @ 2024-04-16 2:01 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 13546 bytes --]
Hi John,
Few years ago, while discussing mitigations for mempool pinning at the
commitment and second-stage transaction-level, we went to consider
deploying new transaction-relay infrastructure directly connecting
Lightning nodes and miners mempools over LN gossips [0]. This idea was
disregarded, as you're introducing miners / Lightning nodes incentives
misalignment (quid if your LSP who is your channel counterparty drops your
gossip with a HTLC-preimage transaction within). Additionally, mempool
partitioning in the miners mempools can be always tried by your
counterparty with another commitment transaction.
However, one should note that since then privileged transaction-relay API
for Bitcoin applications with time-sensitive traffic requirements have
become more frequent with the "so-branded" transaction accelerators, where
the inclusion of a boosted transaction is only relying on the reputation of
mining pools. With seeing more private / staged transaction-relay API or
protocols, there is indeed a concern of loosing the notion of a common
blockspace market feerate that can be estimated by all full-nodes operators.
On delegating policy-choice to the transaction-issuer themselves, I did
myself an experiment "transaction-issuer selected policy limits" (e.g
selecting the max standard tx weight that is accepted for a transaction
version) [1]. The signaling opt-in mechanism was hacked in the nSequence
field, which I found a bit gross and they are issues with this approach.
Finally, I would observe that still today's mainstream Internet packets
(IPv4 - RFC 794) fields have a defined meaning (e.g type of 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 transaction flags
proposal like that relies on respecting the finality or dynamic transaction
size limits shall come with a security model relying on miners economic
incentives to have the flag semantics validated.
Best,
Antoine
[0] https://github.com/lightning/bolts/issues/783
[1] https://github.com/bitcoin/bitcoin/issues/29454
Le lundi 15 avril 2024 à 23:00:59 UTC+1, Keagan McClelland a écrit :
> Gaming this out a few iterations, I'm pretty sure a widely deployed DNR
> policy will result in a proliferation of direct-to-miner transaction
> submissions and will result in less network-wide visibility of the
> transaction set that is staged for confirmation. At first it seems
> reasonable to assume that users can help block the propagation of a
> hypothetical DNR replacement, but the miners ultimately are unlikely to
> make this choice in practice. The only argument you can fall back on here
> is that Miners openly defying user desires will ultimately result in
> stagnant or negative BTC growth which is bad for their long term, but I
> think that argument is pretty weak in this context.
>
> Relying on DNR type behavior in applications will definitely be insecure,
> but I think fighting to do it anyway has even more distortion effects that
> we are unlikely to want in the long run.
>
> Keags
>
> On Sun, Apr 14, 2024 at 9:16 AM Bitcoin Error Log <bitcoin...@gmail•com>
> wrote:
>
>> *Posted here:*
>> https://github.com/BitcoinAndLightningLayerSpecs/balls/blob/main/balls-00138.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-Replace
>> (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 transaction’s
>> 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 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 DNR to
>> facilitate 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
>> 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-centric
>> inclusion requirements, which could lead to increased centralization and
>> censorship.
>> -
>> -
>>
>> Miner-defined (The rational, pessimistic option): The final strategy
>> involves removing all policies and flags, allowing miners to decide based
>> on transaction 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 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 greater
>> 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 need
>> 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 prevent
>> fraud.
>> -
>>
>> Usage: By using the DNR flag, merchants can ensure that once a
>> transaction is broadcast, it cannot be replaced, thereby securing the
>> 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 canceled,
>> 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 simplifying
>> 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 scenarios:
>>
>> -
>>
>> 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 delayed,
>> 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 of
>> 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+...@googlegroups•com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/cc812488-9da0-4595-be3b-bcfd7ab41106n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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/acf8b209-0c7c-4885-8fcc-8f79c2c4d045n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 42640 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-04-16 13:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-04-14 15:09 [bitcoindev] Draft BIP for User-Defined Transaction Flags Policy & Strategy Bitcoin Error Log
2024-04-14 15:51 ` Peter Todd
2024-04-14 20:12 ` Isaac Eiter
2024-04-15 18:58 ` Keagan McClelland
2024-04-16 2:01 ` Antoine Riard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox