init.quest("SACRED.CARROT")::accept(if("you.giggle"))::follow(clues.through.memes)::decode(glyphs.on.toast)::laugh(3x)::post(1 cryptic emoji)::transmit("I almost got it...")::repeat::never.win()::always.play()

i added his relays. 😏 🚬

Knots will continue to grow as Core merges stuff without consensus.... #bitcoin View quoted note →

do not sass me about data holdings - i know what SALT is. and in the end, private digital "wallets" are the easiest targets. but you do not want to talk about that. or anything else. SALT tax is bullshit, always has been. and trying to somehow categorise medicare/aid as wallet retirements is the essence of elitism and disconnection from reality. data means nothing if you are elderly with dementia, no real medical access, and home insecure. and if they shutdown the government over it, which i wager they do not have the guts to do, everyone will have the opportunity to discuss those things in real ways. cia operatives evading discovery is not a universal problem, and is one i already solved. but you don't want to talk about it. and neither does congress - in reality. View quoted note →

Dramatic irony.

Mindless propoganda about Bitcoin development from people that don't know anything about Bitcoin development is the biggest threat to Bitcoin.

Here we are again. No one gives a damn about node runners except Luke. I'm disappointed in you Jack.

No surprise you'd be on the wrong side of this one I suppose.

Why are you arguing that we arguing “minutia”, if I can just run my own node and Pleb out? There’s no argument, just individual choice. Calling opposition to this change a “dishonest and inauthentic social media campaign” is a fatal mis-step, imo. I try to never have a personal incentive in any serious matter. But its clear, clear to me that the Core dev PR team is desperate, on the ropes, and lashing out.

It used to be 40 bytes for a reason right? I feel overtime we gradually give in on multiple fronts every time while actually, we the node runners, should stand firm. Even though it might result in some short term negative consequences. We can try to grab that by the roots instead of the leafs. Feels like slow dead otherwise.

nevent1qvzqqqqqqypzp6dkfqdu8fn4de5laa6a4wh9xhqa6vmpe86yx3tm6n2a2ha20s7qqy88wumn8ghj7mn0wvhxcmmv9uq35amnwvaz7tmxwfjk2mrp0yh8xmmkvf5hgtngdaehgtcpz4mhxue69uhkummnw3ezuum9v9e8stnfwvhsqgzja9046hc9r4lapegxjzhuta3p8n2m45770z3227mcf4g2pndefqdpe53n

A SOFTWARE COMPANY TELLING ME WHAT TO DO WITH MY HARDWARE. MMMM..... WHERE DID WE HEAR THAT AGAIN? Not arguing with BC decision. It is the way that it unfolded: dodgy moderation on GH, ignoring Luke's PR for spam filters for years and then claming eliminating OP_RETURN limits is to avoid spam, and finally (if they have not change this) not giving the option to manage filtering options on Core UI. BC are free to choose the direction they want. And so are we to choose which software we ran on our nodes. ENJOY THE NOISE

