matt
Matt Corallo

10th known contributor to Bitcoin Core. Now Full-Time Open-Source Bitcoin+Lightning Projects at Spiral (Part of Block).

Public Key

npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp

NIP-05 Address

matt@bitcoin.ninja

NIP-57 Address

matt@bitcoin.ninja

Profile Code

nprofile1qqsr6tj32zrfn7v0pu4aheaytdnnc6rluepq73ndc2tdjzus34gat9qpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpzamhxue69uhhyetvv9ujucm4wfex2mn59en8j6gxyucky

Publishing to

nostr.bitcoiner.social

relay.current.fyi

relay.damus.io

Author Public Key

npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp

Show more details

Last Notes

2025-06-05 22:16:56

- reply

After the judicial election, republicans viewed Elon as a massive political liability, but wanted to try to find a line where they could kick him out without pissing him off so much that he stopped donating money. That line was super unlikely to exist, so….

2025-06-05 22:15:49

- reply

Elon v Trump lol

2025-06-05 21:56:41

If you don’t recognize this as the fallout from the Wisconsin Judicial election, you aren’t paying attention.

2025-06-03 23:30:35

- reply

Whether you love this administration or hate it (or, like most of us, are somewhere in between), what the next administration does we cannot predict. The only solution is a change to the laws that bind every administration!

2025-06-03 18:53:59

We’ve got one shot at fixing the law or Americans simply won't have access to the best wallets available and US devs will be locked out of providing the best UX!
It’s time for Bitcoiners to fight for our right to access our wallets, before it’s too late.
As most of you know, under Biden, the DOJ decided that ancillary services to noncustodial wallets are MSBs, charging both Samurai Wallet and Tornado Cash with operating an unregistered Money Services Business (nevermind that no regulator would have accepted theirr registration!).
The definition the DOJ used applies not just to privacy services, but also to lightning nodes, rollup sequencers, Ark, Spark, and more. Basically every technology anyone has come up with for providing better scalability, privacy, or user experience for cryptocurrencies requires some kind of ancillary service, the exact things that would be made illegal!
While the Trump DOJ has (partially) walked that back, the next admin will be right back at it - the only solution is to get the law changed so that this isn't a risk in three years.
Luckily, the Blockchain Regulatory Certainty Act was recently re-introduced by Reps Emmer and Torres to fix this issue, but they need our help!
Please, please, pick up the phone and make a 5 minute call to congress, make clear that this is a simple straightforward amendment of the law to bring it in line with existing FinCEN rules. saveourwallets.org will give you the phone numbers to call for your zip code.
#nevent1q…pfm8

2025-05-25 13:33:33

- reply

Just because you can draw an analogy to something physical doesn’t mean that people are going to learn the weird bitcoin-specific jargon and technologies. I’m sorry but you really need to spend more time talking to normies and newcoiners.
And, to be clear, just because the tech happens to be a bit different doesn’t mean it can’t be used in a BIP (3)21. Even the thing demod here ends up in a QR code to provide a channel to send the token to.

2025-05-25 13:30:38

- reply

Not your fingerprints, no they don’t. They also don’t know where you live until you give them a RealID…

2025-05-25 13:24:22

If you’re in Bitcoin and you gave the Feds your fingerprints just for TSA PreCheck….🤦‍♂️

2025-05-24 21:58:03

Every five years I go through old backups looking for wallets that might have money in them. And every five years I realize that was a total waste of time cause I’m looking through the same backups that were empty five years ago.

2025-05-24 15:59:42

- reply

Way, way, way more important.

2025-05-24 15:54:57

Have 25 of the absolute most exclusive hats printed for Vegas. For promoting the actual most important thing in bitcoin this year. Seeking the 25 most interesting heads. DM me.

2025-05-24 15:52:48

- reply

You know you can have a single BIP (3)21 that supports receiving over lightning, Cashu, *and* on-chain, right? And that’s the sender wouldn’t have to know anything about the features their wallet supports or technical details of Bitcoin protocols?

