One of the things that makes me proud of bitcoin is its exhibition of rightly ordered freedom. Users freely select the software that does what they like best, and freely run it, without harming anyone else. Everyone wins in a "conflict" like this. The number of node runners goes up, bitcoin's network health rises, and everyone gets to express their opinion through software choices. To me, it's a beautiful thing. I want more of it.
Login to reply
Replies (4)
I think LN reliability will go down though if these new Tor node runners try creating channels for the first time and if Knots defaults cause issues with LN channels (closing, CPFP...) ๐
i agree with all your points, but bitcoins biggest disadvantage to adoption is its complexity. Its like the ERP SAP which is smarter than most of its users. Bitcoin is in a similiar boat. If you have a software/tech background you will be fine but for those who don't it does not come across well.
I think I persuaded openoms that it's wrong to insinuate that Knots users are in danger of force closures or cpfp difficulties. Perhaps the thread will convince you too:
> Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical
I do not understand this criticism. Neither Knots nor Core looks *only* at the mempool to estimate fees. Partly as a result of this, the scenario where a wallet based on Knots would give a fee estimate that "wouldn't work" seems absurd: (1) the total weight of spam transactions in the mempool would have to *suddenly* increase (2) without a corresponding, similar increase in competition from "normal" (non-spammy) transactions (3) to a point where the non-spammy transactions only show fees at level X (4) but the real feerate is actually at level Y (5) and Y is so much larger than X that X won't work. But even that's not enough, for the following reason:
As an example of a wallet with a critical need to get a transaction confirmed in a certain time frame, consider a lightning node. These have to be prepared to use RBF or CPFP to bump their transactions if a justice transaction is called for, because they must "go through" in a certain time frame. (E.g. see here: https://docs.lightning.engineering/lightning-network-tools/lnd/sweeper). Since Knots and Core both look at "recent blocks" to figure out what the current feerates are, and not just the mempool, this means the above scenario -- with the sudden increase in spam fees with several other conditions attached -- will only cause the wallet to fail to get its transaction confirmed if the scenario *repeats* as each subsequent block comes out, such that the additional fee information provided by block K+1 is already out of date when Knots tries to estimate fees again at the prompting of whatever wallet wants to use RBF or CPFP to get its transaction confirmed.
Given the absurdity of such a situation playing out in the real world, it seems equally absurd to use this as a legitimate criticism of Knots. Even in critical applications, your fee estimator does not need a *precisely accurate* mempool. If bitcoin required that, it would be a broken system, because the mempool is intentionally not consensus critical.
View quoted note →
Yeah, I don't understand cpfp, so I'll have to trust you on that.