Every RBF transaction has to pay a higher rate than the last one. Just a side note.
I've done more thinking. I think if your viewpoint is switch to something that filters or don't update then you can just consider Bitcoin Ossified at Core 29 (Really core 21, Taproot) until a hardfork outcompetes Bitcoin in the free market. That fork is going to have to prove it's solution to "spam" actually works and doesn't inadvertently censor real "financial transactions" and it's going to have to beat a 2T dollar asset quickly or else it will just fade into nothing.
Any change since Taproot has just been maintenance and policy. The best route forward for the reference implementation now is to strip it completely down to concensous only so we know better what we're working with and can actually achieve a real solution at some point. If you like some policy that gets stripped out, there should be a well funded concensous fork to satisfy that market demand.
Login to reply
Replies (3)
Thank you for taking my hand and guiding me through implemention choices. ๐ซ Much value from you to me.
Your sidenote is acutally about my main point of my original note:
**Theoretical**
The increased sats/vb rate (=delta sats to pay for completely new data to be distributed in the mempools) is for the signer from mempooltx[t0] and mempooltx[t1] and mempooltx[txyz] very cheap.
**Practical**
I then can distribute for just a few hundred sats completely new data with an RBF "overwrite" of the old data in the mempools.
My opinion:
1. Filters do work and cause significant economic and effort cost to people that attempt to work around them
2. Worst case smaller blocks and higher fees by 2x the end
not to the chain, I know. But I can abuse the mempools as temporary distributed data storage for VERY LOW FEES (just what is the policy for a valid increase in fees of an RBF tx is.