I presume the protocol is this: https://github.com/getAlby/nips/blob/master/47.md
Is it planned to open a PR to the main nostr-protocol repo?
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.
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.
did you try:
bitcoind.estimatemode=ECNOMICAL
in the in the lnd.conf ?
You are right in the use case, but it is a demo server because it shouldn't be relied on!
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.
Good data point, but would be interesting if there are bigger differences occasionally over time.
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.
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.
There you go, but not using the demo server, are you?
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.
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.
we need this
it is a main usecase of any honest custodial wallet to be able to receive easily and withdraw anywhere the cheapest and most efficient way possible
#[0]
Then you can get into trusting yourself and/or other(s).
Is it not better to call it self-custodial?
It's my incentive to have an accurate fee estimation in my own node so the transactions broadcasted automatically won't underpay.
To get new things implemented opening a feature request on the github repo is the most efficient way.
People who also have the need can discuss and get it done.
There is nO menu option, but can build Core from source.
I don't see it being a good idea, as it messes up the fee estimation vs the miners.
OBW can have a hosted channel from your node if it is running CLN and the poncho plugin
