Murch

Does bitcoiny things at Localhost Research

Public Key

npub1j5mp526z5fkz9wkrk6mt5nzu43xndyrwkr8mnqngdqwytgcpc5vqcnsd5c

NIP-05 Address

Profile Code

nprofile1qqsf2ds69dp2ympzhtpmdd46f3w2cnfkjphtpnaesf5xs8z95vqu2xqppamhxue69uhkummnw3ezumt0d5qjzamnwvaz7tmdw4k8g6tsd3jhsetj9e582um6dahx2eme9emk7unvvshxv0yz

Publishing to

nostr.mom

multiplexer.huszonegy.world

nos.lol

nostr-pub.wellorder.net

Author Public Key

npub1j5mp526z5fkz9wkrk6mt5nzu43xndyrwkr8mnqngdqwytgcpc5vqcnsd5c

Show more details

Last Notes

2025-07-20 07:51:19 CEST

- reply

Nice catch, thanks

2025-07-17 15:19:41 CEST

- reply

The account you're replying to is my personal account, or wdym?

2025-07-17 15:16:22 CEST

- reply

I couldn't find a change, could you point out the difference, please?

2025-07-17 15:13:56 CEST

- reply

No worries!

2025-07-16 04:27:49 CEST

- reply

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

2025-07-16 04:27:14 CEST

- reply

Stamps 🫣

2025-07-15 20:29:43 CEST

# UTXO set counts change between 2025-01-01 and 2025-07-14
P2A: +19
P2TR: +28,167
P2WPKH: -10,993,297
P2WSH: +504,757
P2SH: -1,892,424
P2MS: +592,588
P2PK: -600
P2PKH: -6,881,365
https://image.nostr.build/4c1c84edf010fd56d42cf9f53c1d67b98b1655a7ef3fb79efb2d3fcca600cb78.jpg
## 2025-01-01
P2A: 1
P2TR: 57,851,467
P2WPKH: 56,806,770
P2WSH: 1,627,820
P2SH: 14,993,160
P2MS: 2,016,773
P2PK: 45,731
P2PKH: 52,278,323
## 2025-07-14
P2A: 20
P2TR: 57,879,634
P2WPKH: 45,813,473
P2WSH: 2,132,577
P2SH: 13,100,736
P2MS: 2,609,361
P2PK: 45,131
P2PKH: 45,396,958

2025-06-28 06:36:32 CEST

- reply

It's like a cherry on a giant turd.

2025-06-24 23:24:00 CEST

- reply

Hey, my co-founder Justin is it executive director, I'm the other co-founder. You can find more information on our transparency page and this blog post: https://lclhost.org/blog/getting-started/

2025-06-24 16:48:13 CEST

Localhost Research got its non-profit status: https://lclhost.org/blog/501c3/
🥳

2025-06-18 16:29:26 CEST

- reply

That's too long for a vanity address. It looks like they burned the funds.

2025-06-09 04:51:59 CEST

- reply

Interesting observation that better moderation tools coincided with fewer questions getting asked

2025-06-06 21:28:17 CEST

- reply

We currently have only translations to Japanese, Spanish, Czech, Hindi, Mandarin, German, and French, although not every issue of the newsletter is translated to every language. All the translations are made by volunteers separate from the people working on the English newsletter.
If there are some Portuguese speakers that would like to contribute to a Portuguese translation that would be welcome!

2025-06-06 19:06:39 CEST

Würdest du den Optech Newsletter lieber in Deutsch lesen? Kannste!
https://bitcoinops.org/de/publications/

2025-06-04 00:41:29 CEST

- reply

I can't stand the current regime, but I still support this piece of legislation. — I would prefer not to go to prison for working on the Bitcoin Core wallet.

2025-06-03 04:32:00 CEST

- reply

Yeah bots that repeat the same words in a weird order

2025-06-03 03:53:06 CEST

- reply

What we're doing is significantly improving the performance of Bitcoin Core with many releases.
Maybe you're just expecting a little much out of such a low-powered device?

