aj

Public Key

npub1cev2qfuqv5s9jm5a6yvhc8ne8cdl9mh459m5g8zz759s7pw9fayqnketlq

Profile Code

nprofile1qqsvvk9qy7qx2gzed6wazxtureunuxljam66za6yr3p02zc0qhz57jqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqythwumn8ghj7un9d3shjtnrw4e8yetwwshxv7tfrxdeg5

Publishing to

relay.snort.social

relay.current.fyi

soloco.nl

nost.bitcoiner.social

nostr.mom

eden.nostr.land

Author Public Key

npub1cev2qfuqv5s9jm5a6yvhc8ne8cdl9mh459m5g8zz759s7pw9fayqnketlq

Show more details

Last Notes

2026-10-30 03:18:49 GMT

- reply

Querying the signet miner addresses or some of the signet powcoin faucet addresses should be good stress tests probably. Lots of address reuse, lots of transactions.

2026-08-16 11:40:53 GMT

- reply

Optimistic take: we stopped writing manuals because no one reads them, but now, AIs read them so they're worth the effort to maintain, and AIs also make manuals easier to maintain. We're about to enter a golden age of vendor provided documentation! 🚀🚀🚀

2026-07-10 07:56:47 GMT

- reply

So that it's easy to build up a backlog and get fee pressure, without having to make 4x the spam txs.

2026-06-21 01:00:56 GMT

- reply

How effective the cache is depends on how the client sends prompts. eg https://www.claudecodecamp.com/p/how-prompt-caching-actually-works-in-claude-code
But i think April/May had some big changes that made targeting anthropic's caching behaviour specifically make a big difference.

2026-06-18 09:48:40 GMT

- reply

I've read that claude code uses context caching better/differently to generic clients which makes a massive difference to claude token usage. I also thought the detection stuff just switched you over to bonus usage even without your subscription being used up.

2026-03-25 06:01:55 GMT

- reply

Seems like you of all people should be in a bubble where everyone's talking about payments and point of sale availability being key to unlocking exponential growth...

2026-03-24 09:30:02 GMT

- reply

Sounds like the problem is you're listening to the wrong people? Billions "rushing" in is unlikely to happen, and even if it did its effects are likely to be mitigated by billions rushing out as earlier investors take profits. $42k to $70k in two years is also nothing to sneeze at.

2026-02-01 09:51:09 GMT

- reply

Info from blockchair.com, originally posted on twitter.
https://x.com/i/status/2017813697255891246

2026-02-01 09:50:18 GMT

- reply

Less difference between eth and btc than I would have expected, not really much out of the segwit plus 1/2/4 doubling plan that's was considered prior to segwit becoming super controversial.

2025-11-26 02:18:59 GMT

- reply

You might not think bip editors have that responsibility, but lots of people do, and will react pretty negatively if they don't appear to live up to that responsibility.

2025-10-26 09:52:36 GMT

- reply

tinyformat does compile time checks that catch that, for C++ anyway. At least if I'm not misunderstanding the bug.

2025-10-25 09:43:39 GMT

- reply

Did you try batching the additions (begin..commit)?
O(0) algorithms ftw. There has to be a tshirt idea there. Maybe a -420+0 diff on the back?

2025-10-08 19:13:47 GMT

- reply

Who are you seeing doing any of those things? As far as I can tell you're arguing about strawman.

2025-06-19 02:51:09 GMT

- reply

Wish you'd at least take a look at the lisp approach...
Anyway, a few quick comments on the op_tx part: a) if the selector is meant to be scriptnum compatible, would be good to make that clear (ie 513 on the stack is interpreted as outputscript+collate not as 0x0102 and tested as outputamount+version. b) please use hex for the selector values...c) you might consider two separate functions [op_tx and op_txcollate] instead of using a bit selector; makes it slightly easier to statically validate expected stack depth, though still not great. d) not sure the ordering of collate-vs-noncollate makes sense - should "output" just always put the new data at the start of the buffer or the end of the stack do you consistently get the last output thing first? e) input(num)witness seems like a bad idea to me, constraining how other inputs are spent just seems like asking for complexity and bugs. f) having a way to pull info from other inputs' annex (and your own) would be a win though, but maybe that should be an op_annex getter. g) personally I don't think upgradability is a win here, better to upgrade by defining a new opcode than have weird semantics that people will forget to check. h) the ctv comparison at the end is inaccurate - ctv also commits to scriptSigs. i) automatically hashing it as you go rather than pushing the whole thing to the stack then hashing it seems worth considering
Hmm maybe gmax is right it abbreviating as txn instead of tx which is also transmit (he says after correcting an op_rx typo)

2025-06-08 23:25:09 GMT

