It's my incentive to have an accurate fee estimation in my own node so the transactions broadcasted automatically won't underpay.
Discussion
There is no such thing as an "accurate fee estimation" as each node runner has full control over mempool policy, so each mempool can be different (and actually is in practice).
My incentive as a bitcoin user is to pay less fees when I transact, not more. And as a node runner my incentive is to prevent my node from relaying spam* so that the blockchain doesn't bloat, and operating the node doesn't become more expensive than necessary, leading to more pruned nodes and centralization.
*Each node runner decides what he considers spam, it follows from the fact that he controls mempool policy.
With that I agree, you can choose what you want to censor from your own mempool.
It ranges from denying arbirary scripts to running mempoolfullrbf=1.
For me my node's mempool is the more useful the more accurately it is able to predict the next blocks.
Calling that censorship is disingenuous and not constructive to debate. You also "censor" unless you've explicitly set minrelaytxfee=0, or you've never run with blocksonly=1.
It is what it is.
There is a different incentive to drop the bottom fee txns - they won't make it to the next blocks due to clear economic reasons so not useful to be kept or relayed.
And I'm not criticising it, my node also does that. What I'm doing is pointing out the contradiction of calling inscription filtering "censorship", but not 0-fee tx filtering. Both are done in exactly the same way, and neither are an act of censorship.
Both inscribers and 0-fee transactors can tweak their node configs and mine themselves, or strike their deals with miners. An Ordisrespector node doesn't get in the way of any of that.
Look inscription filtering nodes have a handicapped fee estimation in return for slightly less data stored in memory and relayed.
Running the patch has no effect on what gets into the chain (and downloaded by those nodes as well eventually) as something like 90% of the public nodes would need to filter to achieve anything.
If that would happen the inscribors can just use another data structure, possibly even more wasteful.
The thing is I believe we're in a catch-22 situation where an actual supermajority of node runners want to filter inscriptions from their mempools but they don't know how to do it (because BC devs and most node distros aren't making it easy), or they don't even realize they can do it. If I'm right and the situation ends resolving this way the patch will be no more and no less effective than minrelaytxfee. There are 0-fee txs from time to time but they aren't half of the mempool space.
Regarding other Bitcoin Script opcode sequences to embed arbitrary bytes in tx: I don't think they even need to be patched. If the network coordinates to reject this first kind of txs it should discourage spammers from trying much further. Detecting these patterns and patching them out is orders of magnitude easier than finding them, then it's just a matter of how fast most nodes patch them out.
I won't tell you what to do with Raspiblitz. But your users are sovereign to filter inscriptions, and some of them want to do it. They placed their trust in you, and you can either respect that sovereignty or you can try to get in the way of it. That's just the way it is.
Please don't take me as speaking for what happens with the Raspiblitz project. I am an open-source contributor in my free-time and simply deciding what to work on by it being useful for me or not.
There have been no PRs offering patches for Core (which would still need to be reviewed and tested).
The dependence on any of these projects is concerning in itself and I think if someone not able to build Bitcoin Core from source is likely not aware of the implications either.
BTW the Raspiblitz - close to bare metal - way makes the easiest to make such modifications yourself, but as discussed above to have the supermajority of the node network run some patch is not that straightforward and in my opinion not easier than coming up with a new data structure for data storage.
I’m running a “normal” node and the odisrespector patched node. Both return an estimatesmartfee within 1 sat of each other at 1/6/144 block targets. The mempool difference is usually over 100 blocks.
Good data point, but would be interesting if there are bigger differences occasionally over time.
I built the #[11] precisely for that. Though it sources the data from the mempool.space websocket API, not estimatesmartfee.
Nice bot, thank you for building!
And now just look at the No Prio Fee:
1 sat/vByte transactions were last included in a block on 7th March and would also have been purged since.
I like to pay only the minimum fee so find it important to see the floor. To be clear I am most worried about the automatic fee calculation for the commitment transactions on the connected lightning nodes.
Fair point. I didn't thought about that and it's the first time someone brings it up to me.
I concede that an operator of a LN node backed by an Ordisrespector Bitcoin Core has to pay extra attention to both mempools if he wants to close a channel (for now).
The mempool.space api considers the current mempool. But I bitcoind’s estimator looks more at recently mined blocks. You can restart bitcoind with persistmempool=0 and get the similar estimates as with 500gig mempool. One of the reasons I pointed my lnd node to my ordisrepector node was to try to decrease the sweep fees lnd paying (conf target 6). But it made little/no difference and I was paying 20 s/vb when 6 or 7 would’ve put it in the next block.
did you try:
bitcoind.estimatemode=ECNOMICAL
in the in the lnd.conf ?
Yes. However, for block target 6, bitcoind returns the same fee rate for conservative/economical which is 13 s/vb right now
That is clearly because inscriptions are taking uo the lower fee bands. Once the mempool empties more or inscriptors pay more the problem will be present at 6 block targets as well.
Stuck transactions for channel opens and closes are a major headache.
Do you happen to know if LND, Core Lightning and Eclair's onchain wallets support RBF?
Yes, all transaction done by lightning clients are RBF enabled, but can be complicated for the channels due to the multisig.
LND: https://lightning.engineering/api-docs/api/lnd/wallet-kit/bump-fee
not familiar with Eclair and LDK does surely have procedures for this too.
Coming soon...
https://github.com/ZeusLN/zeus/releases/tag/v0.7.4-beta1
* **Fee bumping**
* Channel sorting and filtering
* Default invoice settings
* Single channel view redesign
[...]
I guess my point is running the patch doesn't make the problem worse in that lnd/bitcoind is not underestimating fees because of it. If anything, a very slight positive may be that lnd tx are not being purged from your local bitcoind mempool making it easier to CPFP.
I didn't expect to get schooled today. Thanks for these insights.
This is just my observation from running the patched node for the past month which included a few hours(?) the mempool was actually clearing 1 s/vb txs. I do recommended running a patched node in parallel if you can to see for yourself. I just added 2 lines to lncm/bitcoind Dockerfile to get it going.