2025-06-02 22:01:41 CEST

Okay, I'm getting old or something, but can someone explain what people mean when they use the "call me" symbol: 🤙?
Clearly it's not "call me" in the contexts that I'm seeing it used.

2025-06-01 03:59:54 CEST

- reply

Correction, digital copy is not published yet, but coming soon

2025-06-01 01:18:04 CEST

- reply

It's free, you can find it on her website to print and assemble it yourself, or if you're lucky, you may get a handsown copy from Satsie herself, when you run into her at a conference or meetup

2025-05-31 19:16:11 CEST

@nprofile…wca6 made a splendid new zine! About Silent Payments this time. Check it out! https://image.nostr.build/6babb785cb90f2b0219a7c3f061e65c4558e6c0f4c8f6791fd0472ffc0b905a2.jpg

2025-05-29 04:14:42 CEST

If you were at the Las Vegas #bitdevs today and you're owed the nitty gritty details of Pay to Anchor, TRUC transactions, 1p1c, and ephemeral dust, here is the Stack Exchange topic that was referenced:
https://bitcoin.stackexchange.com/q/126098/5406

2025-05-27 16:53:37 CEST

- reply

I mostly follow your argument, but would posit that establishing a social convention can be meaningful coordination. I'd also want to point out that there are a few more similar BIPs e.g., BIP176 and BIP179.

2025-05-26 05:13:04 CEST

- reply

I am not sure I get your point. There are occasionally some blocks that are completely empty, and sometimes miners accidentally include less transactions than are available, e.g. because they build a block with a recently restarted node.
We also have recently cleared the mempool a few times, so at those times non-full blocks would have been expected.

2025-05-25 18:18:17 CEST

- reply

There is a bit of a range between controversial and unserious. ;)

2025-05-25 17:49:23 CEST

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.

2025-05-25 17:47:05 CEST

- reply

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.

2025-05-25 17:39:12 CEST

- reply

2025-05-25 17:34:44 CEST

- reply

Ich bin verwirrt. Ich habe dieses Jahr eins geschrieben.

2025-05-25 17:32:53 CEST

- reply

2025-05-25 00:28:53 CEST

- reply

Not just the normies

2025-05-24 17:53:31 CEST

- reply

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

2025-05-23 05:40:49 CEST

- reply

Software update broke my desktop at work and I got stuck way later fixing it, just picking up my pizza. 😁 https://image.nostr.build/e1c3125474fe293a279641e83d6b184d1ccc17a08d77b2a0434a18394c565eb9.jpg

2025-05-23 05:29:31 CEST

- reply

I guess I'll have go claim it then.

2025-05-23 05:29:00 CEST

- reply

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 😅

2025-05-23 05:27:31 CEST

- reply

Whatcha writin' about?

2025-05-23 03:24:43 CEST

- reply

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

2025-05-23 03:21:10 CEST

- reply

BIP353 has probably not really arrived yet, has it?

2025-05-23 03:05:03 CEST

- reply

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

2025-05-23 02:40:57 CEST

- 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 02:34:31 CEST

- reply

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

2025-05-23 02:31:40 CEST

- 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-23 02:30:12 CEST

- reply

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.

2025-05-22 22:15:02 CEST

- reply

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

2025-05-22 22:13:42 CEST

- reply

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

2025-05-22 06:26:22 CEST

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.

2025-05-22 03:34:33 CEST

- reply

If you mean me, my first post with this account was in December 2022, but I haven't been active for most of the time since then. If you meant AJ, he should answer that himself.

2025-05-22 02:30:52 CEST

- reply

I wrote a longer response to Leon here, that you might also find interesting: https://njump.me/nevent1qqsd9h3yau0zzev5zel30jkztvhluw9us6anhnvlqj28wxqc9runa8qpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygy4xcdzks4zds3t4sakk6aych9vf5mfqm4se7ucy6rgr3z6xqw9rqpsgqqqqqqsfk9w40

