jimmysong

Zero-JS Hypermedia Browser

avatar
jimmysong
jimmysong@programmingbitcoin.com
npub10vlh...sp42
Bitcoin Expert Open-Source Coder Follow me to learn #BTC Author of 5 Bitcoin books Fiat Ruins Everything: https://fiatruinseverything.com PGP: C1D7 97BE 7D10 5291 228C D70C FAA6 17E3 2

Notes (20)

Crypto VCs are like cockroaches, surviving on the dead bodies of altcoin traders.
2025-10-11 15:08:56 from 1 relay(s) View Thread →
It would be a good time to say "I told you so" but nobody needs to say anything when the carnage is so evident.
2025-10-11 02:13:31 from 1 relay(s) View Thread →
Courage is your biggest edge. Prudence is your second.
2025-10-10 18:56:45 from 1 relay(s) View Thread →
Within the datacarriersize/OP_RETURN change is hidden a change to how many OP_RETURN outputs are allowed. Previously, it was 1. With the datacarriersize change, it's now as many as the user wants. The technical justification for multiple OP_RETURNs now being standard is completely unconvincing. To quote @theinstagibbs : "The motivation for doing this is for situations where you cannot commit to all data efficiently otherwise. Think SIGHASH_SINGLE | ACP scenarios. The datacarriersize argument applies to payloads themslves, so yes, if someone wants to do ~80 bytes of payload and can do it in one output, they should just do that." To paraphrase, he's saying there might be transactions where multiple people sign one input and have one output that they get to control, which are each OP_RETURN. No wallet I know of even supports SIGHASH_SINGLE/ANYONECANPAY constructions. I'm not sure if you get 10 Bitcoin seasoned developers together that they'd be able to construct a transaction like this together without a lot of debugging. I have never seen any transaction like this in the wild (multi-op-return, sighash_single), and I have not seen anyone even ask for something like this. This justification was never brought up until I specifically asked this question in the un-deprecation PR. The multiple OP_RETURN becoming now standard was pointed out in the original PR, asking if this was an intended effect, to which no one responded with anything like the quote above. Thus, the rationale quoted above looks like to me an elaborate post-hoc justification for bad code. This modification is going into v30. Honestly, I'm not too concerned about the consequences of this particular aspect of the PR as the effects of it aren't too great (the 100k default is far more consequential), but the fact that this flimsy rationalization was accepted without much question is what makes me question not just the user-alignment, but code quality of the datacarriersize PR.
2025-10-09 14:32:52 from 1 relay(s) View Thread →
Assuming usage of OP_RETURN as the garbage can for non-financial data that would otherwise go into the UTXO set is naive. First, it's more expensive than inscriptions, control block embedding and other techniques. Second, you're expecting developers of ordinals, inscriptions, stamps, brc-20, etc to *change* their protocol to accommodate. There's zero evidence this is going to happen. Third, you're assuming that these are people that want to act as good stewards of the Bitcoin protocol. They spam specifically to hurt Bitcoin. They've demonstrated this by spamming in the first place. That's like asking malicious spray painting vandals to paint a particular wall that's easy to wash off. Again, no evidence that this is going to happen. The logic is misguided and makes unfounded assumptions.
2025-10-08 15:29:26 from 1 relay(s) View Thread →
There is no technical reason the default should be 100,000 bytes instead of 160. It's a pure power play to win the argument once instead of having to justify increasing the number again and again.
2025-10-07 13:48:47 from 1 relay(s) View Thread →
A lot of very technically proficient people are economically illiterate and get offended when you point out their economic illiteracy. That sums up the current OP_RETURN drama in a nutshell.
2025-10-07 01:13:28 from 1 relay(s) View Thread →
Free issue for the first Monday of the month! Reality Slop Doomscrolling, Parasites and Behavior, Liberalism's Conformity, Annoying Purpose, Empty Consumption, Charitable Giving, Freedom Money, Anti-Node Running, Un-Deprecation, Lightning Disappointment, Invoice Detective, GDP Fudge Factors and more! #Bitcoin Tech Talk #469 https://jimmysong.substack.com/p/bitcoin-tech-talk-469
2025-10-06 14:32:13 from 1 relay(s) View Thread →
Australia is blocking content around Iryna Zaruska, a Ukrainian murdered in the US. Yea, that makes sense. 🙄 Where the Auzzies at?
2025-10-05 23:29:52 from 1 relay(s) View Thread →
A kids smartwatch requires an app to set the time. The app requires registration to work. I can't express how much I hate products like this.
2025-10-05 17:32:17 from 1 relay(s) View Thread →
These tops aren't nearly as violent as they used to be.
2025-10-05 14:23:07 from 1 relay(s) View Thread →
Be grateful when others are complaining.
2025-10-04 16:34:00 from 1 relay(s) View Thread →
Can someone explain why everyone is posting pics saying this is my politics?
2025-10-04 00:59:08 from 1 relay(s) View Thread →
If developers and users have a values conflict, one or the other will change or be replaced. Long-term this is the equilibrium we will head towards.
2025-10-03 13:55:34 from 1 relay(s) View Thread →
Apologies. My client was super slow I think, and I pressed the post button multiple times and it all came through at once. I requested delete on most of them. Here's a picture of a baby monkey that I saw over the summer as penance. image
2025-10-02 14:00:22 from 1 relay(s) View Thread →
Reminder that no one is beyond critique. Especially people tasked with maintaining a $2T monetary network.
2025-10-02 13:39:42 from 1 relay(s) View Thread →
The real lesson of the datacarriersize controversy is the cultural divide between devs and plebs.
2025-10-01 16:26:55 from 1 relay(s) View Thread →
Rest in peace, Voddie.
2025-09-30 18:21:07 from 1 relay(s) View Thread →