GrassFedBitcoin
Bitcoin Mechanic

"If you do that the spammers will just...."
I know. That's the point. https://image.nostr.build/095c2ba80330c47fa434a4c07eadcea55bc8c7f3eb006cfdde522930aebed27d.png

2025-05-19 16:44:20

Clarification of my thoughts and a brief explanation of how I get to where I am currently for anyone interested:
Miners and nodes were originally pretty much the same thing.
They aren't now.
What happens when the incentives of miners and the incentives of nodes become misaligned?
Miners want to get revenue from any source imaginable - stuffing spam into blocks is potentially lucrative.
Nodes of course do not have any immediate incentive to relay this stuff and certainly don't benefit from storing it or competing with it and paying higher transaction fees as a result.
The theme coming from
@darosior
is that Core must do what is incentive compatible for *miners* - i.e pay attention to what it is spammers want to store in the chain and quickly or preemptively adapt Bitcoin Core as quickly as possible to relay this to prevent any large miner soliciting it out-of-band and developing a competitive edge against miners who are "stuck" with the transactions being relayed around the network.
His concern compounds with the idea that if Core fails to do this, it will be unadopted and lose market share to an implementation that does.
However we have seen significant migration away from Core, for perhaps the first time ever, to Knots, which takes a different approach - it concerns itself with the incentives of people running those nodes who, as mentioned, do not wish to be relaying junk data around the network and storing it for free.
So if we are concerning ourselves with the incentive compatibility of Bitcoin Core, why is the incentive the actual users of that software to not participate in spam not a part of the discussion when it is so clearly relevant? Knots has jumped to about 10% of the listening nodes over the course of May from less than 2% before that.
This, I believe, is where the rift between Core and those angry with Core formed because Core's response to this is generally to say that nodes are being short-sighted. Their desire to reject spam is going to undermine more subtle things in the longer term. This was expressed initially in a crude and insulting manner which further deepened the rift but - no matter how much we might want to dismiss them as genius devs somehow missing the forest for the tress - are they correct?
More simply - are nodes doing themselves a disservice by opting out of the relaying of spam in the hopes that at the very least, they aren't participating in the hypershitcoinization of Bitcoin?
How bad are the tradeoffs for nodes if they do this?
1. If Core is "incentive incompatible" (at least with regard to miners/spammers who both clearly want to use Bitcoin to store non-Bitcoin stuff) is there going to be un-adoption of Core?
So far the only un-adoption we have seen is a (from my perspective) a few thousand nodes switching from Core to Knots - this isn't really fakeable like some suggest with AWS because you'd have need to have spun up Core nodes far in advance of this battle in order to send this signal by having them switch.
The "incentive compatible" alternative is Libre Relay - this of course does the opposite of what Knots and its updated filters permit - it preferentially peers with fellow trash-enjoying nodes in what is (to my mind) a misguided effort to fight what they call censorship. Of course I fundamentally believe that censorship resistance doesn't come in the shape of nodes relaying what is against their own interest.
Libre Relay is nowhere near as widely adopted as Knots. So Core, if wanting to maintain marketshare must take more into consideration what has actually happened to Core as a result of its incentive incompatible design (from the perspective of *nodes* rather than *miners*).
They must convince us that Knots users are making a mistake in philosophy, not just more immediate concerns around practicalities and risks of running something that isn't Core. Those are valid of course but let's assume Core and Knots are of equivalent standard and reliability and just focus on differences in approach and design philosophy here as its what is relevant to this discussion.
2. If we filter spam, fee estimation will get worse.
It can get better actually, assuming there is one decently sized miner on the network respecting those filters. There is of course - most of the DATUM miners on OCEAN use Knots with fairly close to default policy so this can prevent you from *overpaying* fees.
The worsening of fee estimation in the other context - accidentally underpaying because there's so much unconfirmed spam that you just aren't aware of - is much easier to correct for. Simple RBF will suffice.
I don't think it's anything anyone can really care about due to the unpredictable nature of the blockchain anyway. You have no idea if you'll be in the next block or not. The extent to which you do is the extent to which we "know" what *should* be in the next block which is basically just an artifact of centralization and a mistaken celebration of that fact.
You don't know who will find the next block, what will be in it, how long it will take, or how many other people are going to jump in "the" queue after you broadcast your transaction. Core's heuristic around fees work well without knowledge of other people's mempools, this is by design. Thus, I have widely asserted that concerns around fee estimation are nonsense with the above reasoning and I have yet to have anyone dunk on me with some superior understanding.
3. Block Propagation will be slower if we filter spam. Mining will centralize in general.
Slower block propagation sucks for small miners trying to be part of the big club as Antoine points out. The big boys will have a private intra-relay network - a walled garden in which you must belong to not be at a disadvantage with necessarily slower verification times.
Firstly - if you filter something that still generally makes its way around the network, you'll cache it and your verification speed will be just as quick as if you didn't filter so this is a non-argument. I genuinely think most people, including Core devs are just unaware of `blockreconstructionextratxn` so they believe there to be an issue that there just isn't.
But what if the filters are so effective that the private club has to solicit this stuff out-of-band and it never existed in the first place to the filtering nodes?
Then I say we are screwed. These miners control the blockchain at that point. We have concerns orders of magnitude more significant. They can reorg the chain, make double spends and generally wreak havoc. The fact that they haven't is not something we can rely on hence the need to actually decentralize mining not just screw around and make a gesture of concern in relaxing spam filters in the hopes that it doesn't get slightly worse.
We are at this point already so I have no idea why we are discussing inconsequential factors such as spam mitigation vs enthusiastic relaying as though it has any relevance here. Foundry can already 51% attack the network.
---------
This is roughly how I end up at my position - being a vocal advocate for putting the incentives of those running nodes over anyone else in the ecosystem. I do not consider spammers to be "Bitcoiners" but even I did, their needs would be always placed further down the food chain than those of nodes. Just as they were with those who wanted huge blocks for permanently cheap transactions.
The rate at which I am having to revise and reevaluate my position has rapidly decreased compared to a few weeks ago where admittedly I was making far more technical inaccuracies than now.
Everything I read from Greg Maxwell or other long standing and respected developers in the space goes along familiar lines at this point and fails to justify this new, laissez-faire approach to spam attacks that carries a heavy burden of proof versus adhering (as Knots does) to Bitcoin's historical precedent where folks none other than Greg himself would propose extreme counter measures to spam should some new protocol for shitcoining-on-bitcoin suddenly hit escape velocity and start creating a genuine problem for Bitcoin nodes.

