public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Improving RBF Policy
@ 2022-02-01  2:47 Prayank
  2022-02-01  9:30 ` Bastien TEINTURIER
  0 siblings, 1 reply; 25+ messages in thread
From: Prayank @ 2022-02-01  2:47 UTC (permalink / raw)
  To: Bastien TEINTURIER; +Cc: Bitcoin Dev

[-- Attachment #1: Type: text/plain, Size: 1133 bytes --]

Hi Bastein,

> This work will highly improve the security of any multi-party contract trying to build on top of bitcoin
Do you think such multi party contracts are vulnerable by design considering they rely on policy that cannot be enforced?

> For starters, let me quickly explain why the current rules are hard to work with in the context of lightning
Using the term 'rules' can be confusing sometimes because it's just a policy and different from consensus rules. I wish we could change this in the BIP with something else.

> I'm actually paying a high fee twice instead of once (and needlessly using on-chain space, our scarcest asset, because we could have avoided that additional transaction
Not sure I understand this part because if a transaction is on-chain it can't be replaced. 

> The second biggest pain point is rule 3. It prevents me from efficiently using my capital while it's unconfirmed
> I'm curious to hear other people's thoughts on that. If it makes sense, I would propose the following very simple rules
Looks interesting however not sure about X and Y.

-- 
Prayank

A3B1 E430 2298 178F

[-- Attachment #2: Type: text/html, Size: 1828 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] Improving RBF Policy
@ 2022-02-09 17:57 lisa neigut
  0 siblings, 0 replies; 25+ messages in thread
From: lisa neigut @ 2022-02-09 17:57 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 7417 bytes --]

Changing the way that RBF works is an excellent idea. Bitcoin is overdue
for revisiting these rules. Thanks to @glowzo et al for kicking off the
discussion.

I've been thinking about RBF for a very long time[1], and it's been fun to
see other people's thoughts on the topics. Here's my current thinking about
this, and proposal for how we should update the rules.

### Changing the Rules? How to Change Them
Regarding how to change them, Bram and aj are right -- we should move to a
model where transaction relay candidates are evaluated on their net
increase in fees per byte paid, and remove the requirement that the gross
fee of the preceding transaction is met or exceeded.

Our current ruleset is over complicated because it attempts to solve two
problems at once: the miner's best interests (highest possible fee take)
and relay policy.

I believe this is a mistake and the mempool should change its goals.
Instead, the mempool relay design for RBFs should be built around 1)
increasing the the per-byte fees paid of a transaction and 2) providing a
simple policy for applications building on top of bitcoin, such that
knowledge of the mempool is not required for successfully issuing
relay-able RBF transactions.

(A simple "must increase the per-byte feerate" heuristic for RBF relay
candidates has the nice benefit of being easy to program to on the
application side, and only requires knowledge of the previous candidate
transaction, not the entire mempool or any previous tx's relative position
within it.)

Finally, when blockspace is competitive , this simple policy ensures that
the per-byte value of every subsequent relayed transaction increases the
per-byte value of pending bytes for the next block. This provides a measure
of DoS protection and ensures that every relayed byte is more valuable (to
the miner/network) than the last.

*The only time that RBF is critical for relay is during full block periods
-- if there's not enough transactions to fill a block, using RBF to ensure
that a transaction is mined in a timely manner is moot. As such, RBF rules
should not be concerned with low-block environments.

### Mempools and Relay
The mempool currently serves two masters: the profit motive of the miner
and the relay motive of a utxo holder. It is in the interest of a user to
send the miner a high per-byte tx, such that it might end up in the next
block. It is in the miner's best interest to include the highest per-byte
set of transactions in their block template.

There is some conflation here in the current RBF policies between what is
in the mempool and what is considered a candidate for the block template.
If a miner has already included a more profitable package of txs into their
block template than a more valuable per-byte tx that the network has
relayed to them, it should be the responsibility of the block template
constructor to reject the new proposed tx, not the nodes relaying the
transaction to said miner.

This is a policy that the miner can (and should) implement at the level of
the template construction, however.

Is it the responsibility of the mempool to provide the best "historical"
block opportunity for a miner (e.g. the highest paying block given all txs
it's ever seen)? I would say no, that the ability of a utxo owner to
re-state the spend condition of a pending transaction is more important,
from a use-case perspective, and that the mempool should concern itself
solely with relaying increasingly more profitable bytes to miners. Let the
miners concern themselves with deciding what the best policy for their own
block construction is, and the mempool with relaying the highest value
bytes for the network. Net-net, this will benefit everyone as it becomes
easier for users to re-submit txs with increasingly greater feerates,
creating more active competition for available blockspace as more
applications are able to include it as a feature (and it works, reliable,
as a relay mechanism).

### Packages and RBF
Packages make the increasing per-byte rule less of a guarantee that
increasing the per-byte value of a single transaction will net a given
miner more fees than including the entire package.

Let's decompose this a bit. It's helpful to think of tx packages as
'composable txs'. Basically when you consider a 'package' it is actually a
large tx with sub-components, the individual txs. As a 'composed tx', you
can calculate the per-byte feerate of the entire set. This is the number
that you, as someone issuing an RBF, would need to beat in order to move
your tx up in the pending block queue.

RBF, however, is a transaction level policy: it allows you to replace any
*one* component of a package, or tree, with the side effect of possibly
invalidating other candidate txs. If the 'composed tx' (aka package) had a
net per-byte value that was higher than the new replacement transaction
because of a leaf tx that had an outsized per-byte feerate, then it would
be more profitable for the miner to have mined the entire package rather
than the replacement.

This edge case complicates the picture for the miner. Considered from the
viewpoint of the user issuing the RBF, however, it is far simpler. In the
ideal case, a person is issuing an RBF because the previous tx tree, even
with its high fee sub-component, was not a candidate for the next block.
And, in some cases, increasing the sub-component's per-byte feerate will
not achieve the goal of moving the tx any closer to being mined. It's only
by increasing the feerate above the present feerate of the candidate plus
desendents (tx package) that the transaction will advance in the queue.

While not uncomplicated, this is a simple enough metric for a wallet to
track, and does not require any knowledge of the current mempool to
effectively surpass. It's the wallet's responsibility to track this though;
failure to take descendants into account when deciding on the next per-byte
feerate for an RBF *will* mean that your RBF will be ineffective at
achieving the goal of getting your UTXO spent. Any wallet is incentivized
to always provide a higher per-byte feerate than the 'composed tx' (tx and
its descendants), so as to ensure an actual improvement in the unconfirmed
transaction's position in the block queue, so to speak.

Note that the v2 protocol for channel opens in lightning uses an RBF
negotiation that adheres basically to these rules (ea transaction must have
a strictly greater per-byte feerate).

We enforce a rate of 65/64th as the required increase in feerate for each
subsequent channel open transaction.

https://github.com/lightning/bolts/pull/851/files#diff-ed04ca2c673fd6aabde69389511fa9ee60cb44d6b2ef6c88b549ffaa753d6afeR1154

### RBF and DoS

Admittedly, changing these rules will increase the number of times that any
UTXO is eligible to be retransmitted (relayed) via the bitcoin node
network. Strictly increasing the per-byte feerate however ensures that this
re-relay is increasingly more expensive to the UTXO owner, however.


### in exitus
These are the things I've been thinking about with regards to RBF. I hope
they can help to highlight the challenges in the RBF design space a bit
more clearly, as well as spelling out the case for using a simple heuristic
such as "solely increasing per-byte feerate" as a good candidate for the
revised RBF policy.

~niftynei

[1]
https://basicbitch.software/posts/2018-12-27-Explaining-Replace-By-Fee.html

[-- Attachment #2: Type: text/html, Size: 15920 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
[parent not found: <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>]
* [bitcoin-dev] Improving RBF Policy
@ 2022-01-27 13:42 Gloria Zhao
  2022-01-28  1:35 ` Jeremy
  2022-01-30 22:53 ` Antoine Riard
  0 siblings, 2 replies; 25+ messages in thread
From: Gloria Zhao @ 2022-01-27 13:42 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 21067 bytes --]

Hi everyone,

This post discusses limitations of current Bitcoin Core RBF policy and
attempts to start a conversation about how we can improve it,
summarizing some ideas that have been discussed. Please reply if you
have any new input on issues to be solved and ideas for improvement!

Just in case I've screwed up the text wrapping again, another copy can be
found here: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff

## Background

Please feel free to skip this section if you are already familiar
with RBF.

Nodes may receive *conflicting* unconfirmed transactions, aka
"double spends" of the same inputs. Instead of always keeping the
first transaction, since v0.12, Bitcoin Core mempool policy has
included a set of Replace-by-Fee (RBF) criteria that allows the second
transaction to replace the first one and any descendants it may have.

Bitcoin Core RBF policy was previously documented as BIP 125.
The current RBF policy is documented [here][1]. In summary:

1. The directly conflicting transactions all signal replaceability
   explicitly.

2. The replacement transaction only includes an unconfirmed input if
   that input was included in one of the directly conflicting
transactions.

3. The replacement transaction pays an absolute fee of at least the
   sum paid by the original transactions.

4. The additional fees pays for the replacement transaction's
   bandwidth at or above the rate set by the node's *incremental relay
feerate*.

5. The sum of all directly conflicting transactions' descendant counts
   (number of transactions inclusive of itself and its descendants)
does not exceed 100.

We can split these rules into 3 categories/goals:

- **Allow Opting Out**: Some applications/businesses are unable to
  handle transactions that are replaceable (e.g. merchants that use
zero-confirmation transactions). We (try to) help these businesses by
honoring BIP125 signaling; we won't replace transactions that have not
opted in.

- **Incentive Compatibility**: Ensure that our RBF policy would not
  accept replacement transactions which would decrease fee profits
  of a miner. In general, if our mempool policy deviates from what is
economically rational, it's likely that the transactions in our
mempool will not match the ones in miners' mempools, making our
fee estimation, compact block relay, and other mempool-dependent
functions unreliable. Incentive-incompatible policy may also
encourage transaction submission through routes other than the p2p
network, harming censorship-resistance and privacy of Bitcoin payments.

- **DoS Protection**: Limit two types of DoS attacks on the node's
  mempool: (1) the number of times a transaction can be replaced and
(2) the volume of transactions that can be evicted during a
replacement.

Even more abstract: our goal is to make a replacement policy that
results in a useful interface for users and safe policy for
node operators.

## Motivation

There are a number of known problems with the current RBF policy.
Many of these shortcomings exist due to mempool limitations at the
time RBF was implemented or result from new types of Bitcoin usage;
they are not criticisms of the original design.

### Pinning Attacks

The most pressing concern is that attackers may take advantage of
limitations in RBF policy to prevent other users' transactions from
being mined or getting accepted as a replacement.

#### SIGHASH_ANYONECANPAY Pinning

BIP125#2 can be bypassed by creating intermediary transactions to be
replaced together. Anyone can simply split a 1-input 1-output
transaction off from the replacement transaction, then broadcast the
transaction as is. This can always be done, and quite cheaply. More
details in [this comment][2].

In general, if a transaction is signed with SIGHASH\_ANYONECANPAY,
anybody can just attach a low feerate parent to this transaction and
lower its ancestor feerate.  Even if you require SIGHASH\_ALL which
prevents an attacker from changing any outputs, the input can be a
very low amount (e.g. just above the dust limit) from a low-fee
ancestor and still bring down the ancestor feerate of the transaction.

TLDR: if your transaction is signed with SIGHASH\_ANYONECANPAY and
signals replaceability, regardless of the feerate you broadcast at, an
attacker can lower its mining priority by adding an ancestor.

#### Absolute Fee

The restriction of requiring replacement transactions to increase the
absolute fee of the mempool has been described as "bonkers." If the
original transaction has a very large descendant that pays a large
amount of fees, even if it has a low feerate, the replacement
transaction must now pay those fees in order to meet Rule #3.

#### Package RBF

There are a number of reasons why, in order to enable Package RBF, we
cannot use the same criteria.

For starters, the absolute fee pinning attack is especially
problematic if we apply the same rules (i.e. Rule #3 and #4) in
Package RBF. Imagine that Alice (honest) and Bob (adversary) share a
LN channel. The mempool is rather full, so their pre-negotiated
commitment transactions' feerates would not be considered high
priority by miners.  Bob broadcasts his commitment transaction and
attaches a very large child (100KvB with 100,000sat in fees) to his
anchor output. Alice broadcasts her commitment transaction with a
fee-bumping child (200vB with 50,000sat fees which is a generous
250sat/vB), but this does not meet the absolute fee requirement. She
would need to add another 50,000sat to replace Bob's commitment
transaction.

Disallowing new unconfirmed inputs (Rule #2) in Package RBF would be
broken for packages containing transactions already in the mempool,
explained [here][7].

Note: I originally [proposed][6] Package RBF using the same Rule #3
and #4 before I realized how significant this pinning attack is. I'm
retracting that proposal, and a new set of Package RBF rules would
follow from whatever the new individual RBF rules end up being.

#### Same Txid Different Witness

Two transactions with the same non-witness data but different
witnesses have the same txid but different wtxid, and the same fee but
not necessarily the same feerate. Currently, if we see a transaction
that has the same txid as one in the mempool, we reject it as a
duplicate, even if the feerate is much higher. It's unclear to me if
we have a very strong reason to change this, but noting it as a
limitation of our current replacement policy. See [#24007][12].

### User Interface

#### Using Unconfirmed UTXOs to Fund Replacements

The restriction of only allowing confirmed UTXOs for funding a
fee-bump (Rule #2) can hurt users trying to fee-bump their
transactions and complicate wallet implementations. If the original
transaction's output value isn't sufficient to fund a fee-bump and/or
all of the user's other UTXOs are unconfirmed, they might not be able
to fund a replacement transaction. Wallet developers also need to
treat self-owned unconfirmed UTXOs as unusable for fee-bumping, which
adds complexity to wallet logic. For example, see BDK issues [#144][4]
and [#414][5].

#### Interface Not Suitable for Coin Selection

Currently, a user cannot simply create a replacement transaction
targeting a specific feerate or meeting a minimum fee amount and
expect to meet the RBF criteria. The fee amount depends on the size of
the replacement transaction, and feerate is almost irrelevant.

Bitcoin Core's `bumpfee` doesn't use the RBF rules when funding the
replacement. It [estimates][13] a feerate which is "wallet incremental
relay fee" (a conservative overestimation of the node's incremental
relay fee) higher than the original transaction, selects coins for
that feerate, and hopes that it meets the RBF rules. It never fails
Rule #3 and #4 because it uses all original inputs and refuses to
bump a transaction with mempool descendants.

This is suboptimal, but is designed to work with the coin selection
engine: select a feerate first, and then add fees to cover it.
Following the exact RBF rules would require working the other way
around: based on how much fees we've added to the transaction and its
current size, calculate the feerate to see if we meet Rule #4.

While this isn't completely broken, and the user interface is
secondary to the safety of the mempool policy, we can do much better.
A much more user-friendly interface would depend *only* on the
fee and size of the original transactions.

### Updates to Mempool and Mining

Since RBF was first implemented, a number of improvements have been
made to mempool and mining logic. For example, we now use ancestor
feerates in mining (allowing CPFP), and keep track of ancestor
packages in the mempool.

## Ideas for Improvements

### Goals

To summarize, these seem to be desired changes, in order of priority:

1. Remove Rule #3. The replacement should not be *required* to pay
higher absolute fees.

2. Make it impossible for a replacement transaction to have a lower
mining score than the original transaction(s). This would eliminate
the `SIGHASH\_ANYONECANPAY` pinning attack.

3. Remove Rule #2. Adding new unconfirmed inputs should be allowed.

4. Create a more helpful interface that helps wallet fund replacement
transactions that aim for a feerate and fee.

### A Different Model for Fees

For incentive compatibility, I believe there are different
formulations we should consider.  Most importantly, if we want to get
rid of the absolute fee rule, we can no longer think of it as "the
transaction needs to pay for its own bandwidth," since we won't always
be getting additional fees. That means we need a new method of
rate-limiting replacements that doesn't require additional fees every
time.

While it makes sense to think about monetary costs when launching a
specific type of attack, given that the fees are paid to the miner and
not to the mempool operators, maybe it doesn't make much sense to
think about "paying for bandwidth". Maybe we should implement
transaction validation rate-limiting differently, e.g. building it
into the P2P layer instead of the mempool policy layer.

Recently, Suhas gave a [formulation][8] for incentive compatibility
that made sense to me: "are the fees expected to be paid in the next
(N?) blocks higher or lower if we process this transaction?"

I started by thinking about this where N=1 or `1 + p`.
Here, a rational miner is looking at what fees they would
collect in the next block, and then some proportion `p` of the rest of
the blocks based on their hashrate. We're assuming `p` isn't *so high*
that they would be okay with lower absolute fees in the next 1 block.
We're also assuming `p` isn't *so low* that the miner doesn't care
about what's left of the mempool after this block.

A tweak to this formulation is "if we process this transaction, would
the fees in the next 1 block higher or lower, and is the feerate
density of the rest of the mempool higher or lower?" This is pretty
similar, where N=1, but we consider the rest of the mempool by feerate
rather than fees.

### Mining Score of a Mempool Transaction

We are often interested in finding out what
the "mining score" of a transaction in the mempool is. That is, when
the transaction is considered in block template building, what is the
feerate it is considered at?

Obviously, it's not the transaction's individual feerate. Bitcoin Core
[mining code sorts][14] transactions by their ancestor feerate and
includes them packages at a time, keeping track of how this affects the
package feerates of remaining transactions in the mempool.

*ancestor feerate*: Ancestor feerate is easily accessible information,
but it's not accurate either, because it doesn't take into account the
fact that subsets of a transaction's ancestor set can be included
without it. For example, ancestors may have high feerates on their own
or we may have [high feerate siblings][8].

TLDR: *Looking at the current ancestor feerate of a transaction is
insufficient to tell us what feerate it will be considered at when
building a block template in the future.*

*min(individual feerate, ancestor feerate)*: Another
heuristic that is simple to calculate based on current mempool tooling
is to use the [minimum of a transaction's individual score and its
ancestor score][10] as a conservative measure.  But this can
overestimate as well (see the example below).

*min ancestor feerate(tx + possible ancestor subsets)* We can also
take the minimum of every possible ancestor subset, but this can be
computationally expensive since there can be lots and lots of ancestor
subsets.

*max ancestor feerate(tx + possible descendant subsets)*: Another idea
is to use the [maximum ancestor score of the transaction + each of its
descendants][9]. This doesn't work either; it has the same blindspot
of ancestor subsets being mined on their own.

#### Mining Score Example

Here's an example illustrating why mining score is tricky to
efficiently calculate for mempool transactions:

Let's say you have same-size transactions A (21sat/vB), B (1sat/vB),
C(9sat/vB), D(5sat/vB).
The layout is: grandparent A, parent B, and two children C and D.

```
    A
    ^
    B
   ^ ^
   C D