2025-05-23 22:25:42

- reply

> Lots of stores seem to leave it off, maybe wallet support was spotty or something.
Sounds like really bad defaults that need updating!
> Arguably, anyone using Cashu will know they are going to go to their Cashu wallet to pay.
So you’re saying no normies will ever use Cashu? Boy why are we bothering with it then.

2025-05-23 14:03:36

- reply

Yes and then it’s a bug in BTCPayServer. That looks like the payer screen, and that is a horrendous user experience :).

2025-05-23 14:02:29

- reply

Huh? BOLT 12 *is* here? It’s been available in all major lighting implementations for several years now (LND via LNDK). It is a tool you’ve got.

2025-05-23 11:31:49

- reply

Gah! No. Please god no. Do not ever make a sender pick between different receive modes as if they have any idea what “lightning” or “cashu” are. They do not, they want to pay in Bitcoin, let them. (BIP (3)21 lets you embed many payment instructions!)

2025-05-23 11:29:47

- reply

Sure, but you can’t even send a zap over some public NWC endpoint, and even if you could you should still prefer BOLT 12 for privacy reasons.

2025-05-21 16:06:35

What was the custom tshirt company that were secretly bitcoiners? Someone posted it here a week or two ago. Maybe @npub1qny…95gx ?

2025-05-18 18:55:53

You don’t gotta call me out like that man.
#note1typ…j8qk

2025-05-18 18:04:20

The price:mempool correlation looks to be ticking back up. Nature is healing.

2025-05-17 06:18:10

- reply

Hmm?

2025-05-16 14:07:31

https://image.nostr.build/108bbb28f1b8be263529604a3a94cb3a3d266e4b37075484fa5b8104b77998f1.jpg

2025-05-15 01:17:46

- reply

I need the office I work out of to get better cashews, honestly. Roasted in peanut oil and salted instead of fresh and raw 🤮

2025-05-14 00:08:48

One thing I think people have a hard time grokking is that even a moderate amount of hashrate filtering some transactions they don’t like won’t actually drive up the fees those transactions pay, as long as those transactions are relatively time-insensitive.
The market for less-time-sensitive block space is all one market. If one miner mines only a subset of the transactions available, a later miner will pick up the slack and normalize the ratio because they just take whatever pays the most (and those happen to now be the filtered transactions).
You can see this (usually) in the inverse - even though OCEAN filters a ton of transactions (including all kinds of weirdly specific rules that might impact normal transacting), they don’t actually make all that much less in fees - it’s all one market so the filtered transactions bid up the price because the non-filtered transactions don’t know who’s gonna mine the next few blocks.
This changes dramatically when there’s a huge demand spike for transactions they wish to filter (e.g. around the halving) where they may get paid materially less, but we’ve only really seen it the once.
There’s also the case of current OP_RETURNs paying more, but that’s mostly a side effect of one transactor (the OP_RETURN bot) submitting only to Slipstream, which charges more than other options (mostly F2Pool). This isn’t sustainable if there’s sustained demand, as other pools will want in, though there’s little reason to think it will be sustained once the drama dies down (all the people complaining about OP_RETURN are really driving a lot of demand for them lol).

2025-05-13 23:58:12

- reply

