📅 Original date posted:2022-02-10 📝 Original message:> ...

2023-06-07T23:04:13Z

In reply to nevent1q…csuf
_________________________

📅 Original date posted:2022-02-10
📝 Original message:> It's not that simple. As a miner, if i have less than 1vMB of
transactions in my mempool. I don't want a 10sats/vb transaction paying
100000sats by a 100sats/vb transaction paying only 10000sats.

I don't understand why the "<1vMB in the mempool" case is even worth
consideration because the miner will just include the entire mempool in the
next block regardless of feerate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/58bee534/attachment-0001.html>;

📅 Original date posted:2022-02-17 📝 Original message:> ...

2023-06-07T23:04:11Z

In reply to nevent1q…w5a6
_________________________

📅 Original date posted:2022-02-17
📝 Original message:> Is it really true that miners do/should care about that?

De facto, any miner running an unmodified version of bitcoind doesn't
care about anything aside from ancestor fee rate, given that the
BlockAssembler as-written orders transactions for inclusion by
descending ancestor fee-rate and then greedily adds them to the block
template. [0]

If anyone has any indication that there are miners running forks of
bitcoind that change this behavior, I'd be curious to know it.

Along the lines of what AJ wrote, optimal transaction selection is
NP-hard (knapsack problem). Any time that a miner spends deciding how
to assemble the next block is time not spent grinding on the nonce, and
so I'm skeptical that miners in practice are currently doing anything
that isn't fast and simple like the default implementation: sorting
fee-rate in descending order and then greedily packing.

But it would be interesting to hear evidence to the contrary.

---

You can make the argument that transaction selection is just a function
of mempool contents, and so mempool maintenance criteria might be the
thing to look at. Mempool acceptance is gated based on a minimum
feerate[1]. Mempool eviction (when running low on space) happens on
the basis of max(self_feerate, descendant_feerate) [2]. So even in the
mempool we're still talking in terms of fee rates, not absolute fees.