- reply

Require a zap or pow for comments from outside your social graph, and automatically add people to your social graph (and refund the zap) when you like a comment from them?
Bonus: will make moderating your comment threads feel like watching Adam West's Batman: Pow! Zap!

2025-06-02 12:18:52 GMT

- reply

The enemy's gate is down.

2025-05-25 14:25:08 GMT

- reply

Lower the block size?

2025-05-21 06:40:02 GMT

- reply

The only (informed) argument I see for that position is something along the lines of "this acts as an endorsement that such data storage is fine, and will encourage people to do more of it. You can observe that this effect has already happened with a large increase in op_return activity since the pr was opened, and the creation of a new "op20" token scheme. That endorsement will flow over to schemes that use witness data, increasing their use as well. That will make it less likely that will have non-full blocks (due to more token usage of either type) and increase the data storage requirements of non-pruned nodes due to increased witness usage"
Personally, I think the immediate observable effect is due solely to the publicity the issue has generated and will disappear when attention moves elsewhere.

2025-05-20 06:50:42 GMT

- reply

"You can reduce spam by discouraging it" is a question of incentives, not one of fundamentals. I don't think we've finished the fundamental debate that you wanted yet.
Do you agree that core devs in general are trying to make bitcon work as a monetary network with a similar/compatible definitively to yours? That is, that we are actually on the same side here, even if we have different thoughts on how best to achieve that goal?
Do you accept that reasonable people can disagree on what constitutes "spam"? Both in thinking things you think aren't spam actually are, and in thinking stuff you think is spam is fine?
Do you accept that bitcoin is not your network, to rule as you wish, but that rule changes require near unanimous consent, even from the reasonable people who disagree with you, and potentially even from people doing the spamming?
Are you trying to ban spamming from bitcoin entirely?
Are you merely trying to discourage spammers? Are you aware that that might have no effect, or the opposite ("how dare you tell me what to do, I'll do it to spite you")?
Do you believe that going into technical details on this topic, to work out how best to make bitcoin sustainable as a monetary network in the long term is a valuable thing to do, or is that just a way for experts to attempt to close down the discussion and exclude non-experts?
I notice you're gong straight back to personal attacks ("would you rather people question your competence rather than your intent") and justifying it with fairly specific thoughts about current approaches, rather than sticking with the fundamental principles you claimed to want to discuss.

2025-05-17 00:23:47 GMT

- reply

I'm sorry, I thought you were insisting discussing the fundamentals, not the technical details, whether software or economics. You said "If we were having a real, serious conversation, it would be not be at this level, it would be about what we think Bitcoin really is. Is it a monetary network or is it something more? Do spammers have as much right to Bitcoin block space as monetary people?" You obviously think people who've been disagreeing with you, of which I'm one, have a different view on that fundamental question that they, including me, are disguising behind technical gibberish. Let's have the real serious conversion about fundamentals you claim is lacking before backing down to a "but it's bad communication" cop out.
Do you accept that we both agree that Bitcoin should be a monetary network? Do you agree that's also true of the vast majority of regular contributors to Bitcoin Core?

2025-05-16 18:43:23 GMT

- reply

There's not much point talking to people who think they know your values better than you do, and just claim you're lying when you disagree. The entire point of bitcoin is to be a monetary network, and this change is a deliberate step forward in achieving that goal. As far as patronising goes, check for the log in your own eye.

2025-05-14 23:42:15 GMT

- reply

What if what you think is a fundamental disagreement is just a lack of understanding? Would it be better to spend time talking and listening, rather than developing a long term schism or grudge?

2025-05-14 15:47:15 GMT

- reply

Corollary: if you want someone out of the kitchen, turn up the heat.
#nevent1q…rn2w

2025-05-14 15:01:43 GMT

- reply

I don't think this is really an honest/fair criticism, personally - it was only poor communication if you were expecting it to have been able to overcome a concerted disinformation campaign from all the usual suspects. On the other hand, if it works as motivation for you to do more good stuff, though, carry on.

2025-05-02 11:22:43 GMT

- reply

It's easier for a light client to obtain data in an OP_RETURN too - you only need the block merkle root, for witness data you'd need to get the coinbase tx and the witness commitment as well.

2025-02-18 21:58:44 GMT

- reply

Your audio is pretty echoey 😟

2025-01-28 14:38:46 GMT

- reply

Afaik assumeutxo doesn't use muhash, https://github.com/bitcoin/bitcoin/issues/27669 ?

2025-01-28 13:09:31 GMT

- reply

But it's already a possibility? coinstatsindex works fine?

2024-08-30 01:58:22 GMT

Anyone have an android nostr client to recommend for a (roughly) twitter-like experience?