> The data says on average people pay a lot more for non-standard OP_RETURN transactions and wait longer. Standardness, then decreases the cost. That's my contention.
I dunno if you can really call 1 sat/vB a “lot” but okay :)
> What miners will do in the face of more non-standard OP_RETURNs being available, I have no idea.
Right but this is what actually matters - by just posting what the market for OP_RETURNs looks like today (when there is very little usage) you give people a dramatically false conclusion (that filters “work” any more than incredibly marginally on the edges).
> What I do know is that there are social costs to mining stuff like inscriptions, which is why MARA has a bad reputation.
Ha, others think MARA is the best. You might want to get outside your filter bubble on this one :)
> Perhaps giving up a little fee revenue is worth not mining spam to some miners. In other words, it's not a straightforward calculation of miners making more money with no downside when mining these.
Indeed, there’s lots of subtle things, but again the point isn’t about “Will miners change code to mine garbage for an extra 1k sats a month”. No, of course they won’t! Will miners start to change things to make a lot more? Of course. Again with your post you’re giving your followers a dramatically wrong impression. And not just wrong, *dangerous*, see my longer form post on MEVil and how confusion here can drive mining centralization!
> So yea, I would expect at least some miners to not mine them. In fact, you know the miners on OCEAN are mostly *not* mining inscriptions and the like, so there's your counterexample right there. How many of them will is the real question, because that naturally reduces the profit they make from the non-standard transactions. But I guarantee it's not everyone and possibly not even the majority as we're seeing here.
OCEAN is a great example! Every large miner I’ve ever spoken to has laughed at the idea of mining in a way that pays them at all less (even though in general OCEAN’s payment aren’t that much less - see my previous post about it all being one market and some portion of hashrate refusing to mine inscriptions not impacting their price - it goes both ways!). Some smaller miners mine on OCEAN with their own block templates that don’t filter, but the rest are hobbyists who don’t care all that much.

2025-05-13 17:08:05

- reply

@nevent1qqst4hnz0ufpkyhuggmxcd52wp6gwdlv7xcp8flv9klm6ec7x8awjrspzfmhxue69uhk7enxvd5xz6tw9ec82cspp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqlg3xey

2025-05-13 16:31:05

- reply

Yes, IIRC Slipstream charges something like 2x for its use. Your data lines up pretty good with that. But that also doesn’t imply anything about standardness materially increasing the cost (F2Pool doesn’t charge extra at all!).
More importantly, if there’s any material sustained demand is your claim seriously that miners wouldn’t just run Libre Relay and instead watch their competition make 3% more revenue (a huge increase in profit!)? Or are you claiming they’ll just go out of business and this is good for bitcoin?
#nevent1q…ks6s

2025-05-13 11:00:11

- reply

And, again, my point above was about what happens when people *regularly* want to create non-standard transactions. As long as it’s incredibly rare, there’s not a lot of demand and only one or two pools might offer it (indeed, F2Pool and MARA today). The whole start of this drama was because a potentially-large transactor wanted to fill the UTXO set with garbage because they didn’t want to rely on OP_RETURNs. Obviously that changes the calculus here.

2025-05-13 10:55:00

- reply

Oh come on Jimmy. Lots of transactions in general pay too high a fee. With such a small sample size that’s not evidence of anything.

2025-05-13 10:54:49

- reply

Oh come on Jimmy. Lots of transactions in general pay too high a fee. With such a small sample size that’s not evidence of anything.

2025-05-13 00:44:38

- reply

Eg https://bluematt.bitcoin.ninja/2025/05/07/mevil-of-relay-policy/

2025-05-13 00:42:10

- reply

And, more generally, I didn’t claim that filters don’t work period. Indeed, as long as there is very little revenue to be had from the spam there is some cost to working around them. They’re maybe good for like 0.1 sat/vB in additional cost from effort and whatever. But it’s very very little, and if there starts to be lots of transactions that are non-standard then it will get driven down further (while driving small miners out of business!)

2025-05-13 00:40:27

- reply

It’s double the regular fee if you use a bot run by someone taking a cut before MARA takes a cut with Slipstream….Libre Relay should get you mined with 1 sat/vB no problem (used to be F2Pool ran that, no idea what they do now but generally they’ll mine anything).
Your assumption about delays driving fees up only holds if those transactors are incredibly time-sensitive. If they aren’t (which is true of most of the inscription nonsense people) then it’s all one market - There is N weight in block space created in a day and only maybe 3% of it is restricted to non-inscriptions (or whatever). The inscription people will just get into the remaining 97% of block space that is now slightly less full because the filtooring hashpower took somewhat lower fee non-inscriptions.
There’s some edge cases around if the 3% of filtooring miners find a few blocks in a row so the prevailing feerate is somewhat lower in their blocks than others, but with so little hashpower it won’t happen.