```

A miner using ancestor packages to build block templates will first
include A with a mining score of 21. Next, the miner will include B and
C with a mining score of 6. This leaves D, with a mining score of 5.

Note: in this case, mining by ancestor feerate results in the most
rational decisions, but [a candidate set-based approach][10] which
makes ancestor feerate much less relevant could
be more advantageous in other situations.

Here is a chart showing the "true" mining score alongside the values
calculating using imperfect heuristics described above. All of them
can overestimate or underestimate.

```
   A     B       C     D
mining score |   21   |   6   |   6   |   5   |
ancestor feerate   |   21   |  11   | 10.3  |   9   |
min(individual, ancestor) |   21   |   1   |   9   |   5   |
min(tx + ancestor subsets)      |   21   |   1   |   5   |   3   |
max(tx + descendants subsets) |   21   |   9   |   9   |   5   |

```

Possibly the best solution for finding the "mining score" of a
transaction is to build a block template, see what feerate each
package is included at. Perhaps at some cutoff, remaining mempool
transactions can be estimated using some heuristic that leans
{overestimating, underestimating} depending on the situation.

Mining score seems to be relevant in multiple places: Murch and I
recently [found][3] that it would be very important in
"ancestor-aware" funding of transactions (the wallet doesn't
incorporate ancestor fees when using unconfirmed transactions in coin
selection, which is a bug we want to fix).

In general, it would be nice to know the exact mining priority of
one's unconfirmed transaction is.  I can think of a few block/mempool
explorers who might want to display this information for users.

### RBF Improvement Proposals

After speaking to quite a few people, here are some suggestions
for improvements that I have heard:

* The ancestor score of the replacement must be {5, 10, N}% higher
  than that of every original transaction.

* The ancestor score of the replacement must be 1sat/vB higher than
  that of every original transaction.

* If the original transaction is in the top {0.75MvB, 1MvB} of the
  mempool, apply the current rules (absolute fees must increase and
pay for the replacement transaction's new bandwidth). Otherwise, use a
feerate-only rule.

* If fees don't increase, the size of the replacement transaction must
  decrease by at least N%.

* Rate-limit how many replacements we allow per prevout.

* Rate-limit transaction validation in general, per peer.

Perhaps some others on the mailing list can chime in to throw other
ideas into the ring and/or combine some of these rules into a sensible
policy.

#### Replace by Feerate Only

I don't think there's going to be a single-line feerate-based
rule that can incorporate everything we need.
On one hand, a feerate-only approach helps eliminate the issues
associated with Rule #3. On the other hand, I believe the main concern
with a feerate-only approach is how to rate limit replacements. We
don't want to enable an attack such as:

1. Attacker broadcasts large, low-feerate transaction, and attaches a
chain of descendants.

2. The attacker replaces the transaction with a smaller but higher
feerate transaction, attaching a new chain of descendants.

3. Repeat 1000 times.

#### Fees in Next Block and Feerate for the Rest of the Mempool

Perhaps we can look at replacements like this:

1. Calculate the directly conflicting transactions and, with their
descendants, the original transactions. Check signaling. Limit the
total volume (e.g. can't be more than 100 total or 1MvB or something).

2. Find which original transactions would be in the next ~1 block. The
replacement must pay at least this amount + X% in absolute fees. This
guarantees that the fees of the next block doesn't decrease.

3. Find which transactions would be left in the mempool after that ~1
block. The replacement's feerate must be Y% higher than the maximum
mining score of these transactions. This guarantees that you now have
only *better* candidates in your after-this-block mempool than you did
before, even if the size and fees the transactions decrease.

4. Now you have two numbers: a minimum absolute fee amount and a
minimum feerate. Check to see if the replacement(s) meet these
minimums. Also, a wallet would be able to ask the node "What fee and
feerate would I need to put on a transaction replacing this?" and use
this information to fund a replacement transaction, without needing to
guess or overshoot.

Obviously, there are some magic numbers missing here. X and Y are
TBD constants to ensure we have some kind of rate limiting for the
number of replacements allowed using some set of fees.

What should they be? We can do some arithmetic to see what happens if
you start with the biggest/lowest feerate transaction and do a bunch
of replacements. Maybe we end up with values that are high enough to
prevent abuse and make sense for applications/users that do RBF.

### Mempool Changes Need for Implementation

As described in the mining score section above,
we may want additional tooling to more accurately assess
the economic gain of replacing transactions in our mempool.

A few options have been discussed:

* Calculate block templates on the fly when we need to consider a
  replacement. However, since replacements are [quite common][11]
  and the information might be useful for other things as well,
  it may be worth it to cache a block template.

* Keep a persistent block template so that we know what transactions
  we would put in the next block. We need to remember the feerate
at which each transaction was included in the template, because an
ancestor package may be included in the same block template in
multiple subsets. Transactions included earlier alter the ancestor
feerate of the remaining transactions in the package. We also need
to keep track of the new feerates of transactions left over.

* Divide the mempool into two layers, "high feerate" and "low
  feerate." The high feerate layer contains ~1 block of packages with
the highest ancestor feerates, and the low feerate layer contains
everything else. At the edge of a block, we have a Knapsacky problem
where the next highest ancestor feerate package might not fit, so we
would probably want the high feerate layer ~2MvB or something to avoid
underestimating the fees.

## Acknowledgements

Thank you to everyone whose RBF-related suggestions, grievances,
criticisms and ideas were incorporated in this document:
Andrew Chow, Matt Corallo, Suhas Daftuar, Christian Decker,
Mark Erhardt, Lloyd Fournier, Lisa Neigut, John Newbery,
Antoine Poinsot, Antoine Riard, Larry Ruane,
S3RK and Bastien Teinturier.

Thanks for reading!

Best,
Gloria

[1]:
https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
[2]: https://github.com/bitcoin/bitcoin/pull/23121#issuecomment-929475999
[3]:
https://github.com/Xekyo/bitcoin/commit/d754b0242ec69d42c570418aebf9c1335af0b8ea
[4]: https://github.com/bitcoindevkit/bdk/issues/144
[5]: https://github.com/bitcoindevkit/bdk/issues/414
[6]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019464.html
[7]:
https://gist.github.com/glozow/dc4e9d5c5b14ade7cdfac40f43adb18a#new-unconfirmed-inputs-rule-2
[8]: https://github.com/bitcoin/bitcoin/pull/23121#discussion_r777131366
[9]: https://github.com/bitcoin/bitcoin/pull/22290#issuecomment-865887922
[10]:
https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
[11]: https://github.com/bitcoin/bitcoin/pull/22539#issuecomment-885763670
[12]: https://github.com/bitcoin/bitcoin/pull/24007
[13]:
https://github.com/bitcoin/bitcoin/blob/1a369f006fd0bec373b95001ed84b480e852f191/src/wallet/feebumper.cpp#L114
[14]:
https://github.com/bitcoin/bitcoin/blob/cf5bb048e80d4cde8828787b266b7f5f2e3b6d7b/src/node/miner.cpp#L310-L320

[-- Attachment #2: Type: text/html, Size: 24377 bytes --]

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2022-03-17 15:59 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-01  2:47 [bitcoin-dev] Improving RBF Policy Prayank
2022-02-01  9:30 ` Bastien TEINTURIER
2022-02-02 10:21   ` Anthony Towns
  -- strict thread matches above, loose matches on Subject: below --
2022-02-09 17:57 lisa neigut
     [not found] <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-01-31 22:54 ` [bitcoin-dev] Improving RBF policy Bram Cohen
2022-02-01  0:08   ` Eric Voskuil
2022-02-01  8:32     ` Bram Cohen
2022-02-01 19:44       ` Eric Voskuil
2022-02-01  0:42   ` Antoine Riard
2022-01-27 13:42 [bitcoin-dev] Improving RBF Policy Gloria Zhao
2022-01-28  1:35 ` Jeremy
2022-01-30 22:53 ` Antoine Riard
2022-01-31 15:57   ` Bastien TEINTURIER
2022-02-01  1:56     ` Anthony Towns
2022-02-05 13:21     ` Michael Folkson
2022-02-07 10:22       ` Bastien TEINTURIER
2022-02-07 11:16         ` Gloria Zhao
2022-02-08  4:58           ` Anthony Towns
2022-03-09 15:09             ` Gloria Zhao
2022-03-11 16:22               ` Billy Tetrud
2022-03-12  8:18                 ` Billy Tetrud
2022-03-14 10:29                   ` Gloria Zhao
2022-03-15  1:43                     ` Billy Tetrud
2022-03-17  2:02               ` Antoine Riard
2022-03-17 15:59                 ` Billy Tetrud

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox