It's a vocal minority brigading the pr. They stated to take their discussion to the mailing list and not on the pr, when they didn't, they got banned.
Discussion
i don’t believe it is a minority…
There are 500 knots and 10k core nodes
how many of those core nodes are active participants in reviewing release notes?
what about people like me who are running older core and trying to vocally dissent?
do I not deserve vulnerability fixes or other updates because I don’t support removing my mempool options by default?
the majority of engaged users (node runners) I believe are against this PR.
unfortunately just by using “who’s running what” the discussion nuance is completely bypassed and if the PR is merged on this assumption we can’t go back. and I am left abandoned on the side of the road forever running an old Core or having to fork off, which i don’t want to do currently.
If you want to hurt your node it's fine that you have to go out of your way
move the goalposts and ignore the original question of who’s in the majority, nice 👍
If the majority wants to hurt themselves should we cater to that?
why are we catering to a single set of shitcoining behavior that is producing an extremely small set of utxos which happen to be unspendable then?
if we want to talk about who’s hurting who, citrea intentionally created their shitcoin to be this way, and Core is going to push a change to accommodate their existence.
the next group will come along and push the standardness bounds and what, we’re just going to do this again for them?
how does this have anything to do with “me choosing to harm my node”?
49% of utxos are under 1k sats. We can let them pollute the utxoset more or give them ways to not hurt the network as much.
I guess we just disagree on the approach, either way thank you for actually engaging with me on this discussion, it’s been hard.
for me, this indicates the extreme nascency of the monetary network, and it also ties into misconceptions about bitcoin’s trajectory and purpose.
the sub-1k sat utxos (I am guessing) are probably mostly due to actual transactions of this size being sent around since inception? the actual amount and rate of increase which comes from data anchoring is a fraction. (total utxo bloat is a different story, but if most of that is coming from standardized shitcoining doesn’t it negate the entire argument of aligning incentives?)
altering standardness in anticipation of further growth in non-standard outputs is putting the cart before the horse.
Alterting standardness rules so people create less harmful txs is exactly what we should be doing
right, but we already made alterations to even include OP_RETURN in the first place because of things like colored coins.
citrea, ordinals, et al, are just the latest group to exploit data anchoring.
why should we continue to accommodate when the next group will just come along and force the next update?
this is the wrong approach, we should be allowing the market to increase the necessity of financial transactions. this will price out non-standard bad actors in a much safer and more incentive-aligned way in my opinion.
the question is whether it will take too long and too much bloat will occur in the meantime, to which my answer is a resounding no.
We should because they will do more harm to the chain if we don't
Removing the option altogether is a bad idea compared to increasing it to be high.
Why leave the option if all it does is hurt yourself
Because I personally do not want huge OP_RETURNs. Inscriptions take up less effective block space.
The first PR should have been to disable bare P2MS by default. No one uses it anymore except spammers.
the amount of harm they do assumes they continue their attack indefinitely into the future.
do you not think the cumulative harm would be minimized by the market outpricing these transactions over the next few years (it won’t take longer than that)?
I think they will be eventually priced out. Which is why we should not have them leave permanent damage by have them create unspendable outputs and instead let them create something we can prune
can definitely agree there, but again you are now assuming that the next shitcoin group won’t pop up and find a new non-standard abuse to exploit.
we should not accommodate these behaviors and introduce an incentive to attack bitcoin to get devs to ack changes that are “technically sound”
That just makes no sense.
You just dislike shitcoins more than you want to protect bitcoin
low key fire and I will self reflect on this..
To be fair eventually P2WSH can be used for data storage. Or P2WPKH. Or P2SH. Or P2anything.
What I still don’t understand is:
- What’s the point of OP_RETURN size increases? Inscriptions are cheaper.
- Why not disable P2MS?
Which is why we should make op return the best way to do it because we can actually prune the data
Okay, we can prune the data. But why do Stamps exist? Exactly because P2MS is not disabled, and people want it to be unprunable…
And Inscriptions are cheaper and prunable as well
Op return is the least destructive way to store data. Sure other ways exist but we should make it so people use the least destructive version
but you aren’t “making it so”.
you are encouraging it.
shitcoiners will abuse what they can still abuse.
They are going to abuse it either way, we can't stop them. So make them do it in a better way
People will not use it until we disable P2MS because it’s a similar cost, but one is “unprunable” so they of course want to do P2MS.
Anyone that cares about cost also uses inscriptions. Those will not switch to OP_RETURN for 4x.
We should at least give them the option
Are we sure anybody is actually doing P2MS because it's unprunable, and not because of the datacarrier limit? (and/or to be jerks)
Yes
What protocol(s) are doing that?
stamps
Fair enough, but stamps uses counterparty, and the counterparty FAQ says this about OP_RETURN and prunability: https://docs.counterparty.io/docs/basics/faq/#what-happens-if-and-when-op_return-data-is-auto-pruned
> Counterparty only needs some Bitcoin full nodes somewhere to have an unpruned copy of the blockchain. As every Counterparty full node is also a Bitcoin full node, this is easily done.
stamps references the counterparty behavior as the reason why stamps uses bare multisig and says
https://github.com/mikeinspace/stamps/blob/main/BitcoinStamps.md
> The length of the string means that Counterparty defaults to bare multisig, thereby chunking the data into outputs rather than using *the limited* (and prunable) OP_RETURN.
Since counterparty refutes/denies the pruning argument, it's IMHO safe to conclude that stamps is actually using bare multisig because of the datacarrier limit anyway.
“prunable OP_RETURN”
That’s the end.
why does citrea exist and not use colored coins?
it’s an observation of path dependency.
citrea abuses the current set of standardness, which only exists because of past ‘exploits’.
changing standards to “fix” this just leads to the next abuse, which leads to the next “fix”.
this is ETH. we don’t want ETH.
This is like comparing the bitcoin dominance in cRyPtO. The UTXOs under 1000 sats likely are less than a tenth of a percent of all bitcoin.
You literal have some of the worst takes ever. You must big a big block sleeper cell or some shit.
Because until now and up until the pr is merged we don't need knots, cause we can set limits on core.
That's kinda disingenuous is it not.
The issue here is that every time you tinker with a constraint, it has unintended consequences. There's a social contract with the 10s of millions of people that have invested their time, energy and money into bitcoin that those risks will be managed responsibly.
No changes are happening to bitcoin. It's the exact same thing you invested in, it's just making core's mempool more accurate
Unless I misunderstand NACK and ACK, assuming NACK for against and ACK being for. It would seem majority of reviewers are against it in some part, so not minority.
And I will say I'm not familiar with GitHub eitquette 
But trying to bring to light a conflict of interest, once a post disclosing it was marked as off topic, that seems quite on topic to me ¯\_(ツ)_/¯
Also why can't I zap it you.....
You are correct. NACK means against.
I mean the usernames in each section give it away. But I was trying to air on the side of not sounding like I know everything, cause this technical stuff is a lot over my head.
I'm a left bell curve kinda guy. I know enough to run a node, play with some DLCs back in the day, thanks for that btw nostr:nprofile1qqswrlemlh2wgqc4jkds3d8ueqj9a2j3gcm7r48v9tskdd6rxsd7rtcprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqyf8wumn8ghj7ur4wfcxcetsv9njuetnqyw8wumn8ghj7un9d3shjtnzv4h8g6r9vdshymtpdchxxmmduzd0zn. And I try to stay informed where I can and the big thing I see here as a layman.
Right now I can set that arbitrary data limit on my node.
PR would remove that.
thought nostr:nprofile1qqstnem9g6aqv3tw6vqaneftcj06frns56lj9q470gdww228vysz8hqpzdmhxue69uhkzmr8duh82arcduhx7mn9qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqgdwaehxw309ahx7uewd3hkcam28zl comment was poignant and the issue i think most non technical people have,
Honestly, Guy knocked it out of the park. If bitcoin survives, there should be statues for folks like him in future civilization.
This might help a bit, if you like visual stuff.
& thanks for running a node!
Yeah I was looking for this again, found it yesterday when trying to read up on everything. Thank you
Fixed my zaps