If core decides to merge the OP_RETURN data limit, I won't update to any new version of core with this default implemented.
Just think about what use cases coule and which most probably will emerge.
As an example you can broadcast data through the mempool without paying for the transmitted data by RBF'ing the tx before the tx hit's the first confirmation and replace it as long as it doesn't get that much sats/vb to be confirmed. This lowers the relative fee for any further RBF (with new data included and distributed) DRAMATICALLY and will create incentives for mempool only use cases which just consume node bandwith which isn't even paid for to the miners. Sounds like siphoning the avaiable bandwith of node runners for the distribution of data. I won't give my node ressources in support of creating and maintaining a relative RBF sats/vb market.
h/t @OceanSlim
Login to reply
Replies (6)
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.
i favor smaller blocks, i would love to see the witness discount removed, that would fix a lot of things, problem is it is a hard fork, as OS points out
anyway, the spammers only took advantage of the fact that so much tx volume got shifted to lightning, and used the vulnerability that has been there since 2017
yes, and taproot is also cutting the data size and fee cost for regular transactions as well as the size of lightning transactions, i can't imagine where they can go with squeezing it down any further, and i think the reason why the spam has mostly gone away is because people have got wise to the scams and aren't buying into bitcoin based shitcoins anyway, on top of the general widespread decline of interest in shitcoins due to the fact that a blockchain is a terrible way to store data in general, all the hype about that is dying pretty fast as shitcoin projects are deploying dual epyc servers with quad raid controllers to keep up with it and the money just gets slurped up by hardware costs and the scammers are realising their grift may not have much legs anymore.
I cannot agree more. I of course am in favor of smaller blocks too. But 4mb is the limit. I have to be okay with anything below that, no matter what the block may contain. I'm not saying you or anyone else has to be okay with it in their mempool, but you do have to be okay with it in your node. Thems the rules.
If core decides to merge the OP_RETURN data limit, I won't update to any new version of core with this default implemented.
Just think about what use cases coule and which most probably will emerge.
As an example you can broadcast data through the mempool without paying for the transmitted data by RBF'ing the tx before the tx hit's the first confirmation and replace it as long as it doesn't get that much sats/vb to be confirmed. This lowers the relative fee for any further RBF (with new data included and distributed) DRAMATICALLY and will create incentives for mempool only use cases which just consume node bandwith which isn't even paid for to the miners. Sounds like siphoning the avaiable bandwith of node runners for the distribution of data. I won't give my node ressources in support of creating and maintaining a relative RBF sats/vb market.
h/t @OceanSlim
View quoted note →
#yestr
If core decides to merge the OP_RETURN data limit, I won't update to any new version of core with this default implemented.
Just think about what use cases coule and which most probably will emerge.
As an example you can broadcast data through the mempool without paying for the transmitted data by RBF'ing the tx before the tx hit's the first confirmation and replace it as long as it doesn't get that much sats/vb to be confirmed. This lowers the relative fee for any further RBF (with new data included and distributed) DRAMATICALLY and will create incentives for mempool only use cases which just consume node bandwith which isn't even paid for to the miners. Sounds like siphoning the avaiable bandwith of node runners for the distribution of data. I won't give my node ressources in support of creating and maintaining a relative RBF sats/vb market.
h/t @OceanSlim
View quoted note →