2025-05-22 02:29:37 CEST

- reply

Yeah, I get that all the hype around silly pictures in the blockchain gets on the nerves. FWIW, all the Bitcoin Core devs are working on the native currency for the Internet, as far as I can tell, they largely feel the same.
To us it mostly feels like a question of priorities and benefit per cost. Except for Luke, I don't know if any Bitcoin Core contributors that think filters have any effect at all on transactions for which there is sufficient economic demand. 53% of all transactions in the last year have had inscriptions or op_return outputs. These transactions paid hundreds of millions of dollars in transaction fees.
I don't think there is an appetite for crippling Bitcoin Script over this by soft forking in mitigations. So, Bitcoin Core devs mostly choose to spend their time on other things.
Most Bitcoin Core devs have plenty skin in the game, with their careers tied up in Bitcoin for many years. Don't get too worked up, it's not as big of a deal as some make it sound.

2025-05-22 02:16:10 CEST

- reply

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

2025-05-22 02:08:10 CEST

- reply

Thanos for being open to this conversation

2025-05-22 02:03:58 CEST

- 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 20:58:56 CEST

- reply

That argument would make more sense to me, but that's why I was asking about the other argument, which doesn't. ;)

2025-05-21 12:41:39 CEST

- reply

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

2025-05-21 07:20:45 CEST

- 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 02:48:01 CEST

- reply

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

2025-05-21 02:08:26 CEST

- reply

"Never to STFU"?

2025-05-21 02:07:35 CEST

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-21 01:38:54 CEST

- reply

Nice strawman, hope nobody torches it

2025-05-21 01:16:25 CEST

- 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-21 01:00:54 CEST

- reply