2025-05-17 15:22:14

Just unblocked the kitchen sink.
Nothing stops this drain.

2025-05-16 19:32:55

When a miner starts making their own blocks with DATUM
https://image.nostr.build/8242a5302200fb3f060dce533a31b700b9bbffc72361cb4906ad5e3111a5feea.png

2025-05-14 00:41:26

Spam filters mean there will be less spam.
If you're worried about side effects like centralization of mining or UTXO set bloat then let me know when you're ready to take those problems seriously instead of LARPing about it and nuking OP RETURN limits.
UTXO bloat and mining centralization are *serious issues* in Bitcoin.
You don't get to do absolutely nothing about them for years then invoke them when coming up for convenient excuses for killing datacarriersize.
Mining *is* centralized. There's no amount of bending over we can do relaying the stupidest trash possible around the network appeasing miners and scammers that can roll back the tide there just in the hopes that MARA becomes less motivated to maintain Slipstream.
Where have the serious people gone?

2025-05-13 06:58:00

- reply

The giggling haunts me. These people are children.

2025-05-13 05:31:54

- reply

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 https://github.com/bitcoin/bitcoin/pull/28408 and https://github.com/bitcoin/bitcoin/pull/28217
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.

2025-05-13 04:02:53

- reply

We've outpaced difficulty so far this year? The hardest part is getting the first couple of EH. We did that already so I'm pretty confident in it.