2025-05-12 19:08:49

- reply

At the time, Bitcoin Core scaled poorly. We didn’t have things like compact blocks and were not really ready to handle actually full blocks. Further, things like Slipstream and Libre Relay didn’t exist so policy wasn’t completely useless, though obviously it still only fairly marginally increased the cost of finding a miner to mine non-standard stuff (though F2Pool was mining non-standard stuff regularly not too much later than this). Finally, there didn’t seem to be a ton of demand for these kinds of transactions, just people exploring backing up their data to the chain, so nudging them away from that was effective (compare to today where it not only wouldn’t be effective, it would harm most miners in favor of MARA) vs today where we have transactors putting crap in the UTXO set to get around the limit, which is obviously much much worse.

2025-05-12 18:41:12

- reply

Are you really suggesting that nothing material to this has changed in Bitcoin in a *decade*? Come on…

2025-05-12 17:39:56

- reply

Only very very very very marginally. Ultimately if they don’t get mined this block that just means there’s more of them (and fewer normal transactions) for the next miner that isn’t filtering. Over the course of a few blocks it averages out.
It only actually works if you have more miners blocking spam than the portion of spam transactions.

2025-05-12 17:38:11

Bitcoin down on a day where the market is celebrating. Honestly good for Bitcoin.

2025-05-07 16:49:32

Learn more about OP_RETURN and why making standardness less restrictive isn’t just Bitcoin Core navel gazing, it’s actually very important for Bitcoin!
#note1pky…9haj

2025-05-06 11:40:15

- reply

It is fundamentally improve to prevent those who want to store data on chain from doing so. There’s nothing to investigate there, there’s only worse ways of doing it and better ways of doing it.
> On top of this, I do not think it is unreasonable to point out that there are people involved in making this decision who will benefit from being able to store large amounts of data in op_return.
I don’t believe this is true. The Citrea instance isn’t material to them. They’re gonna do it either way, either in a really shitty way that bloats the UTXO set or in a better way. The only impact is on Bitcoin, not them.
> rushing this will increase the chance of forks
Huh? This is mempool policy, not consensus logic. People can run other code if they want to but there’s no chance of a fork for mempool policy.
If you mean that people will fork Core, I mean, okay? The issue is ~all the engineers working on Bitcoin Core and mempool policy agree with this change (which should tell you something, they don’t often all agree!), so maintaining a fork without any of the people competent at doing so is not gonna end well.
Or you end up like Knots, a one-man project shipping a ton of barely-tested patches that zero people aside from Luke have reviewed. That’s not a serious project.

2025-05-06 11:32:31

- reply

Have you looked at the mining centralization chart? If that’s not cause for concern I dunno what is.

2025-05-06 11:29:56

- reply

Thank you for asking good questions!

2025-05-05 20:53:40

- reply

In general, my view is software shouldn’t have options that let you shoot your foot off, even accidentally. Even if you can live fine without a foot, you probably prefer to have it.
For relay policy, divergent rules tends to be that. There may be some exceptions (like “I have little CPU power and can’t process complicated packages of transactions” or “I have little memory and want a smaller mempool” or even “this may get used in the future but it isn’t now so have an option so people can enable some new transactions without upgrading”), but in most cases divergent policy is simply divergent policy, and only harms the user”.

2025-05-05 17:40:50

- reply

The problem is there are very real and very significant consequences to mining centralization if ~all the valid transactions people want to make are not readily available to any miner running Bitcoin Core. So changing the option (a) doesn’t impact how much data people can store, they can just store it in a new place that’s more expensive (not sure why they would but even if they do great, they’re storing less data) and (b) it materially improves Bitcoin’s robustness.
I get that it feels icky, but the facts on the ground are pretty clear.