Hey Leon,
thanks for your reply. Given the many points you raised, I will quote for context what I’m replying to.
> Leon wrote:
> What I don't understand is why the limit for op_return is being changed when filters are actually working. Yes they don't filter out everything but they do filter out most of it.
I am puzzled how you arrive at the conclusion that they "filter out most of it". 53% of transactions over the past year had OP_RETURN outputs or inscriptions. Could you perhaps explain further what effect you perceive filters to have had?
> Leon wrote:
> Then you have a couple of folks claiming that filters are useless and we should give up on them entirely because spammers could use out of bound transactions via services as slipstream by MARA to circumvent filters (which is right but also proves that filters are working pretty well since they wouldn't need to go out of bound otherwise).
Some miners appear to be running Libre Relay or have otherwise loosened their mempool policy. These miners accept transactions considered non-standard by default Bitcoin Core configurations in-band. They appear to track them normally in their mempools, and include them in their blocks whenever those transaction’s feerates put them in the block. The myth that non-standard transactions need to pay a multiple of other transactions appears to be based on the OP_RETURN_BOT service charging a premium and sending at a higher feerate, but if you are willing to wait, non-standard transactions appear to be getting confirmed at the same feerates as any other txs.
> What puzzles me as well is the statement that transaction fees are enough to filter out spam. You might be right with this claim but I am not sold on it entirely.
Given limited blockspace, it is obvious that transaction uses that can afford to pay more for blockspace will price out transactions that can only afford to pay little for blockspace. This means especially that large value transfers have a much bigger budget to pay for blockspace than small transfers (if you are sending 10 ₿, you don’t care about paying 10'000 sats in fees, but if you’re trying to send 10'000 sats, paying 10'000 sats is prohibitive). This isn’t a new observation, I wrote in 2016: "Transaction fees are not in relation to the amount of value transferred, but in relation to the amount of block space they'll take. Therefore, it is relatively cheap to send large amounts of value in Bitcoin but uneconomical to send micro-payments." (via https://bitcoin.stackexchange.com/a/48422/5406). I’m not sure what your expectation is, but any form of Bitcoin succeeding will mean that small payments will be economically infeasible on chain. In the past couple years, we saw the third hype wave of people using Bitcoin for publishing data. Just like the prior two times, the excitement eventually subsided and as the premium came down, the cost curbed the transaction volume. Even at the peak of the hype, large transfers easily price out this sort of use. If you are upset that small payments were priced out, I’m afraid that’s the expected outcome either way. I don’t see the point in lying to Bitcoin users by trying to keep transaction fees low artificially.
> Leon wrote:
> As long as bitcoin evolves the way as projected and increases in global significance a lot more folks might want to spam the chain even though fees would be higher at that point the incentive for spamming and using more resources to do so would grow similarly.
> In general I think spam is harmful and might lead to unintended consequences so I don't think we should give non monetary transactions more room and easier ways to use the protocol.
OP_RETURN outputs do not grow the UTXO set, because they do not get added to the UTXO set. They are easier to validate than payment outputs, because they don’t contain signature operations. Since OP_RETURN data is in output scripts, it has no witness data that would be discounted. As far as I can tell, besides competing for blockspace, they use less resources in every way than other transactions per byte.
Inscriptions also do not increase the UTXO set per se, because it takes creating an output and spending an output to publish the Inscription in the input’s witness stack. Witness data is validated once and retained with a full copy of the blockchain or discarded by pruned nodes as any other blockchain data.
It seems to me that most of the UTXO set increase is due to Ordinals—the notion that satoshis have a serial number and some of those serial numbers are more valuable than others—and users splitting up UTXOs to isolate satoshis with certain Ordinals. Sometimes inscriptions are attached to Ordinals, but I’d still blame that on Ordinals more than on Inscriptions. The transactions that split UTXO amounts to isolate certain Ordinals are indistinguishable from payment transactions without out-of-band information about Ordinals, so the main UTXO set bloat is not easy to filter.
So, overall I see UTXO bloat from Ordinals and blockspace demand by transactions that offer to pay more for blockspace. I don’t see a practical way of preventing Ordinals, and don’t perceive Inscriptions or OP_RETURN outputs as particularly harmful (dumb sure, but not harmful). Perhaps you could elaborate how spam is harmful, if you disagree, because I don’t see it.
> Leon wrote:
> I said core seems compromised because they would not ship many "controversial" implementations in the past but this time when controversy is obvious as you can tell from the debate they don't care and ship anyways.
I don’t know which examples of controversial changes that did not get shipped you are referring to, but the ones I recall were sunk by convincing technical arguments against them. I have yet to see a convincing technical argument against raising the OP_RETURN limit.

2025-05-20 18:10:47 CEST

- reply

P2TR keypath inputs weigh 230 Wu (57.5 vB), so P2TR outputs with 1000 sats are economically spendable at feerates up to 17.3 sats/vB.

2025-05-20 01:42:15 CEST

- reply

Would you like to share your concrete concerns, so I can address them?
I have not received any money or other incentives to have a specific position in this matter, not am I aware of any other participants in this discussion being paid to represent a specific position.
To me the arguments for lifting the limit make sense by themselves. My skepticism to the viability of filtering transactions with significant demand aren't exactly new, I pretty much write the same thing on last year's pull request for "match more data carrying" which I found to be similarly poorly motivated.

2025-05-19 18:48:04 CEST

- reply

New major versions are only released twice a year, in April and October. Even if the PR were merged, which it has not yet, it would not be released until Bitcoin Core 30.0 is released in October.

2025-05-19 18:44:17 CEST

- reply

If a pull request doesn't pass review, the reviewers leave feedback on what to improve until it becomes ready for merge or work on it is discontinued. When pull requests run into well-reasoned opposition they tend to get closed to curb review time spent on things that are unlikely to be merged.

2025-05-19 16:57:29 CEST

- reply

No, I did not conflate contributors and maintainers. In Bitcoin Core nothing gets merged until it has been reviewed by several regular contributors, usually several times. Sure, one of the five maintainers (who are part of the regular contributors) is usually the last reviewer and will merge a PR if it has had enough review and they're satisfied, but they don't merge things that haven't been reviewed by other knowledgeable developers, mostly from those 40 regulars.

2025-05-19 16:40:44 CEST

- reply

It might make more sense when you consider that neither Peter nor myself is speaking for Bitcoin Core, but that birth of us are just presenting our own opinions.

2025-05-19 03:57:04 CEST

- reply

Murch didn't talk about the OP_RETURN limit at all in that post, he was addressing claims that Bitcoin Knots has more developers than Bitcoin Core.
If you want to know my thoughts on the policy change, I've left a comment on the PR.

2025-05-17 18:52:05 CEST

- reply

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

2025-05-17 18:48:37 CEST

- reply

Okay, what for? For informing people about the options they're choosing from?

2025-05-16 06:56:18 CEST

- reply

You're welcome, and that's what I think mostly as well: (high-value)monetary transactions will have the highest bidding power in the long run and that's what will curb the data transactions. Thanks for being open to hearing various sources.

2025-05-16 01:21:28 CEST

- reply

Stop wondering whether that was a joke

2025-05-15 23:51:56 CEST

- reply

Is that a gut feeling, wishful thinking, or did you see anything specific in that repository that indicated review activity?

2025-05-15 23:34:48 CEST

- reply

Yeah it isn't much, just about 28,000 lines of code difference across 550 files and 1400 commits. https://image.nostr.build/5be4acb9eb8e563bf409bad25f6594b157eb862fedce6c9411c564477979a433.jpg

2025-05-15 23:17:10 CEST

- reply

See https://njump.me/nevent1qqsqgqshlvle5f0ud0xvaadcytfest4mv47hr2j9fsrlpf67c7mwprspr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qgsf2ds69dp2ympzhtpmdd46f3w2cnfkjphtpnaesf5xs8z95vqu2xqrqsqqqqqplc5wt9

2025-05-15 23:12:00 CEST

- reply

Witness data is discounted by a factor four not three, but yeah, OP_RETURN data takes more blockspace and is more expensive to the same degree. Either way the sender pays for whatever blockspace they win the bid on.

2025-05-15 23:10:08 CEST

- reply

That's where we disagree. We should make the benign way of writing data easier so they stop using the malign one.

2025-05-15 23:09:19 CEST

- reply

Yes, that's correct. Small data payloads get slightly cheaper. It just seems that people are much more concerned about big amounts of data and those are significantly more expensive with OP_RETURN. Either way, data occupies whatever blockspace the transaction bids the premium for.

2025-05-15 23:04:54 CEST

- reply

It's not a bug. Dropping the script size limit is an intentional design decision. As BIP 342 says:
"Why is a limit on script size no longer needed? Since there is no scriptCode directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed."
You could always put data in the block chain by paying for the block space. The DoS protection was always the block size limit and blockspace market: it's expensive and people stop doing it whenever the hype has jumped the shark.
Could you elaborate how "inscriptions are more onerous for the data hoarders to inscribe and reconstruct in order to access their data"? Serialization and deserialization of data is a standard exercise that gets designed once and then used per a library. Why would they care which function they call on a library?
Could you tell me more about the concern you have when you say "if we let them put data on the Blockchain in its raw form that could be inviting even more problems than it solves"?

2025-05-15 22:47:04 CEST

- reply

Theoretically you could have done the same reveal truck with p2sh, but the redeem script had to fit into a single 520 byte push. Segwit introduced the witness section and witness discount, Taproot removed the 520 byte limit for witness stack items. Altogether, you could then do big scripts for less in the witness.

2025-05-15 20:22:01 CEST

- reply

The main reason to do it is the same reason as 2013: it's preferable for people to write into op_return outputs than into unspendable payment outputs. Dropping the limit makes OP_RETURN a reliable replacement for the latter which is currently standard and essentially unpreventable.
Data in OP_RETURN is significantly more expensive than data in inscriptions, so I have a hard time understanding the concern that the overall block space occupied by data transactions would increase.
Whether more should have been done about inscriptions seems like a separate debate that mostly muddies the water here.

2025-05-15 20:13:52 CEST

- reply

Biometrics are user IDs, not passwords.

2025-05-15 16:55:18 CEST

- reply

Bitcoin Core currently estimates feerates based on the time transactions of various feerates spend in the mempool before they appear in blocks. We ignore any transactions that we have not seen in the mempool.
We also have work in progress to estimate feerates based on the transactions in the mempool. https://github.com/bitcoin/bitcoin/issues/30392

2025-05-15 07:36:16 CEST

- 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-15 07:20:19 CEST

- reply

1. I don't understand why people think Peter Todd is a regular contributor to Bitcoin Core. I don't think I've seen him make that claim, I've certainly not seen other contributors make that claim, and as far as I can tell, he has made three commits since 2016.
https://image.nostr.build/c12a73d4e689ab00cfe4c16a1f0cba822f06d7467c42c2e6abf7f1e5e5272bc9.jpg
2. You will have to ask Peter why he said that and how he meant it.

2025-05-14 20:07:20 CEST

- reply

*restating

2025-05-14 20:06:46 CEST

- reply

No, people contributing to the upstream project are part of the process in the upstream project. Their review also benefits the downstream project as their code contributions are released with the downstairs project, but they are not participating in the downstream project's process.
Your restarting it like this makes me think that the distinction is not clearly understood.

2025-05-14 19:06:53 CEST

- reply

Sjors and I chatted a bit about it in last week's Optech Recap about it, of someone wants to listen to other sources.

2025-05-14 19:02:31 CEST

If you want to get more background on what the mempool is all about, Gloria and I wrote a ten week series in Optech two years ago: https://bitcoinops.org/en/blog/waiting-for-confirmation/
We also discussed each part of the series in the Optech Recap, if you prefer listening (look for the headphone symbol).

2025-05-14 16:36:21 CEST

- reply

Oh, my apologies, I didn't realize what the source of the second screenshot was. Thanks

2025-05-14 08:54:18 CEST

- reply

https://njump.me/nevent1qqstvvt6eddat0z5tkzmma3y7a9z3clyg7le58evm8yaz9vtnu53secpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygy4xcdzks4zds3t4sakk6aych9vf5mfqm4se7ucy6rgr3z6xqw9rqpsgqqqqqqs3ftc5h

2025-05-14 08:53:34 CEST

- reply

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

2025-05-14 08:50:43 CEST

- reply

What are you referring to?

2025-05-14 08:49:06 CEST

- reply

Maybe it's because we're not at the center of drama every other week

2025-05-14 08:47:47 CEST

- reply

I agree that the people who are interested in that project should probably do something to improve the review it gets.

2025-05-14 08:45:19 CEST

- reply

The project was previously hosted on sourceforge. Besides this number only counts the people that have committed code, not all contributors.
Luke is a BIPs Editor and the BIPs repository is part of the Bitcoin organization.

2025-05-14 08:32:14 CEST

- reply

The other developers work on the upstream project, Bitcoin Core. It is not clear to me why you think he's joking. Irrational takes like this are par of the course for him.

2025-05-14 07:42:56 CEST

- reply

https://nitter.space/LukeDashjr/status/1921234140717805769 https://image.nostr.build/72cbf2f65f8044d2ebe12ddeb1081fa5f6eb7fdc84ec64064d8a5750c8ce6972.jpg https://image.nostr.build/72cbf2f65f8044d2ebe12ddeb1081fa5f6eb7fdc84ec64064d8a5750c8ce6972.jpg
https://www.erisian.com.au/bitcoin-core-dev/log-2024-05-02.html#l-596

2025-05-14 03:25:46 CEST

- reply

I do. What's up with the leading questions? Are you working up to my code being released in Knots? I'm well aware of that, and that's an obvious possibility from most of my work being freely licensed.

2025-05-14 01:01:26 CEST

- reply

No, I have zero interest to be associated with Knots in any way.