2025-05-12 18:59:51

- reply

This is more appropriately done at the policy level. This has always been how it's approached. Obviously it doesn't work if ideological gaslighting happens to the point where people abandon doing things that way.

2025-05-12 18:32:51

Core have given up trying to deny users the ability to configure datacarriersize - definitely stepping back from the ledge so that's progress.
What remains is a new default that will be 2,500x the size of what it is currently.
Remains ridiculous, sorry.
Core nodes should not - by default - cause users to relay more non-monetary activity around the network than necessary as it is obviously not in their interest.
40 bytes - the old default - was reasonable. This allowed side chains and hashes of however much data you wanted.
80 bytes was an unnecessary compromise.
Changing it to 100,000 bytes by default which is "all" the latest PR does is reckless.
The excuse that "at that size, the inscriptions hack is cheaper anyway so who cares" is not valid.
The solution is to implement the fully functional filter that makes life harder and more expensive for inscribers - not blow out OP RETURN limits which provides an easier, if more expensive method of doing what the inscribers are doing.
Fix the filters. Stop trying to play reverse whack-a-mole appeasing spammers constantly pushing for changes to Bitcoin.

2025-05-10 18:37:07

Filters = Node sovereignty
No filters = Help miners out with their side-gig

2025-05-10 17:27:30

- reply

Which is why Luke's site excludeds AWS.

2025-05-06 21:13:55

- reply

Can do

2025-05-06 17:53:04

Bitcoin is amazing.
So many celebrate what it does.
So few understand that what makes it great is what it *doesn't* do.

2025-05-05 22:10:24

https://image.nostr.build/6c805310f13fad55b311653a398c58e7aff1d023a6b1f1e7f45c122e0cd7403b.jpg

2025-05-05 05:39:29

- reply

op return is "the least harmful" way to store this stuff for the reasons you cite, but it's also 4x more expensive (simplifying because it's less expensive if storing smaller amounts) - so plenty of the time OP RETURN is preferable for spammers *and* the network which is the supposed rationale for all this. Obviously taking all that in isolation is foolish, but that's the steel man.

2025-05-05 03:44:59

Apologies for lack of op return war 2 content on here.
Happy to start something off here if anyone has questions.

2025-05-04 05:14:28

- reply

any abandoned attempt on github even?

2025-05-04 05:13:07

- reply

my concern is missing stuff. i'm OCD about it, and sometimes things just get missed on here.

2025-05-04 05:11:06

Is BOLT12 on Nostr a thing yet?

2025-05-03 18:16:32

- reply

yes

2025-05-03 00:16:47

- reply

Hard to say, this aint the kind of network with official stats ya know?
There seem to be about 1000 listening Knots nodes out of 21,000 total. https://image.nostr.build/7226025d665b644782a9ae1b290f567d990f3d50bdd8c1302775eaa784887abc.png
Non-listening is only tracked on Luke's site but it takes forever to update so basically hasn't moved yet.

2025-05-02 15:14:11

- reply

Shoot me a DM

2025-05-02 00:21:57

Well hello there https://image.nostr.build/fca0d683f73430bbef5272559eb4df2bcbad21cc249465045b847bf97cf7394e.png

2025-05-01 06:56:37

- reply

Appreciate it 🙏

2025-05-01 06:34:10

https://www.youtube.com/watch?v=15biQH1H140

2025-04-30 00:48:09

- reply

Trying

2025-04-29 23:20:47

- reply

because nodes aren't free cloud storage

2025-04-29 23:09:30

Hypershitcoinization

2025-04-29 18:51:48

- reply

Correct.

2025-04-29 18:24:59

- reply

opposite, knots users retain control of their mempools. Core seek to deny this.

