Curious if this is an unpopular opinion:

It was with too hard to get a BIP processed in the past and now people put BIPs on a pedestal.

But BIPs are author documents. Especially in Draft stage, they do not present community consensus — they're the authors’ personal recommendation to the Bitcoin community.

It seems good to me that we get a few controversial BIPs. It clears up that it's still the readers’ responsibility to make up their mind.

It was with too hard to get a BIP processed in the past, and now people put BIPs on a pedestal.

But BIPs are author documents. They don't present community consensus, they're the authors’ personal recommendation to the Bitcoin community, especially in Draft status.

It's good that we get a few controversial BIPs. It helps to make it clear that it's still the readers’ responsibility to make up their mind.

It was with too hard to get a BIP processed in the past, and now people put BIPs on a pedestal.

But BIPs are author documents. They don't present community consensus, they're the authors’ personal recommendation to the Bitcoin community, especially in Draft status.

It's good that we get a few controversial BIPs. It helps to make it clear that it's still the readers’ responsibility to make up their mind.

Ich bin verwirrt. Ich habe dieses Jahr eins geschrieben.

It was with too hard to get a BIP processed in the past, and now people put BIPs on a pedestal.

But BIPs are author documents. They don't present community consensus, they're the authors’ personal recommendation to the Bitcoin community, especially in Draft status.

It's good that we get a few controversial BIPs. It helps to make it clear that it's still the readers’ responsibility to make up their mind.

Not just the normies

So, what you're saying is that we have not been selective enough for accepting recent submissions?

Software update broke my desktop at work and I got stuck way later fixing it, just picking up my pizza. 😁

I guess I'll have go claim it then.

Alright, gonna keep my eyes peeled. Thanks for going to the ML first, we've been getting a lot of halfbaked stuff first-seen as pull requests lately 😅

Whatcha writin' about?

What is the second one? I got BIP77 and I'm drawing a blank for the other. You cooking something? 😉

BIP353 has probably not really arrived yet, has it?

Non-custodial is probably not less work than a nip-5, I take it? 😅

That was pretty easy, so that's a good argument.

What I've tried so far, was to set up receiving with Phoenix. I figured a bolt12 invoice might work, or the BIP353 username would, but neither seemed to work from Amethyst when I tried in my own profile. I moved recently and haven't set up my homenode again, so I was considering doing that one of the coming weekends, but maybe I'm missing a way easier way of doing it?

Would that work from amethyst, or do I need to operate the wallet from the website?

Okay, why's that? Kinda confused why I spent 30% of my work time on the BIPs repo in the past year, if they're relevant now.

Thanks, let's dive in, shall we?

What issue were you experiencing with the Pi4?

I'm asking because there is a common misunderstanding that the entire UTXO set needs to fit into RAM, but that is not the case. The UTXO set is mostly stopped on disk. You only need a couple gigs of RAM for Bitcoin Core to run decently, although more is certainly helpful. UTXO set growth means slower IBD and generally more disk reads during validation, but it's a graceful degradation, not a cliff.

Mh, still ob the fence whether to bother with yet another social media platform, so I've put little effort into seeing it up so far

Thanks! I answered a lot of the frequent questions on Stacker News a couple weeks ago:

https://stacker.news/items/971277

Since it became a pretty big thread, here is a table of contents for the previous thread: https://stacker.news/items/978404

I also thought that Antoine did a great job of addressing most talking points in this debate on delving:

https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697

It's raining BIPs, hallelujah...

Recently merged:

BIP53

BIP54

BIP172

BIP177

BIP321

BIP443

On the cusp:

BIP77

Maybe a good time to remind that BIPs are author documents that represent the authors’ recommendation to the Bitcoin community.

Ocean had only found 11,895 blocks, and that's if you count the ones found by Eligius.

Thanos for being open to this conversation

A lot to unpack here.

> The fact they will remove the option for us node runners to decide what will go trough our nodes is shady. I want option to change OP_RETURN value in settings.

The latest version of the pull request only deprecates, but does not remove the configuration option.

> Increasing the Blockchain size by allowing arbitrary data transactions. It's true they'll pay more but that won't stop them and major miners arent against that.

OP_RETURN data is written to output scripts. Output scripts are not subject to the witness discount. More OP_RETURN data would likely reduce blockchain growth, so as I was asking in the above post, I am not sure where this idea is coming from.

> The cost of running a node will increase because 2TB drive will not be enough if they keep spamming the Bitcoin.

Blocks are limited to 4'000'000 weight units. OP_RETURN data bytes weigh four weight units, so a block filled with OP_RETURN outputs would come in close to 1MB, which is significantly less than the latest 30-day average of 1.64 MB. It’s unlear to me how more OP_RETURN data would increase the blockchain growth.

> Look at the Ethereum for example. Their full archive node requires 12TB of disk space I believe. It might be even more today. And even they have OPTIONS to run 3 kinds of nodes.

No clue, they have made a lot of strange decisions, but I don’t see how it’s relevant as the things that lead to bloat there are completely different.

> I'm not seeing the reason why in the hell #Core devs need to remove this option. Leave it there. I'll decide how much shit I want to broadcast.

I think there have been several books worth of explanations written at this point, so I don’t think it’s useful to elaborate, but if you are earnestly interested, I can provide a few links.

> I hope people won't blindly update to new core 29 release after knowing what that brings.

Bitcoin Core 29.0 came out in April and did not change the OP_RETURN limit. If the currently open pull request should get merged, the change would at the earliest be released with Bitcoin Core 30.0 in October.

That feels unfair, I didn't say I didn't want to talk to you because you were a "normal node runner". I indicated that your answer did not match the topic I asked about.

I get that people don't like data in the blockchain—I'm not excited about that either—but I've already heard all about that for the past two weeks. Here, I'm specifically trying to I understand why people argue that OP_RETURN transactions make nodes more expensive to run. I don't get where that is coming from or what the line of thought is.

Okay, do you also have an opinion on what I asked?

"Never to STFU"?

Does someone want to explain to me how OP_RETURNs increase the blockchain growth, hardware requirements, or otherwise increase the cost of running a node? I keep seeing that concern, and that seems completely counter my expectations. I'd love to see a detailed explanation of how that follows.

Nice strawman, hope nobody torches it