Oct 27, 2024

We use PoW as the block DoS guard, and fees for txs. They are validated in the context of a next block (the actual block may have an incompatible context, but almost never, and we revalidate as necessary). We don’t have a mempool, we have a tx pool (unconfirmed txs, either from weak (reorged or disgorged) blocks or as unconfirmed txs relay). The store is append only, once we write a tx it never changes and they are all stored I. The same manner/place.

We don’t care about “replacement”, or any of the policy and pool antics that are currently ongoing. We just store a tx if it has sufficient fees (configurable) to guard the store. This implies that if a tx creates a conflict with a stored tx, the net mineable fee must be a min increase for it to be accepted, strictly for DoS protect. Packaging is this also considered, but not in the way Core has implemented it. I posted our concept of that to bitcoin-dev a couple years ago.

I'll dig that up. To be clear here by fee you mean absolute fee, not feerate right?

Is that what you are referring to? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020518.html

Ah, no it must be this https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020544.html.

Looks like it’s both, yes.

The tx DoS protection is a min fee rate (sats/byte), and for conflicts is the same idea, but must “pay for” both itself and the graph it conflicts with.

Since txs are stored to disk and paid for, and constant time accessible, there is little concern for size. The purpose of them is for miners to build the most optimal templates. They also speed block announcement, also strictly for miners. For a merchant to “see” unconfirmed txs doesn’t require anything but querying the store for the one’s of interest. Address subscript was a v3 feature, and that is now Electrum-based indexing, which covers all outputs for all confirmed, unconfirmed, and conflicting txs. For mining we will eventually run a chaser to maintain the minimal state (graph) necessary to generate a block template (much smaller than txs in a “pool”, which we store to disk).

Am i correct this minimum feerate is 1 sat/vbyte, as per https://github.com/libbitcoin/libbitcoin-blockchain/blob/2be874a62181fd73f93a4b5feb3e9f162b39dd78/src/settings.cpp#L29 ? Is that also the value used for the min increase? So for instance if an incoming 100k vbytes transaction conflicts with an in-pool, 1sat/vb, 500k vbytes transaction, then it needs to be at least 7sat/vb (pays the min fee for both itself and the transaction it conflicts with, plus the 1sat/vb min increase).

No, blockchain is an obsolete v3 project (and fee rate was configurable for v3). But that's the idea. It's not limited to individual transactions, but any unconfirmed subgraph(s) in conflict. You won't find this in implementation for v4.

Ok, i see. I'll make the graph thing clear in the example i'll use in my writeup.

Do you have a limit on the size of transactions you accept in the pool?

The tx graph is related to the topic on packaging that you linked above.

No, there is no limit to the size of individual transactions except that they must be confirmable. For a package to be considered it must be independently confirmable as well (see comments in bitcoin-dev post). There is an inherent rough patch there at the limit, due the the variable nature of coinbases, which could be exploited if misconfigured, but that's really only an issue for miners, who have the coinbase under their control.

The approach is simple, allow anything that is valid while protecting against disk overflow (using PoW for blocks and fees for unconfirmed txs). There's no policy necessary apart from the fee rate required for DoS protection.

That's where i was getting at. 🙂 ok, i'll read these posts before asking more questions.

Yeah, the idea is that the coinbase size is configured by default with a large enough value that the maximal tx/subgraph can get mined. A miner who wants to maximize revenue could take more risk (given his low probability of mining it himself, his own coinbase size isn't necessarily the primary consideration).

What matters is that the transacting party is exposed to a real risk of fee sacrifice.