2025-05-05 17:37:24

- reply

As for the “just leave it an option and change the default”, there’s no reason to do that that I’ve seen either. As you note, most nodes run with the default options, so it doesn’t delay or prevent these transactions from being mined. The only impact it has is it makes you and your peers use more bandwidth and slows down block propagation.
Having policy be configurable is actually a really bad idea generally, and including this specific case.

2025-05-05 17:35:48

- reply

> think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.
To be clear, there I was referring to the consensus rules. The consensus rules are, literally, the definition of Bitcoin. So I was drawing a distinction between the code that literally defines Bitcoin and the rest of the code in Bitcoin Core.
> And as we've learned from the discussion, defaults are incredibly sticky.
I think this is very much the wrong takeaway. Rather, if we look at actual network behavior and the transactions that get mined, our takeaway should be “if Bitcoin Core doesn’t relay it, and its consensus-valid, someone will build some shitty centralized relay alternative that will be used”. Yes, Bitcoin Core’s defaults might largely decide the P2P relay rules, but those don’t matter if transaction creators are just routing around that network!> think from the outside perspective, your framing of the "definition of Bitcoin" is a bit worrisome.
To be clear, there I was referring to the consensus rules. The consensus rules are, literally, the definition of Bitcoin. So I was drawing a distinction between the code that literally defines Bitcoin and the rest of the code in Bitcoin Core.
> And as we've learned from the discussion, defaults are incredibly sticky.
I think this is very much the wrong takeaway. Rather, if we look at actual network behavior and the transactions that get mined, our takeaway should be “if Bitcoin Core doesn’t relay it, and its consensus-valid, someone will build some shitty centralized relay alternative that will be used”. Yes, Bitcoin Core’s defaults might largely decide the P2P relay rules, but those don’t matter if transaction creators are just routing around that network!
> I think we are giving too much credit to that being a reality and not enough credit to the reality that the majority view Core as Bitcoin, and having to "prove" them wrong would be much more harmful than not.
Where are you getting this from, though? Every day, many, many non-standard transactions get confirmed. With turning off RBF it was clear that if Bitcoin Core doesn’t provide something, someone else will, and many miners will use it! (In this case Peter Todd’s patch set). With Slipstream it’s similarly evident that any policy rules Bitcoin Core makes just don’t add up to anything but giving Mara more money at the expense of other miners.

2025-05-05 14:21:49

- reply

Yes, in both cases it has no impact on Bitcoin’s consensus rules nor the “definition of Bitcoin”. In both cases, if the decision is “wrong”, the network will simply route around Bitcoin Core (either with a different wallet or by using things like Slipstream).
Yes, obviously the GUI is less likely to cause problems for other Bitcoin users than P2P changes but in both cases this is a question for the open source contributors of Bitcoin Core (which is an open process everyone should provide feedback on!), not one that gets decided by “consensus” and doesn’t change without it.

2025-05-05 13:56:08

- reply

People currently embed data in the chain via witness data (which allows them to embed 4x more data), often using Slipstream to get nonstandard transactions mined. I don’t see any reason to think allowing additional OP_RETURN data would increase the amount of data stored in the chain.

2025-05-05 13:13:00

- reply

I’m happy to answer any question you have! I don’t see any tradeoffs at all, actually (not that I’m happy people want to embed data, to be clear I’m not!)

2025-05-05 12:35:50

- reply

This isn’t an argument, it’s just “wellllll, I haven’t thought about it that long so hold off until I do”? This debate is a decade old, that’s on Adam.

2025-05-05 12:21:58

- reply

I’m working on a writeup, but the TL;DR is basically that if it were to become popular, small miners wouldn’t be able to compete because only the large miners see a large portion of the transactions that pay them fees.

2025-05-05 12:20:55

- reply