2025-04-29 16:07:45

It's YOUR mempool.
Peter Todd doesn't get to tell you what goes in it.
Miners get to tell you what goes in the blocks in your local copy of the blockchain *if* they meet a massive PoW requirement that fits within consensus rules.
But "you are not allowed control over what goes into your mempool anymore"
As I said yesterday, it's over if this gets merged and it looks like Core are ignoring all the push back and accelerating it.
https://image.nostr.build/7b81b24a50feff01b1de1354c34ceec19c65f202dc7042e08360dfa87feaa988.png

2025-04-28 23:19:41

- reply

I'm not attacking you, I'm highlighting the conflict of interest as it's relevant to the discussion.

2025-04-28 21:48:16

He attacks Bitcoin
This motivates a major change to Bitcoin
In the resulting discussion on github, he approves of this change (that is motivated by his attack)
If you point out this conflict of interest - no matter how politely - you will be banned.
@npub1qny…95gx hope you're paying attention to all this
https://image.nostr.build/2cd9e5ad50de5b2c367a47a586bf8100c22ce187de599fa8b5b6025a5196adab.png https://image.nostr.build/7eebf6927f100a8a6ee0fdd1a24bdb81b066809441c6ac00545008c01953c2b8.png

2025-04-28 21:09:28

I have avoided inflammatory language for the last 2 years and tried to remain a cooler head despite how passionately I've disagreed with Core.
But it's undeniable now. Bitcoin Core is overtly malicious and attempting to destroy the one chance we get at breaking away from fiat.

2025-04-28 12:16:07

- reply

Delete this

2025-04-27 21:40:43

"Miners can just put malicious stuff in blocks, so disallow nodes from having any say over whether or not they can reject that stuff from their mempools."
Wakey wakey everyone.
The heart of the issue with Bitcoin Core is this: They are seeking to disallow Bitcoiners any means by which they can decide what does/doesn't end up in their mempools.
This is a critical and almost-never discussed aspect of what makes Bitcoiners sovereign.
You are not running a free service for miners where you must seek and relay to them whatever pays them the most.
Your node is yours to do with what you deem appropriate.
https://image.nostr.build/5762e931d3bc4b912da1de25aee68a09a8d88114ee97560ab32b72d446e953ba.png

2025-04-24 21:10:25

- reply

What distro?

2025-04-24 20:48:37

In this situation again. Make it stop. https://image.nostr.build/ae0a1f38ea0a472f5c7a62d585aeaecc20a273e2722a1de8e76f8ed915b42671.jpg

2025-04-23 15:22:02

- reply

People love to speculate. No one knows what price will do short term. Long term, fiat is dead.

2025-04-22 14:39:28

Bitcoin is a great way to make politics something you can increasingly just ignore.

2025-04-20 03:01:20

Go zap this guy
#nevent1q…0vgf

2025-04-20 00:35:01

You can just make custom front ends for @npub1qtv…7dze !
Shout out @npub1ze4…7r97
https://image.nostr.build/381e84e1e0292708a8628aa3544f7c14149aa910322d156e78df2297854dd9ad.png https://image.nostr.build/8791ad4fe75d652a11d9fd741a60c8ccddf87354ad934310fb85e8023df4b8f0.png

2025-04-20 00:06:01

- reply

It uses Lightning natively so very well setup for an eventual solution. Heck, I already pay for good relays.

2025-04-20 00:03:49

If the news is X, don't think about X.
Think about why someone would want you to be thinking about X.

2025-04-18 19:43:27

- reply

MotherOfGod.gif

2025-04-17 00:10:14

- reply

Hi!

2025-04-16 19:52:38

84K gang

2025-04-15 06:33:34

How to actually configure DATUM:
https://github.com/BitcoinMechanic/datum-setup-instructions

2025-04-15 01:51:00

