<unnamed>

Public Key

npub1j5mp526z5fkz9wkrk6mt5nzu43xndyrwkr8mnqngdqwytgcpc5vqcnsd5c

Profile Code

nprofile1qqsf2ds69dp2ympzhtpmdd46f3w2cnfkjphtpnaesf5xs8z95vqu2xqpp4mhxue69uhkummn9ekx7mqs7x62n

Publishing to

nos.lol

Last Notes

2025-07-16 02:27:49 UTC

- reply

What is shared sign? I didn't think I've heard that term before.

2025-05-23 01:21:10 UTC

- reply

BIP353 has probably not really arrived yet, has it?

2025-05-23 00:40:57 UTC

- reply

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?

2025-05-23 00:31:40 UTC

- reply

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.

2025-05-22 00:03:58 UTC

- reply

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.

2025-05-21 10:41:39 UTC

- reply

Yeah, agree, it seems mostly like trolling to make a point or riding on the attention.

2025-05-21 05:20:45 UTC

- reply

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.

2025-05-21 00:07:35 UTC

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.

2025-05-20 23:16:25 UTC

- reply

For context, Bitcoin Core has something like 240'000 lines of c++ code.
I don't intend to take the time to go through someone of that magnitude, but if you want to take a look, here's the diff: https://github.com/bitcoin/bitcoin/compare/28.x...bitcoinknots:bitcoin:28.x-knots

2025-05-17 16:52:05 UTC

- reply

About 28,000 differing lines of code across 550 files and 1400 commits

2025-05-15 05:36:16 UTC

- reply

As far as I can tell all Bitcoin Core contributors are only interested in Bitcoin as a monetary system, although some are more excited about nascent scaling technologies than others.
We've seen at least three waves of data transaction uses get priced out of Bitcoin so far, and just because a sober assessment indicates that it will always be possible to embed data in the Bitcoin block chain doesn't mean that any Bitcoin Core developers are motivated by that.
That said, I have in 12 years not seen a mempool policy tightening, especially not against any transaction types that had more than vanishing demand. I'm not convinced it's feasible without making it financially attractive to break rank.
If you have some time and are open to reading more, I thought Antoine's responses to various concerns were well laid out here: https://delvingbitcoin.org/t/addressing-community-concerns-and-objections-regarding-my-recent-proposal-to-relax-bitcoin-cores-standardness-limits-on-op-return-outputs/1697

2025-05-14 06:53:34 UTC

- reply

I'm just pointing out some facts, you do you

2025-05-06 06:02:22 UTC

- reply

What makes you so sure? Have you tried it? From what I hear and see, the OP_RETURNBOT creates larger OP_RETURN outputs just fine.