When someone provides one argument that stands up to the slightest bit of scrutiny why paternalistic node policy is a good (or even neutral) thing, I’ll happily change my tune. Until then…

2025-05-05 11:26:30

I think this is an important thing to grok - there is no reason Bitcoin Core should be bound by “consensus” for things unrelated to Bitcoin’s consensus rules.
Bitcoin Core is a software project with a wallet, a GUI, an RPC API, and an implementation of a P2P network for rumoring blocks and transactions. For all of those things, there’s no reason for Bitcoin Core to only act with “consensus” - can you imagine if they needed consensus of the community to make opinionated decisions in the GUI?!
But specifically on the topic of the P2P layer - Bitcoin Core contributors’ jobs are to be good stewards to that implementation and do what is right for Bitcoin to maximize decentralization and robustness. There’s no debate (except from people who don’t understand Bitcoin) that reducing or removing paternalistic censorial standardness limits is not only good but possibly important for Bitcoin’s long-term decentralization.
There is nothing that says anyone has to run Core, and there is nothing that says Bitcoin Core must only do things when there exists consensus in the broader Bitcoin community, especially when it’s abundantly clear those things are important for Bitcoin.
None of this applies, of course, to Bitcoin’s consensus rules - that sub-project of Bitcoin Core has drastically different constraints.
#note1ask…w4ge

2025-05-05 02:36:54

- reply

Less auto-immune response would be nice, though, tbh.

2025-05-05 02:36:27

- reply

……isn’t that supposed to be a winter thing?

2025-05-04 15:03:41

- reply

Not well

2025-05-04 04:18:42

- reply

Anyway here’s some random shit that’s weirdly good (ignore the nonsense YouTube video) https://m.youtube.com/watch?v=7gq_g4AeLsM

2025-05-04 04:10:49

- reply

And because there’s no way Nostr appreciates this, here’s a classic from where I’m from https://m.youtube.com/watch?v=W3vRF7eOwP0

2025-05-04 03:59:16

Alright by popular(?) demand, here’s a great track from Shazam in a restaurant bathroom which it turned out was a Moroccan family band. https://www.youtube.com/watch?v=T7vycrwxRLY

2025-05-04 03:54:24

Currently I post more detailed Bitcoin stuff here, less detailed Bitcoin stuff on Twitter/X, and music on BlueSky. Should I start posting music here or would people be annoyed cause they just want Bitcoin content?

2025-05-02 11:17:02

- reply

Yes

2025-05-02 00:13:20

- reply

That was true months ago, I believe they’ve taken on more leverage since.

2025-05-02 00:12:54

- reply

That was true months ago, I believe they’ve bought a lot since.

2025-05-02 00:12:20

Its really obvious who actually pays attention right now and who is just getting their information tenth-hand from this site.
Bitcoin Core GitHub has always been for technical discussion relevant to the specific PR to avoid it being impossible for them to get any work done. There are many other places to have broader discussions (e.g. the mailing list, IRC, delving, etc).
Bitcoin Core is *finally* enforcing this rule, which is incredibly healthy for the project as it allows developers to stay focused, and people are upset because they only get bad takes on this site and don't actually research what happened. If you went and looked, you'd see that people who got banned were repeatedly making off-topic comments and didn't stop when it was made clear they should. That deserves a ban in *any* community.
As for the specific thing going on, yes, sadly having a relay policy in Bitcoin Core that accepts all the transactions that people want to make (in this case Citrea wants to make) is a *critical* feature of the Bitcoin network. It ensures small miners (like Ocean!) are able to compete by making sure all transactions are available to everyone, rather than only available to large pools like @MARA via their Slipstream product or ViaBTC via their accelerator.

2025-05-01 22:14:00

- reply

There’s always a liquidation price, doesn’t mean it has to be explicit.

2025-05-01 20:44:53

What is the (Micro) Strategy liquidation price up to?

2025-04-29 14:32:15