Install a Bitcoin node and a DATUM gateway on Debian from scratch:
https://github.com/BitcoinMechanic/datum-guides?tab=readme-ov-file#debian

2025-04-15 01:23:49

Installed Amethyst on new phone. Every message is now an unread message.
Send help

2025-04-14 20:44:29

Must. Not. Feed. Trolls.

2025-04-13 17:08:47

- reply

It's Bluetooth dude. We will be kardashev type 5 before Bluetooth works properly.

2025-04-12 23:54:48

Run DATUM (and a Bitcoin node!) on Windows:
https://github.com/BitcoinMechanic/datum-guides

2025-04-12 01:27:10

- reply

loads

2025-04-12 00:04:58

almost finished with the guide for running DATUM on windows.
it starts - as is tradition - with instructions for how to install Linux. (WSL).

2025-04-10 02:29:12

- reply

savings in fees applies to all new shares starting the moment you start with datum. prior shares submitted before continue having the non-DATUM fee

2025-04-10 01:26:16

- reply

it doesn't go away. anyone can mine to that address with or without datum

2025-04-09 01:32:37

Bitcoin Mining: Spending a few grand on a machine that will consume $150 of electricity to mine you $80 worth of Bitcoin every month.

2025-04-07 19:45:26

- reply

in the fast lane

2025-04-06 18:43:30

Uploading arbitrary data into Bitcoin’s blockchain is just storing data on other people's computers without their permission and taking advantage of the fact that they're trying to be sovereign Bitcoiners.

2025-04-06 17:32:57

https://image.nostr.build/1761b2a7824ca39b74e231bf342a600a5432a632fd7f8d047c57f70f0d7277d8.jpg

2025-04-04 17:24:00

- reply

ofc

2025-04-04 14:33:54

- reply

50% discount on fees on OCEAN. Sovereignty. Make Bitcoin decentralized again.

2025-04-04 14:10:13

- reply

Yes. It depends on how you use "solo"
Solo really means making your own blocks which is what DATUM does even if you're pooling.

2025-04-04 13:06:55

Good morning @bitblockboom (are they on Nostr?)
Today I'll be giving a demo on how to turn a basic, fresh slate Debian machine into a fully fledged DATUM box you can use for lotto mining or pooled mining on OCEAN.
You'll be amazed at how easy it is.
1pm, wherever the workshops are.

2025-04-04 02:22:10

- reply

gotta upgrade to 'onyx' bro

2025-04-03 16:49:42

airlines be havin' more "boarding zones" than seats on the plane

2025-04-02 15:29:57

- reply

sorry. lol

2025-04-01 20:28:49

"vibe coding" is not a new concept.
it just used to be called "python"

2025-03-30 22:49:48

First back-2-back! https://image.nostr.build/b690c3911e59b4b965e3cb03e82a8eaed838f6f2bf4677d9e96183c39f4736e4.jpg

2025-03-25 19:24:31

https://image.nostr.build/9179ba47094373329a4fd4ba13dd9dc01bba308873fea4b4b4bdc63800af712b.jpg

2025-03-25 11:53:03

- reply

demographics

2025-03-25 11:51:28

- reply

America is better than Canada.

2025-03-25 11:25:37

Doesn't matter who wins the election, Canada is done.

2025-03-25 01:58:14

- reply

you have no idea what you're talking about

2025-03-25 01:54:17

- reply

his record execs and a bunch of parents looking to score a pay day

2025-03-25 01:39:31

- reply

bet they all took the jabs.

2025-03-25 01:28:45

Michael Jackson was incredible.
The lies they spread about him were a digrace.

2025-03-24 23:38:33

- reply

https://www.youtube.com/watch?v=TEGgvEexs-Q

2025-03-24 23:20:15

- reply

dude, it's a bullshit "gocha" that isn't gonna work.
https://njump.me/nevent1qqsqlzkpqp0h387qmuf6cm788zrm4q2zrq94mxsl8nnw3t5smgjrgpqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygr5llz3escp2r8hndktx9kn59w0xv4t9x3clmy7kjz2k9236mgc2cpsgqqqqqqskzprgl