My response to Greg - >>There does appear to be a dishonest and inauthentic social media campaign *against* Bitcon Core. I'll take the blame/credit for this as I've clearly been a major part of it - regardless of if you think I'm acting in good or bad faith. I of course believe that at least I and the others I work with are sincere and authentic. >>Back in 2014 the average block size was only around 160 kilobytes, as a result there was no real pressure to drive up transaction fees and it was extremely cheap to stuff whatever garbage data you wanted in Bitcoin's chain. Some people were storing data by paying to fake addresses which were really just data instead of an address. This is maximally bad because it bloats up the UTXO database with unprunable data, directly increasing the minimum cost to run a node. UTXO bloat sucks - obviously agree. Context though? Zero concern about 4GB -> 12GB bloating from 2023 to present. Sudden concern about Citrea and similar adding a couple of kilobytes a year? Mind if I take apparent concern about this with a grain of salt? Will reiterate further down. >>To address this core devs introduced a 'data carrier' output type also called an OP_RETURN. This is a kind of output which provably can't be spent so it doesn't have to go into the utxo database and can be pruned. Additionally, they limited the size of the data to 40 bytes in order to encourage applications which can just store a hash instead of the data to do that. Later this limit was increased to 80 bytes. Yes. Which was sufficient for anyone who wants to use Bitcoin for data and do it in a plausibly respectful manner like Open Time Stamps does which no one is going to war about. >>The world has changed a lot since 2014: Fees are now not just meaningful but significant, no one is dumping data in Bitcoin because it's *cheap*. People dumping data in have almost entirely moved to dumping data in the witness portion of transactions. Right! >>Major miners no longer enforce this limit, because it turns out they like money (and have denied requests to limit themselves), and if you are willing to directly connect to one its easy to get them mined. Sad. If it was easy the entire motivation for Core's two PRs would not exist. Citrea *want* the advantage of having *all pools* potentially mine their "transactions" - their design means using one pool that solicits out-of-band nonsense is not sufficient, even if they were prepared to pay the extra cost of a service like Slipstream. You are now missing a major chunk of the story. Not to mention the fact that witness-discount enjoying spammers were left to run amok without any consideration of adding Luke's filter which trivially prevented them. Arguments that it wouldn't work are being made by those who now unironically tell us the OP RETURN limit needs to be raised because it will prevent Citrea from using OP RETURN (which is cheaper for them) than fake pubkeys. This is completely self contradictory and somehow none of this is registering for you. >>There are some users who are still creating 'fake outputs' but have said they would change to opreturn if not for the limit (particularly some payment channel thing). Right. So the filters work and the last two years of pretending they're meaningless was complete nonsense. Thanks for admitting it I guess - I wish it was in service of FIXING them instead of REMOVING them. >>Finally, use of hashes for commitments is now well understood and there are over 2 commitments per second flowing into open-timestamps which can aggregate an unlimited number of commitments into a single transaction. As mentioned, no one is going to war over this. Heck, Knots allows 40 bytes of OP RETURN by default as that was never a controversial compromise. >>The limit also causes some harm to all users of Bitcoin, particularly since multiple significant miners ignore it. When you don't already know a transaction (because it never reached you or you discarded it) it takes *much* longer to relay a block to you (at least 3x the delay if you knew everything but potentially much more depending on how much data you are missing), this harms small miners at the expense of big miners increasing a centralization pressure on mining (because when miners aren't on the same chaintip, one one bigger miners are on will tend to win). It also contributes to mining centralization by encouraging direct transaction submission since no one will bother submitting to a 1% miner, allowing the bigger miners to make more money. An inaccurate mempool also harms users ability to accurately estimate what transactions are pending for the next block so that they can optimally bid against them. Yes!! When mining is CENTRALIZED, the huge actors can bully the rest of the network a million ways, including blocks full of unknown transactions causing their blocks to take longer to process, making life harder for the tiny miners on the network. But you are presumably aware that this attack is not prevented by nodes bending over backwards trying to become aware of every single possible thing on the planet a miner might conceivably wish to include in a block. Bitcoin does not require us all to have identical or even remotely similar mempools for any aspect of how it functions. It is also not meant to be relied upon whatsoever should mining become anything like as centralized as it is today. So this point is somewhat ridiculous. Yes, nodes are on their back trying to keep up with how powerless they are in the current environment. But nuking all their mempool policies to try and level the playing field is not remotely realistic as a solution. What you are pointing out here is technically true and utterly irrelevant when put in the current context. Bitcoin running more optimally, has thousands of miners making their own templates rather than relying on a handful of pools. In that circumstance any MINER who starts filling blocks up with consensus-valid, but mempool-rejected junk suffers instead of the miners who don't. Their blocks propagate more slowly but it's *their* problem, not the network's. Indeed, a long forgotten PR into Core in 2016 introducing Compact Blocks specifically warned *miners* that they should update to recent mempool policies in order to reduce their chances their blocks becoming orphaned. We optimize for nodes, not a handful of template creators to which the entire world's hashrate is beholden to. >>So it was proposed that the limit be removed. There are two proposals, one that just removes the limit completely, which is the first and simpler proposal. Then there is another proposal which makes the default unlimited but retains the ability to adjust it. At this time neither of the proposals have been merged, descriptions of this as having been done are just untruthful. I don't know who has made false claims in that regard. I have not. It's a messy situation so plenty of people are making inaccurate claims whether wittingly or otherwise. Sorry but it doesn't invalidate my entire stance. >>Arguments against it don't seem to hold up. Of course they do. Core is optimizing for miner centralization and trying to adapt nodes to accommodate Bitcoin in a state it cannot expect to operate in reliably for much longer. Over 51% of the hashrate is two, fully permissioned, KYC pools. The smaller of the two has 8 or 9 smaller pools it clearly operates the back-end for such as Braiins, Binance Pool, SEC Pool, Poolin', BTC(.)com and a few others. See stratum(.)work for unrefutable evidence of this. Again, they can bully the rest of the network at such a size, and nodes trying to keep up by agreeing to relay junk against their own interest does not actually mitigate that attack. At this point Bitcoin exists entirely thanks to the benevolence of Bitmain and Foundry. This makes us no better than any random cryptocurrency and it HAS to be fixed. Nodes relaying spam against their own interest are simply trying to remain relevant in a context in which they cannot. >>The first category of opposition is basically just accusing Bitcoin Core devs of being in favor of shitcoins or monkey jpegs, having talked to many I am confident that few or even none of them like that stuff (no one I've talked to was in favor of it). But no matter how much they don't like that stuff, that doesn't change that this proposal should have no significant effect on it-- it's unrelated. That stuff doesn't use opreturn today and would cost more in transaction fees if it did. Currently you pretty much never see OP RETURNs between 80 and 150 bytes. Anything in that range remains cheaper than those exploiting the witness discount with inscriptions which only starts to become a net positive above 150 bytes or so. Saying it will have no significant effect is just wrong. >99% of OP RETURNs in the blockchain are 80 bytes or less. After Core get this change through there will be an enormous number greater than 80 bytes. Assuming they will always use the inscription hack once they exceed 150 bytes is also not something we can flippantly do. There are situations where they would prefer to serialize the data instead of break it up into chunks separated by OP_PUSH as is necessary when inscribing. While more expensive, also far more useful as a troll as suddenly illicit data will trigger anti-virus software and make your laptop something you really don't want to carry through an airport if it has a copy of the blockchain on it. Some mitigations have been made in this regard but are only partially in use at the moment. This isn't something I feel like really using to push back on your overall dismissal of our concerns but it's probably worth noting. The more general point is that I'm not saying Core are secretly shitcoiners. I'm saying they're being utterly gutless in putting up a real fight and instead are using a bunch of excuses to discontinue the approach older developers in the space had - telling these guys to f*ck *ff and not constantly accommodate them invoking all manner of excuses - and if you want to be frustrated, try arguing in favour of spam filtration - something we've been doing since Satoshi's time - while people invent horror stories about what it might do without any historical precedent whatsoever. Again, Bitcoin does not require that we have identical or even similar mempools for any aspect of what it does. Miners can only attack us if we filter if they are in a position to take over the whole network anyway. Fee estimation, miner centralization, UTXO bloat. These are all little more than scare tactics here. You know how fee estimation works in Bitcoin Core. I'm willing to own the mistakes and inaccuracies made by people on my side of the aisle here. But how about Core stop making these technically-true points about fee estimates, miner centralization and UTXO bloat which become meaningless when put in appropriate context? Random Twitter anons and mysterious self-deleting reddit accounts - yeah I'm going to hold Corallo, Todd, and you to higher standards then them. So please stop invoking these nonsense arguments. Spam filters *do not come with tradeoffs anyone actually needs to worry about*. Yes they exist, but they are being exaggerated beyond all reason and burden of proof is on those who want to remove them - not us. >>The next category of opposition is just general opposition to 'spam'-- again this proposal is largely unrelated because spammers won't use this, and to whatever extent they do it'll be good news (either moving from utxo bloating fake outputs or increasing their costs). It's an incidious argument because most contributors to Bitcoin core believe there isn't much meaningfully more that can be done about spam: Miners have bypassed the filters that were there, fees have excluded all price sensitive spam. Bitcoin was designed to be censorship resistant and depends on censorship resistance to work-- and a fact of free speech is that it means it allows both speech you like and speech you oppose. Arguments are made that blocking this traffic isn't morally equivalent to censorship. Perhaps! but it's still substantially *technically* equivalent. But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam. "Spammers won't use this" - already addressed above. There is sweet-spot territory being unlocked here. You're completely ignoring the 81-150 byte range of currently inaccessible OP RETURNS which magically no one uses despite the only thing protecting it being these apparently useless filters. "UTXO bloat" - right. As mentioned above UTXO bloat is terrible, OP RETURNs are better. True! Now am I going to take the concern expressed by Matt Corallo about this as genuine? Well let's see, the lack of action/filter upgrades in 2023 has resulted in the UTXO set jumping from 4GB to 12GB. It did that in a little over a year. Any effort to counter to this was met with (what appeared to me to be) entirely manufactured controversy which resulted in the PRs being closed - see

GitHub

datacarriersize: Match more datacarrying by luke-jr · Pull Request #28408 · bitcoin/bitcoin

Updates -datacarriersize to be effective with newer datacarrying styles.

and

GitHub

set `DEFAULT_PERMIT_BAREMULTISIG` to false by Retropex · Pull Request #28217 · bitcoin/bitcoin

The default activation of the permitbaremultisig=0 option proposes an enhancement for the Bitcoin network. By refusing non-P2SH multisignature tran...

The latter of those two would have specifically address the concern about UTXO bloat caused by "stamps" spam which was created by "MikeInSpace" who announced proudly that he wanted to do as much harm as possible. His plan worked and now thanks to what he and others did, along with what I will admit as making me extremely frustrated with Core - it basically become impossible to sync a node on a Pi4. Took ~40 hours or so in 2022. Now it's months. I get it, Core can't merge controversial PRs. Even if I sense that the opposition to them is financially incentivized to gaslight everyone to the tune of "what even is a bitcoin transaction" which thankfully you don't see to be doing - that is REALLY appreciated by the way as pretending spam magically doesn't exist because it costs the spammer money has been one of the more infuriating arguments made over the last couple of years. Anyway, our concerns and the controversy we kicked up over the recent OP RETURN PRs however did not simply result in those PRs being closed. Core seemed to find whatever moderation policy they could to justify shutting us up and continuing to push these things through. So current context for concern around UTXO bloat? A few kilobytes a year from Citrea who could easily redesign their product to fit within what the spam filters currently allow. Instead we seem intent on changing our filters to accommodate them, defeating their purpose simply due to the minuscule threat of UTXO bloat that is a drop in the ocean compared to what's been happening in front of our faces for the last two years. I'm sorry, there's just no way that's a genuine concern. "Miners have bypassed filters" Yes. They have, and it's a pain in the ass for them and super expensive. *There is a reason they want the efficiency of having 85,000 nodes relay their junk around for them for free instead of having to use a private service for it*. Please, for the love of God stop pretending the two situations are equivalent. Dark mempools are horrible. They're far more expensive and they have to regularly wait hours for blocks instead of ~10 minutes. Incentivizing Citrea to just use 40 (or 80) bytes of OP RETURN is the approach to take here. Not ripping filters out due to threats of laughably small amount of UTXO bloat. "Censorship resistance" Spam filtration is not censorship. I'll paraphrase Luke - censorship *fails* if one "bad" transaction makes it into a block despite most miners rejecting it. Spam filtration *succeeds* if one miner mines a block that rejected any spam. They are opposites. You do not need spam filters to be 100% effective, you have pointed out that they are not and thus conceded that they are not an effective tool for *censorship*. "But, again, this is all a distraction in that the proposed change shouldn't meaningfully facilitate any new spam." As above, you'll see several orders of magnitude more OP RETURNs of size 81-150 bytes. And I would wager many above that too that you almost never see currently. >>Ultimately the subject is deep in the minutia. It won't make a difference to your usage of Bitcoin. The only really concerning thing I see in the subject is the degree that people have successfully weaponized misinformation to direct a lot of entirely undeserved abuse at contributors to Bitcoin Core. ... who had only just started discussing a proposal when they were waylaid by a flood of disproportionate comments and falsehoods. "weaponized misinformation" I've definitely had to learn a lot during this discussion. People have scars from prior wars. I believe Core should be adding filters and it is negligent to not have done so. I believe their justifications for not doing so contradict the current push to relax filters and the apparent inconsistency of what is asserted about mempool policy as a tool for spam mitigation makes Core look like bad actors. If I am wrong about any of this I apologize. If you want to respond then great, I will not request further interaction as you've already expressed elsewhere how annoyed you are with the OCEAN team for all this. However it is certainly not just us in this fight. There are definitely those with their own anti-Core agenda who don't necessarily align with me on spam who are just making use of an opportunity to undermine them too.

Bitcoin Mechanic:

Holier than thou Bitcoin core

I had high hopes that you’d be on the side of the node runners! But I get it—we're just the little guys, struggling to scrape together fiat to buy those pricey ASICs. It totally makes sense; why would you turn against your biggest potential clients? Maybe I’m just venting my frustrations right now, but I truly believe the genie is out of the bottle! We’re gearing up for a major victory, and changes are coming. We're ramping up the filters and shifting the consensus to reject off-curve pub keys. Let’s make this happen!

Luke seeing this meme:

🫡

Nope 🙅

nope. i for one care too... :)

Et tu, jack?

Layed it out very very well, thanks

Feels like little defeats over the course of time, a slow dead. Stop that and fight back. Knots, at least for now, I think is the way to go

Fuck Those cunt tards. Permissionless means...PERMISSIONLESS. Though Greg's take holds truth. It highlights a problem in human nature, not the bitcoin network. Why should bitcoin have to adjust to human nature. Worst part, filters won't fix anything.

👍💜

JFC. This is becoming borderline pathetic at this point. 🫠

their still has to be some laws in free countries.

And tards apparently.

Luke, you, and the Ocean team actually DID something against mining centralization. That is the simplest strong argument to NOT silence and, better, take your word seriously. Keep the good work Mechanic, behind you, legions.

Down with Bitcoin core and all centralized tyrants

I see a lot of people missing the very important difference between mempool and block validation. It bothers me to see this entire giant argument without addressing it directly. For block validation there never was a limit, only in mempool. Node runners have never had the power to fork over any op_return unless it doesn't fit in the base block. As long as that is the facts, changing a mempool filter doesn't give any existing node runner control to mining firms. It is only letting go of an illusion. Also, knots filters still work only because core is not using them. Information Theory and lived experience of everyone who has ever written a regex is clear, a new way around every filter will be found. The "attackers" haven't changed methods because there aren't enough knots nodes to impede them. Every new filter we add is more code attack surface in core that has to be maintained and updated forever. Every new spam attack requires a new filter. Or we could trust that in time the monetary premium will self solve the problem.

Sad to see that Jack has taken the side of the shitcoiners that want to ruin Bitcoin as money (and as anything useful for humanity). nevent1qqs040p9lqhyw9vjxc5zr225q0lk5eqsfrgm326d03f5zdflfpuzaegpzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgun7me7

GOAT

(🙏 I’m extremely Sorry for spam but it’s an emergency ❤️‍🩹 #startsmall ) Hello @jack sir, I am Sid, a gold artist. I need your Help Please 🙏 I kindly request your few minutes please on my Primal Note on my profile 🙏 It’s genuinely an emergency for us, From my Job, to my family, our house & endless Medical bills❤️‍🩹 I can share any proof to verify everything, But please save me & my family, please 🙏 Thank you 🙏

Sid

Hello @jack Sir,
Sid Soni here from india. 

I need your Help, Please save us 🙏

I’ll try to keep this as short as possib...

Greg didn't have anything new to say. We're at the point in the argument where we just keep repeating the same points over and over, and nobody is likely to change their mind. Thank you Mechanic for once again calmly explaining the the pro filter position. No need to apologize. Greg is being ridiculous claiming there is a "social media campaign" against core. There is a lot of unhappy users. Is that what he means? This is a classic dishonest debate tactic: Turn yourself into the victim of some imaginary cabal to gain sympathy. Greg needs to be better than that.

He isn't Core, very long time since he was. So he's this well respected but long retired pro who I would really like to discuss this with. There's a reason everyone is quoting him. I agree he is being stupid about this.

If you allow silly second layer protocols like lightning to be expressed then this is the price that has to be paid. You're right to be concerned because this is the path that etherium took and look at it now.

Yes 💪🤝

Technocrats trying to control tech is nothing new. FUCK YOU @jack

Deceiving or lying only hurts people. It's obvious.

Respect!

👍🏾💯

It is time to change tact The whole world running the same implementation code is too much of a honeypot for those wanting to manipulate Let's all remember: We run an anti-centralization solution

Thank you, this helps.

Exactly, I'm disoriented by the mid-wit nature of his response when he's blown my mind so many times in the past.

What kind of bitcoiner?

Me too, no one is gonna shit in my bed without me kicking it's ass.

Jack's always been on the right side of History. He's impossible to compromise, and would never lie to people about really what's going on behind the scenes.

Serial killer