While everyone was distracted, Bitcoin Core doing the important work https://github.com/ordinals/ord/issues/4335

2025-04-29 11:44:23

I really love when people obsessed with censoring the blockchain get mad about getting banned for brigading and trying to prevent others from doing their work.

2025-04-29 11:27:25

- reply

Bitcoin Core’s GitHub exists to allow contributors to contribute and build good software. Sure, banning people who show up with no intent to contribute creates drama elsewhere, but “are you preventing contributors from contributing” is a pretty clear line. If people can’t stomach that, that’s on them.

2025-04-29 09:59:52

Honestly incredibly excited that Bitcoin Core folks are finally more strictly creating an environment where contributors can focus on code rather than letting things get bogged down in stupid drama. This is incredible news for Bitcoin.

2025-04-23 15:13:57

- reply

Huh? TXHASH is way more understandable - you have some flag bits and you hash those parts of the transaction. CTV is a very specific version of that and you have to understand whether it’s the “right” one.

2025-04-23 03:29:35

- reply

> First is that CTV is relatively way more mature. Been around for a while and hasn't changed much since. So it can be adopted fast. TXHASH still has quite some room for bike-shedding.
This seems like a pretty bad reason to decide on a specific soft fork that we’re committing to for decades, at least when the second option isn’t like crazy complicated and would require a five years of work to “finish”.
> While TXHASH is way more flexible it's also an order of magnitude more complex, mostly code-wise. Needs quite some caching etc, so the code is far from trivial.
Honestly this doesn’t seem that complex? Some tx hash caching already exists so adding a few more cache entries seems…. Incredibly doable?
Honestly these seem like incredibly weak reasons (not saying they’re not the reason, just that if they are, we should choose a different path).

2025-04-21 21:09:11

- reply

For a dev? Not really, CTV is a special-case of TXHASH, if you want CTV you can use that mode.

2025-04-21 21:08:41

- reply

In the abstract, sure. But specifically in this case? The whole point of CTV was it being “not recursive”, but with CSFS it kinda is, and more importantly no one seems to actually want to avoid recursion (and now it’s not even in the BIP).

2025-04-21 17:14:12

Is there a reason why people are pushing CTV currently over TXHASH? It seems like the second is strictly more flexible and I haven’t seen a reason why we should prefer not-that. Maybe @nprofile…fg4m ?

2025-04-15 00:56:46

- reply

You absolutely cannot start from scratch here. I mean if you have like a trillion dollars to burn hiring engineers, buying equipment, and creating process nodes that you throw away maybe? But even then you’re probably better off just acquiring Intel and then driving their process nodes to leadership.

2025-04-15 00:49:25

- reply

Isn’t this better done with BOLT 12? That way a sender/responder could make the payment and include proof-of-payment in the same note as the comment itself. Anyone can trivially verify the proof of payment by looking at the recipient’s profile and there’s no need to have multiple notes flying around for one comment.

2025-04-14 21:10:03

- reply

Packet loss, but it’s a general complaint form.

2025-04-14 20:08:54

For Americans, I cannot recommend the FCC complaint form enough. Fill it out and suddenly your ISP will harass *you* to get your internet issues fixed.

2025-04-14 19:26:42

- reply

Chipfabs specifically is a question of being bleeding edge. There are a lot of chipfabs (including some post-fab processing) in the US (they’re high value-added goods, we manufacture a lot of those in the US!). But it’s fierce competition between Intel and TSMC. So to get Intel to be dominant it’s mostly a question of fixing bad leadership at Intel and making sure the best engineers want to work there.

2025-04-14 01:28:09

- reply

lol that’s not true, China imports a ton for their electronics, but more importantly, you can’t start from zero, if you want people to manufacture you either have to dump a few hundred trillion into factories (which we don’t have the manpower or supplies to build, doubly so since they’re now tariff’d lol) or be willing to import low added value goods so that you can build the high added value goods.

2025-04-14 01:06:40

