Imagine if we could put an AI agent in charge of maintaining your Amethyst. You could just write a DM to the agent asking for a new feature, the agent would change the app in place and give you back to test. If things work well for you, you could submit the change to your friends. If enough of your friends like and use it, the main repo could take that in. Maybe that's the future we want.

I was at the supermarket buying groceries and the machine said "Enter PIN" and then right below it showed my PIN! I was like "What?! Don't show that" and I leaned in to cover it up. Then I realized it was showing the price of what I was buying.

Anyone in Vegas a day early and wanna hang out?

When you're locked into buying house and have to sell in a price pump 🙁

This is straight from the source: Bitcoin Core’s own developers have merged PR #32359 to remove the OP_RETURN limit in the next major release. Check the official GitHub announcement by Greg Sanders on May 5, 2025.

>> Repo reference: bitcoin/bitcoin PR #32359

The world’s about to change-don’t blink.

The removal is not yet live on the current mainnet version, but it is finalized and will be the default behavior once the next release is deployed this month on version 30.

So mempool is only useful for fees. 🤔

Wonder how you could structure fees and have tx's submitted directly to a pool's node for GBT usage?

Most people think Bitcoin governance is decentralized. It’s not.

Here's the uncomfortable truth:

You don’t need 51% of miners to change Bitcoin.

You just need 5 Core maintainers and a network of node operators who click “update” without reading.

That’s not decentralization.

That’s blind trust in a gatekeeping elite.

Here is how.

Bitcoin's 51% hashpower rule protects against double-spends, not protocol changes.

Changing the rules requires consensus. but in practice, consensus often follows the code, not the other way around.

When Core maintainers approve a change, it propagates silently.

Most node operators don’t audit code.

They trust.

They comply.

Exampl: #OPRETURN

Core removed the 80-byte limit with almost no discussion.

Thousands of nodes implemented it automatically.

Most had no idea what changed.

That quiet change triggered a silent revolt:

#Knots node usage surged 137% as informed operators rejected Core’s move.

But let’s be real:

That’s a small, technical elite.

Most #node runners are flying blind.

This creates a hidden centralization vector:

#Core devs don’t just write code. they decide which changes even get considered.

If they don’t approve it, it doesn’t reach the network.

They control what’s ‘acceptable’ and that shapes Bitcoin’s future more than most realize.

They decide which changes are “reasonable.”

And that shapes Bitcoin’s future. far more than people admit.

This isn’t about malice.

It’s about structure.

Complexity creates dependence.

And dependence creates power.

#Bitcoin’ s biggest centralization risk isn’t hashpower.

It’s the silent authority of trusted code maintainers (of the most dominated node sotwares out there) and the myth that decentralization protects us from that.

What's a use case for a node without a mempool?

#asknostr

At btc++, 6 bitcoin core contributors "concept ack'd" my idea change to bitcoin core

When sending money, these 2 commands are available

- sendtoaddress

- sendtomany

When mining a block on regtest, this command is available

-generatetoaddress

Let's add generatetomany! This would be useful for simulating protocols that send money to multiple recipients directly from a coinbase, as several pools do now, like ocean and braidpool.

Unfortunately, I don't know C++. But if *you* wanna be a bitcoin core contributor, consider writing it and do a PR!

People who "concept ack'd" this change were:

Instagibbs

Antoine Poinsot

Luke Dashjr

Jameson Lopp

Peter Todd

I forget the other one but it might have been Matt Corallo

Went to see blood incantation.

All life is temporary, what lasts is consciousness.

Thanks for answering my questions. There should be a FAQ or chatbot to answer these because i doubt im the only one a bit confused. And things got dramatic so quickly.

Anyway, if you still dont mind 😬... does most of today's spam fit in the 157 bytes? The op_return i quoted, for example, is how large?

With wider adoption of stratumv2, wouldnt it be more likely that a public method of broadcasting transactions would come to market? For example, i could see projects broadcasting their non standard txs on nostr and miners having simple clients to grab and add those txs to their mempools. Could leaving datacarriersize alone help boost stratumv2 adoption in this way?

For spam less than 150 bytes, here is the tier list:

Lowest cost option: unfiltered op_returns

Middle cost option: unspendable outputs

Highest cost option: private mempools

I support the filters because they push the cost of spam up the tier list

I feel like this article only makes the case for providing devs better guarantees of doing stuff that node runners dont agree with.

And while i can see how this provides incentives for good behavior, i dont see why devs wouldnt keep creating unspendable utxos.

I had seen some math showing that multiple opreturns might be cheaper up to a certain amount, but what happens above that?

Have any concerns come up about unknown unknowns? How is a node's processing efficiency impacted by larger opreturns and is there a greater chance for malicious payloads considering other software that node runners might be running like electrum and mempool?

Using unspendable utxos to store spam costs a couple of bucks more than using an op_return. The deterrent effect of raising the cost in this way outweighs the cost of storing unspendable utxos, in my opinion. True, unprunable spam is a worse kind, but you have to be quite motivated to do it thanks to its higher cost of production, and the result us much less spam overall. I think that's a good thing, it highlights the filters' deterrent effect. But if we remove that, the effect reverses: we get less "unprunable" spam (yay!), but at the cost of having way more prunable spam, and that seems worse to me.

Ok, how does 1000 ticks crawling around the mempool help make bitcoin, and specifically mining, more decentralized?

Previously this would have taken 2 txs (1 to publish a Taproot output and the next to spend it, revealing the data in the witness).

Wanted to pull the trigger and buy a 49" ultra widescreen monitor for under $1,000 but thankfully I checked the capability of my laptop graphics card first and realized it can't push that many pixels 🫠

gn nostr #deckpics

This is wrong. Witness data is not stored in the UTXO set. Witness data is revealed when spending a UTXO, removing it from the UTXO set. Witness data is only in blocks and can be pruned.