2025-03-24 23:14:00

- reply

https://njump.me/nevent1qqsxzcyuelrdjf7t9f7tm58l3mz3gev7uvt6mp765hkkp7etsd00hucpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgs8fl79rnpsz5x00xmvkvtd8g2u7ve2k2dr3lkfadyy4v24r4k3s4srqsqqqqqp6x5z3v

2025-03-24 19:44:59

- reply

No, we broke one part of what Samorai did by allowing less arb data. This stemmed from a decision in 2014 that they decided was all about them despite not existing until four years later.

2025-03-24 19:37:46

The stupidest FUD against OCEAN since "tHeY cEnSor cOiNjOiNs" just dropped.
Shoutout to @npub10m6…tff3
https://image.nostr.build/b2c6af73f4329cca8b9ea65fbb851f99fc8a90beaeb824ee9f6fdc4893d78be0.png

2025-03-24 19:12:06

- reply

reconsidering what? your hallucinated policy of not broadcasting blocks we dont like in a totally effective way to prevent them getting in the chain?

2025-03-24 19:02:34

- reply

And OCEAN being one extra node broadcasting a solved block somehow fixes that does it?

2025-03-24 18:58:06

- reply

so make sure your node is well connected obviously?
the concern troll you and econo are attempting is embarrassing.
the idea that a pool can exert censorship by leveraging its supposedly superior connectivity is a joke. come back when you're ready to be serious.

2025-03-24 18:41:12

- reply

Dude, broadcasting blocks direct to the network > getting the pool to do it.
If you don't understand this you're a moron.
Yes OCEAN could be stupid and refuse to broadcast a block if it wanted, but it isn't unique compared to any other node. YOU can refuse to broadcast OCEAN blocks if you want with your node. Is it going to have any effect? No.
https://www.dsn.kastel.kit.edu/bitcoin/videos.html

2025-03-24 18:38:34

- reply

Every share is tied to an address. Multiple people can use the same address, the same person can use multiple addresses. There is no continuity - otherwise trolls could mine to "your" address and mess things up for you. Instead the only thing that's possible is for people to mine Bitcoins for you.

2025-03-24 18:31:28

- reply

Exactly.
To add some nuance - we don't exclude "them" if they start submitting shares with bogus splits - any work they did before that's still in the share window remains qualified.
There's no concept in TIDES of identity or people.

2025-03-24 18:03:53

- reply

You seem to be under the impression that a pool must broadcast a block to minimize risk of it being orphaned. This isn't remotely true and was a weird part of your celebration with the FutureBit block last month.
Blocks are tiny and propagate really fast. We....kind of fought a war about maintaining that. Remember?
Really don't appreciate you asserting that I'm trying to be disingenuous or evasive here, you genuinely don't seem to have a firm grasp of where the bottlenecks actually lie.
You're imagining that it's better for a miner to tell a pool about a block and leverage their supposed superior connectivity rather than tell the network about it directly.
Amazingly, adding a middle man only slows things down.

2025-03-24 04:40:54

- reply

you're a solo miner.

2025-03-24 04:34:37

a lot of ocean hate is straight up people just not learning how it works.
#nevent1q…my8q

2025-03-24 04:33:42

- reply

because miners are the ones making the templates.
it's as simple as that.
decentralized reward coordination is a separate issue and utterly irrelevant to Bitcoin, regardless it is being figured out but it is extremely difficult to manage in a scalable way.

2025-03-24 04:31:17

- reply

the block goes directly to the network from the miner via their own node. have you really not looked into how datum works?

2025-03-24 01:31:06

- reply

6 digits

2025-03-24 00:27:26

- reply

no fan of that either for basically the same reason

2025-03-23 22:55:35

- reply

the network wouldn't which is what's relevant