- reply

Not particularly oversimplified, no.

2025-04-13 01:20:06

I appreciate that finished electronics are now tariff-exempt as it ensures no one would ever dare dream of trying to build electronics in the US, and luckily they don’t have to!

2025-04-07 21:53:36

I wish I had some bad news to announce cause man this week would be a perfect time for it.

2025-04-07 00:53:42

- reply

AFAIU they work through generic HTTP callbacks. Implementing a LN-Address server can create invoices without being on the same server as the node, or it can be behind a reverse proxy to hide it. You can proxy the outbound response but (a) I absolutely refuse to have a TLS client in my lightning node 🤮, (b) some websites block Tor anyway so callbacks may not be as reliable and (c) proxying through Tor is a bunch more work than just serving being a reverse proxy.
Generally the zap design is horrendous and only makes sense for custodial wallets that already run a bunch of HTTP infra. Luckily there’s a better way (just literally do a BOLT 12 payment and have the payer post the payment proof as a nostr event, rather than making the payee’s lightning node somehow nostr-aware), but need movement there.

2025-04-05 23:50:34

- reply

Zap receipts reveal the location of your node and are generally a really terrible idea.

2025-04-02 19:52:58

- reply

“The users’ coins are self-custodied” does not say anything about how you aren’t self-custodying *bitcoin* but rather an IOU for bitcoin.

2025-04-02 19:27:12

- reply

Read it again.

2025-04-02 19:14:51

- reply

You could say that you’re self-custodying “Liquid Bitcoin”, but this isn’t self-custodying “Bitcoin”.

2025-04-02 19:02:10

- reply

This paragraph maybe, but self-custody is used several other times in the same article.

2025-04-02 18:30:23

- reply

If a custodian holds your funds, it’s not “self-custody”. That’s pretty black and white lol

2025-04-02 18:29:06

- reply

Custodial. Or, if you prefer, multisig-custodial.

2025-04-02 18:16:20

Since when are funds held with a custodian “self-custody”?
I guess we need a new word for “custody” now that it has absolutely lost all meaning.
https://image.nostr.build/9db6a3b93c3a33f676bbf246c1be102547cd972db5977782cae3479be31b3e6f.jpg

2025-04-01 11:31:58

- reply

Nope, it just spawns too many threads all at once so you don’t get predictability on a platform like windows with two threads on a slow CPU. Windows really just is not a real operating system, it’s a toy that somehow convinced people to use.

2025-03-31 21:56:29

- reply

Did you read the quote? Point was the it’s lazy name-matching, not actual targeting people with objectionable social media posts.

2025-03-31 16:33:36

Gonna end up kicking out everyone named Muhammad. Horrendous for long-term competitiveness of the country.
#note1sux…nzde

2025-03-31 12:23:24

- reply

“Provided as an API by Wallet of Satoshi”. Oof, glad that’s being removed, honestly.

2025-03-31 11:01:21

- reply

It might be, it might not be. Either way the OS doesn’t incur additional cost (since it’s doing it across applications already) and it provides for a more robust platform. In what world is it reasonable to ship an OS in this decade that is a less robust platform just because?
(I’ve hit it a few times in many-threaded tests, eg the rust test runner, in the latest it makes it basically impossible to test https://github.com/lightningdevkit/rust-lightning/pull/3680 on windows).

2025-03-31 10:58:15

- reply

I mean in terms of privacy, in comparison, it’s basically strictly better? It switches who learns the list of client IPs, but now matching that to plaintext traffic takes two entities working together instead of just one of them.

2025-03-31 00:23:24

- reply

It uses Mullvad for the second hop, so basically strictly better?
(Disclosure: am investor)

2025-03-31 00:22:48

I’m always astounded that windows, still, in the 21st century (let alone a quarter of the way through it!) thinks that cooperative multitasking is an acceptable thing to do. Like…. What?!
(It only does this within a single application across its threads, but, still…what?)