That presents us with the "is/ought" problem: just because the mempool
*is* currently gating only on fee rate doesn't mean that's optimal. But
if the whole point of the mempool is to hold transactions that will be
mined, and if there's good reason that txns are chosen for mining based
on fee rate (it's quick and good enough), then it seems like fee rate
is the approximation that should ultimately prevail for txn
replacement.

[0]:
https://github.com/bitcoin/bitcoin/blob/master/src/node/miner.cpp#L310-L320
[1]:
https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1106
[2]:
https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.cpp#L1138-L1144
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220217/178b279c/attachment.html>;

📅 Original date posted:2022-02-10 📝 Original ...

2023-06-07T23:04:07Z

In reply to nevent1q…p7ft
_________________________

📅 Original date posted:2022-02-10
📝 Original message:There's been much talk about fee-bumping lately, and for good reason -
dynamic fee management is going to be a central part of bitcoin use as
the mempool fills up (lord willing) and right now fee-bumping is
fraught with difficulty and pinning peril.

Gloria's recent post on the topic[0] was very lucid and highlights a
lot of the current issues, as well as some proposals to improve the
situation.

As others have noted, the post was great. But throughout the course
of reading it and the ensuing discussion, I became troubled by the
increasing complexity of both the status quo and some of the
proposed remedies.

Layering on special cases, more carve-outs, and X and Y percentage
thresholds is going to make reasoning about the mempool harder than it
already is. Special consideration for "what should be in the next
block" and/or the caching of block templates seems like an imposing
dependency, dragging in a bunch of state and infrastructure to a
question that should be solely limited to mempool feerate aggregates
and the feerate of the particular txn package a wallet is concerned
with.

This is bad enough for protocol designers and Core developers, but
making the situation any more intractable for "end-users" and wallet
developers feels wrong.

I thought it might be useful to step back and reframe. Here are a few
aims that are motivated chiefly by the quality of end-user experience,
constrained to obey incentive compatibility (i.e. miner reward, DoS
avoidance). Forgive the abstract dalliance for a moment; I'll talk
through concretes afterwards.

# Purely additive feerate bumps should never be impossible

Any user should always be able to add to the incentive to mine any
transaction in a purely additive way. The countervailing force here
ends up being spam prevention (a la min-relay-fee) to prevent someone
from consuming bandwidth and mempool space with a long series of
infinitesimal fee-bumps.

A fee bump, naturally, should be given the same per-byte consideration
as a normal Bitcoin transaction in terms of relay and block space,
although it would be nice to come up with a more succinct
representation. This leads to another design principle:

# The bandwidth and chain space consumed by a fee-bump should be minimal

Instead of prompting a rebroadcast of the original transaction for
replacement, which contains a lot of data not new to the network, it
makes more sense to broadcast the "diff" which is the additive
contribution towards some txn's feerate.

This dovetails with the idea that...

# Special transaction structure should not be required to bump fees

In an ideal design, special structural foresight would not be needed
in order for a txn's feerate to be improved after broadcast.

Anchor outputs specified solely for CPFP, which amount to many bytes of
wasted chainspace, are a hack. It's probably uncontroversial at this
point to say that even RBF itself is kind of a hack - a special
sequence number should not be necessary for post-broadcast contribution
toward feerate. Not to mention RBF's seemingly wasteful consumption of
bandwidth due to the rebroadcast of data the network has already seen.

In a sane design, no structural foresight - and certainly no wasted
bytes in the form of unused anchor outputs - should be needed in order
to add to a miner's reward for confirming a given transaction.

Planning for fee-bumps explicitly in transaction structure also often
winds up locking in which keys are required to bump fees, at odds
with the idea that...

# Feerate bumps should be able to come from anywhere

One of the practical downsides of CPFP that I haven't seen discussed in
this conversation is that it requires the transaction to pre-specify the
keys needed to sign for fee bumps. This is problematic if you're, for
example, using a vault structure that makes use of pre-signed
transactions.

What if the key you specified n the anchor outputs for a bunch of
pre-signed txns is compromised? What if you'd like to be able to
dynamically select the wallet that bumps fees? CPFP does you no favors
here.

There is of course a tension between allowing fee bumps to come from
anywhere and the threat of pinning-like attacks. So we should venture
to remove pinning as a possibility, in line with the first design
principle I discuss.

---

Coming down to earth, the "tabula rasa" thought experiment above has led
me to favor an approach like the transaction sponsors design that Jeremy
proposed in a prior discussion back in 2020[1].

Transaction sponsors allow feerates to be bumped after a transaction's
broadcast, regardless of the structure of the original transaction.
No rebroadcast (wasted bandwidth) is required for the original txn data.
No wasted chainspace on only-maybe-used prophylactic anchor outputs.

The interface for end-users is very straightforward: if you want to bump
fees, specify a transaction that contributes incrementally to package
feerate for some txid. Simple.

In the original discussion, there were a few main objections that I noted:

1. In Jeremy's original proposal, only one sponsor txn per txid is
allowed by policy. A malicious actor could execute a pinning-like
attack by specifying an only-slightly-helpful feerate sponsor that
then precludes other larger bumps.

I think there are some ways around this shortcoming. For example: what
if, by policy, sponsor txns had additional constraints that

- each input must be signed {SIGHASH_SINGLE,SIGHASH_NONE}|ANYONECANPAY,
- the txn must be specified RBFable,
- a replacement for the sponsor txn must raise the sponsor feerate,
including ancestors (maybe this is inherent in "is RBFable," but
I don't want to conflate absolute feerates into this).

That way, there is still at most a single sponsor txn per txid in the
mempool, but anyone can "mix in" inputs which bump the effective
feerate of the sponsor.

This may not be the exact solution we want, but I think it demonstrates
that the sponsors design has some flexibility and merits some thinking.

The second objection about sponsors was

2. (from Suhas) sponsors break the classic invariant: "once a valid
transaction is created, it should not become invalid later on unless
the inputs are double-spent."

This doesn't seem like a huge concern to me if you consider the txid
being sponsored as a sort of spiritual input to the sponsor. While the
theoretical objection against broadening where one has to look in a txn
to determine its dependencies is understandable, I don't see what the
practical cost here is.

Reorg complexity seems comparable if not identical, especially if we
broaden sponsor rules to allow blocks to contain sponsor txns that are
both for txids in the same block _or_ already included in the chain.

This theoretical concession seems preferable to heaping more rules onto
an already labyrinthine mempool policy that is difficult for both
implementers and users to reason about practically and conceptually.

A third objection that wasn't posed, IIRC, but almost certainly would
be:

3. Transaction sponsors requires a soft-fork.

Soft-forks are no fun, but I'll tell you what also isn't fun: being on
the hook to model (and sometimes implement) a dizzying potpourri of
mempool policies and special-cases. Expecting wallet implementers to
abide by a maze of rules faithfully in order to ensure txn broadcast and
fee management invites bugs for perpetuity and network behavior that is
difficult to reason about a priori. Use of CPFP in the long-term also
risks needless chain waste.

If a soft-fork is the cost of cleaning up this essential process,
consideration should be given to paying it as a one-time cost. This
topic merits a separate post, but consider that in the 5 years leading
up to the 2017 SegWit drama, we averaged about a soft-fork a year.
Uncontroversial, "safe" changes to the consensus protocol shouldn't be
out of the question when significant practical benefit is plain to see.

---

I hope this message has added some framing to the discussion on fees,
as well prompting other participants to go back and give the
transaction sponsor proposal a serious look. The sponsors interface is
about the simplest I can imagine for wallets, and it seems easy to
reason about for implementers on Core and elsewhere.

I'm not out to propose soft-forks lightly, but the current complexity
in fee management feels untenable, and as evidenced by all the
discussion lately, fees are an increasingly crucial part of the system.

[0]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
[1]:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220210/b6bf7054/attachment.html>;

Nostr notes by James O'Beirne [ARCHIVE]

📅 Original date posted:2022-02-10 📝 Original message:> ...

📅 Original date posted:2022-02-17 📝 Original message:> ...

📅 Original date posted:2022-02-10 📝 Original ...