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

[email protected]

NIP-57 Address

[email protected]

Profile Code

nprofile1qqsr6tj32zrfn7v0pu4aheaytdnnc6rluepq73ndc2tdjzus34gat9qprpmhxue69uhkku3wwp6hyurvv4ex2mrp0yhxxmmdqy0hwumn8ghj7mn0wd68yttjv4kxz7fwdehkucm99eskxctyv4khjq3s0zs

Publishing to

kr.purplerelay.com

nostr-relay.nonce.academy

nostril.cam

Author Public Key

npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp

Show more details

Last Notes

2024-12-28 06:47:07 GMT

Run a bitcoin payment processor so that normie merchants can accept bitcoin and we can spend bitcoin (which was half the damn point)? Congrats you have to ask for the socials of people paying 🤦‍♂️ #note1vxz…j98n

2024-12-22 23:21:15 GMT

- reply

A backdoor is a backdoor whether it’s described in the documentation and public or not.

2024-12-22 22:26:45 GMT

- reply

The app description explicitly lists a privacy backdoor for governments? It’s literally the design of the GNU Taler project (to build ecash with a limited backdoor to prevent money laundering/tax evasion).

2024-12-22 16:53:44 GMT

I once had a discussion with a GNU Taler dev, who argued with a straight face that the government should have a (limited) backdoor into financial systems despite voters sometimes electing bad people because, and I’m dead serious here, the German voters would never elect someone with as authoritarian tendencies as Trump.
I guess he missed his history lessons…in literally every year of school there lol #note1vhh…jzmn

2024-12-19 04:18:41 GMT

Anyone else find it kinda ironic that the Bitcoin 100k push came after an off-hand comment by the Fed chair, and now Bitcoin is down 5% on Fed chair comments?

2024-12-18 22:27:34 GMT

- reply

Tyler from your team made the graphs for me!

2024-12-18 20:42:54 GMT

LDK’s new pathfinding tuning is pretty predictive of the real world! https://image.nostr.build/7e94329c4fe010a97736a339b2269b38d6bb55207d394b87e8f68938ff18d525.jpg

2024-12-15 22:34:27 GMT

- reply

I’m told this was in fact a design goal of Taproot, but somehow I wasn’t aware of it. 🤷‍♂️

2024-12-15 22:29:51 GMT

Turns out Taproot is great for post-Quantum in Bitcoin. https://groups.google.com/g/bitcoindev/c/8O857bRSVV8

2024-12-15 01:15:50 GMT

- reply

Vinny with a bad take? Huh, whod’a thunk it.

2024-12-13 14:48:25 GMT

- reply

So disappointing that I’m their rush to scale Bluesky dropped all the decentralized moderation architecture they built. Just embarrassing.

2024-12-11 15:32:19 GMT

- reply

Nor that. Taking all the counts and adding up the total maximum sentence for each is not how federal sentencing works (and not just any kind of “in theory the judge could….” kinda way, they can’t do that).

2024-12-11 15:28:49 GMT

No, Roger is not facing 109 years in prison. That’s not how federal sentencing works, that’s never how federal sentencing has ever fucking worked. Stop quoting morons who don’t know how things work.

2024-12-11 14:04:53 GMT

- reply

Sure, you can just hide the message behind a tap - removes the message from the payments list but users can still see it. Sadly, I think you’re right - and frankly dunno that the messages are worth having 🤷‍♂️

2024-12-11 13:30:51 GMT

- reply

Wallets should just not display the message (under a certain threshold?) until the user taps into the transaction. That takes the value away for advertisers but retains the original purpose.

2024-12-11 13:26:27 GMT

- reply

Nah, for travel you need bag structure to put things in their place and have them all stay there. Especially important for clothes to avoid wrinkles.

2024-12-11 13:25:40 GMT

- reply

I mean if it has a hard back I’m not sure why collapsible helps? Pushing an empty full suitcase isn’t all that hard if it has four wheels…
But, yea, a proper four wheel suitcase (I’m partial to TravelPro over Away but whatever) is the way to go for actual travel use-cases - sturdy, not annoying cause the sides are always collapsing when you’re trying to put stuff in, hard sides also give structure for where to place items as you add them, etc. But for events…I dunno, if you really want something collapsible, I dunno what’s good, not a lot of competition for such things because they suck for travel.

2024-12-11 05:44:48 GMT

- reply

Well see, there’s your problem, you prefer terrible suitcases.

2024-12-11 01:46:45 GMT

- reply

Why are you sending automated abuse emails?

2024-12-11 01:43:20 GMT

- reply

His book came out *after* this “all started happening to him”. He’s just an asshole who’s sad he lost and can’t accept it.
(Sure prison time of that long for tax evasion is probably not right either, but there are worse miscarriages of justice)

2024-12-11 01:40:54 GMT

Snakes who spent years trying to destroy Bitcoin should stay in their holes rather than trying to emerge and claim they were the savior all along.

2024-12-05 02:39:13 GMT

And that’s 100k

2024-12-04 05:48:00 GMT

- reply

Right, the lightning -> on-chain direction is instant, but the issue is the other way.

2024-12-04 04:14:55 GMT

- reply

I interpreted your design as “hold funds in a custodial lightning wallet until they get big enough, then pull them on chain”. The problem with step two is now to send them back out over lightning you first have to do an on-chain transaction to set up a swap, which will be a terrible UX for paying lightning invoices.
The design makes a hell of a lot of sense otherwise (it’s kinda the old mutiny model), just have to hold the funds in lightning channels.

2024-12-04 01:03:51 GMT

- reply

You really want the withdrawn funds to still be able to pay to a lightning invoice for decent UX, though, so you really need to withdraw to a channel.
Users get really sad when they can’t send their full balance in one transaction to any payment method supported.

2024-12-01 03:43:28 GMT

- reply

That does not solve the issues, sadly far from it.

2024-12-01 03:18:10 GMT

- reply

Congrats!

2024-12-01 03:17:05 GMT

Decentralization is hard. Everything sucks. #note17d3…sjjd

2024-12-01 02:08:48 GMT

- reply

(The LDK “historical model”, however, seems to do okay, keeping histograms of the liquidity bounds)

2024-12-01 02:04:09 GMT

- reply

Err, no, sorry, that’s wrong. Degrading instantly is bad (the learning does help!), but the model itself is worse than the naive “I dunno, 50/50 always” “model”, even when you learn.

2024-12-01 01:31:06 GMT

- reply

At least my initial analysis of the data seems to say that degrading instantly is better than any other time constant 😭. (May just be some nasty bug in the way we’re calculating probabilities?)

2024-11-30 04:10:38 GMT

- reply

Dunno if you saw https://bluematt.bitcoin.ninja/2024/11/22/ln-routing-replay/ but I recently started being more rigorous about our pathfinding scorer. Might be something to play with, it seems like the simple “just keep upper and lower bound on each channel’s liquidity” approach performs *worse* than always assigning each hop a 50% success probability. Keeping a histogram of those bounds, though, does reasonably good.

2024-11-26 20:10:46 GMT

- reply

Sudden distribution of cash to a bunch of people could cause a nontrivial bump in spending, offsetting the crash in spending being predicted due to layoffs and other economic headwinds. It was mostly a joke, though, I don’t think there’s that many people with that much bitcoin trying to sell that much bitcoin with that much demand for bitcoin…

2024-11-25 00:50:36 GMT

- reply

The options are that or constantly be annoying other people cause you aren’t doing stuff you promised them to keep focus 😭

2024-11-25 00:42:18 GMT

- reply

#nevent1q…eegr

2024-11-24 19:12:07 GMT

- reply

Yea, I mean the ETH zkRollups are super centralized but to some extent that’s a consequence of these things being hard to build so they need an “escape valve” in practice. There’s not a lot of motivation to remove that but I assume it’ll get removed eventually…. just may be a while.
I do think it’s somewhat informative that ETH only built *rollups*, which certainly don’t have a huge scalability multiple themselves (doubly so for payments, though it’s important to note ETH is trying to scale computation, not payments).

2024-11-24 19:06:12 GMT

- reply

There’s a bunch of research on the limits of things - Shielded CSV/rollups (though want to see the limits of a CSV thing if we build a version you can do lightning on top of), Ark/timeout trees is a cool set of ideas that feels like it could be extended, etc. The results certainly don’t point to us having any silver bullets, but I think some of those things probably with some more tweaks may give us a nice direction. But certainly want more analysis.

2024-11-24 16:00:30 GMT

This is much better phrased than I can. I’m really, really happy that lots of people are doing *research* into how and what kind of covenants get us the best outcome, but that doesn’t mean we need to rush into anything, maybe the opposite. #note1yae…4aq6

2024-11-24 00:43:45 GMT

- reply

I think interesting ideas using it were eventually proposed…..after most people had given up on CTV 🤷‍♂️

2024-11-23 21:54:27 GMT

I responded on Twitter too, but this is such a strange rant to me.
Bitcoin Core (contributor)’s current push for better mempool policy is *directly* related to multi-party UTXO ownership and scaling. It specifically substantially improves lighting in practice today, and will certainly be required for any future scaling technologies.
In the mean time, lots of folks (like James) continue to do research into how to scale Bitcoin (and cryptocurrencies generally). There’s no reason to care if that happens from Bitcoin Core contributors or others, and we’re still really far from having any particularly good ideas on this front. As that research continues, there’s no reason for concrete software towards short-term soft-forks. #note16h9…tlgm

2024-11-23 17:39:13 GMT

- reply

To be fair, we’ve also cut the bandwidth needed to stream live video by many multiples.

2024-11-17 22:31:18 GMT

- reply

But, yea, people love filter bubbles (censorship being just one way to get that), that’s why most people are on nostr, too! :p

2024-11-17 22:23:58 GMT

- reply

I think having an algorithmic feed resonates with people a hell of a lot more, certainly drove early adopters.

2024-11-17 22:11:21 GMT

- reply

IOW there seems to be a string desire on here to dismiss Bluesky for trivial reasons (“not decentralized”/“they got MSM coverage so the user growth doesn’t mean anything”/etc) rather than admit they’ve built a product that resonates with a large number of people and that has cool features we should learn from!

2024-11-17 21:55:38 GMT

- reply

I don’t *think* it will necessarily become properly decentralized, but rather that it totally *could* and they are working toward it (whether they run out of resources before they get there I dunno), thus I think dismissing Bluesky as “not decentralized, next” is naive.
But I can tell you for sure there the “custom feeds” feature, at a minimum, led to substantial early adopter/evangelist momentum. To a much lesser extent the decentralized labeling/moderation/censorship feature as well.
Even if they didn’t drive material user adoption, they’re cool features we should be learning from, not dismissing the whole thing “because it’s not decentralized”.

2024-11-17 21:08:07 GMT

- reply

Not sure there’s much else in that post? Only other point you made is that the only other relays are mostly for hobbyists stuff, which I think is mostly true. Don’t disagree so why respond to it :).

2024-11-17 21:03:49 GMT

- reply

Making the assumption that every relay is going to see ~every post is very much not the same as assuming there will only be one relay. You’re just putting words in peoples’ mouths, then.

2024-11-17 21:02:45 GMT

- reply

AFAIU you can have an App View that uses a relay, but could also be one software package. conceptually for the purposes of this discussion it’s really one thing.

2024-11-17 20:03:40 GMT

- reply

But really I do not at all understand your comment here - literally the Bluesky devs encourage other relays to exist, and other people *do* run relays, just not very many because of the overhead. Suggesting that they view multiple relays as a bad thing is…. strange to me 🤷‍♂️

2024-11-17 19:58:44 GMT

- reply

The comment about relay being an optimization was somewhat nitpicky, you’re just using the wrong term (technically the relay is a proxy between all the PDs’ and the app view, the app view stores all the posts too and you could drop the relay and replace it with the app view(s) connecting to all the PDSs directly).
The “App View” is a server that returns the posts to display in the feed to clients (eg the mobile app). In practice the App View is what *has* to have a full copy of all the tweets, much like a nostr relay works in practice today.
Clients simply making the same request to multiple App Views wouldn’t result in having to rewrite or throw anything away, I have no idea why you’re suggesting that - in general you’ll get the same response from each, just have to merge them on the client side.

2024-11-17 19:50:59 GMT

- reply

How is this materially different for nostr relays? Sure, nostr clients connect to a few relays, improving censorship resistance greatly, but generally nostr relays are expected to have a large majority of all notes in the social context.

2024-11-17 04:26:28 GMT

- reply

Yes, you’ve just explained nostr though?

2024-11-17 03:26:40 GMT

- reply

But most of the articles are *about* how people are moving. You’re confusing cause and effect :)

2024-11-17 03:20:41 GMT

- reply

I don’t think anyone is suggesting that Bluesky’s decentralization is here or substantial. It might be in the future, but it certainly isn’t now. The point is more that we should learn from their feature set, because they have some features that are very decentralizing of power within a social network, even though they run on centralized rails.

2024-11-16 19:16:10 GMT

I don’t really understand this kind of criticism (and not to pick on Will here, it seems to be from ~everyone).
Bluesky took a different approach - first build a product people want whose technology supports decentralization, and add the features the geeks want later. It’s easy to shit on their lack of decentralization, but Bluesky has made clear and consistent progress on that front since day one, and I assume they will continue to do so.
The result has been a product that’s growing (those user stats are pretty realistic, doubly so when you look at the number of accounts actually posting real content) way more than nostr with tons of anti-centralization features that nostr is missing (anyone can create a feed algorithm, and there are many, decentralized content tagging is a really cool innovation - different “adult content” tagging services, opt-in different moderation services, etc).
The federated model of Mastodon led to a trainwreck of fiefdoms run by weirdly obsessive and controlling mods, but Bluesky took that and addressed the issues by splitting moderation from hosting.
Sure, Bluesky’s hosting model means you don’t get the relay-redundancy that sets nostr’s censorship resistance apart, but that’s not all that hard to add in the future (with the sync assumption they make making it easier to make efficient, too).
Building the kinds of stuff Bluesky has on nostr is gonna take a huge investment, we can’t leave folks like Will stuck building critical nostr apps by himself. #note1vpt…ann4

2024-11-11 23:46:11 GMT

- reply

And yet it’s growing at a rate that nostr isn’t. Sadly “supports an algorithmic feed” seems to be a pretty important feature if you want users to join a social media platform. Luckily nostr could support such a thing, but we have a lot of catching up to do.

2024-11-06 16:32:53 GMT

Not that Kamala wasn’t a pretty poor candidate or that Trump didn’t generate excitement, of course, but the economy is a *really* strong headwind in any election. Don’t overread the general populace’s desire to “vote crypto” or for any other specific issue. #note1vpz…td56

2024-11-06 16:28:54 GMT

- reply

A lot of the “Trump won because….” takes feel incredibly US-myopic. This was the year of more democratic elections across the world than almost any other and nearly all of them “surprised” in how strongly they voted against the party in power (both left and right). The universal rule of politics remains undefeated - people vote their pocket books.

2024-11-01 02:24:09 GMT

- reply

Memtest doesn’t tend to get your CPU hot, though. Different things can fail at different utilization levels…

2024-10-26 12:40:30 GMT

- reply

#nevent1q…j399

2024-10-26 02:21:10 GMT

One team is led by a fraud who thinks he knows how to handle a sword, the other hires an actor who can dress up in a puppet outfit and convincingly hold a sword. We are not the same. https://image.nostr.build/ebe171cabf0cd2820da3c97d687225246664ea70f15e12417c7264d44c27f356.jpg

2024-10-24 13:00:50 GMT

- reply

Hopefully not on testnets!

2024-10-23 22:11:52 GMT

- reply

Yep, that’s why I didn’t say 1000 sats :). Even 100k sats is a lot for a channel, tho, tbh.

2024-10-23 22:02:03 GMT

- reply

The whole point of testnets is that any amount is equivalent. There’s no reason to ever want a whole or event 1/10th a coin.

2024-10-23 02:40:15 GMT

- reply

You can even make bets on leverage 🎰🎰🎰

2024-10-23 02:39:43 GMT

It’s kinda funny that there’s now legal betting on US election outcomes on CFTC-regulated markets through brokerage accounts but you can’t place the same bets at a casino.

2024-10-22 01:55:37 GMT

- reply

Yea, you can do multisig channels (indeed nested musig) for lightning (well, 66%+1, not 50%+1, sadly), but you’re still doing the “I communicate with some third party over your internet before I pay you for it”.
But, yeah just giving people a tiny bit of internet works fine mostly. Even airplane WiFi with credit cards lets you access DNS before you buy…

2024-10-22 01:51:35 GMT

- reply

It’s just a head-of-line-blocking question, though…I imagine mostly you’re not downloading lots of CSS/JS/images, which is the big head-of-line issue HTTP clients have - they can render the page partially in response to each new item they get off the wire.
I assume you don’t, really, though? You presumably get events back from the server in time-order and populate the page down in time-order, so mostly one event stalling the next won’t make all that much difference in UX?

2024-10-21 12:08:29 GMT

- reply

I mean if you drop the TFO requirement it’s easy - just open many connections. But just fetching many resources isn’t sufficient to want QUIC - you have to be doing so immediately after opening the connection(s), the resources have to be non-trivial in size (think 10s of packets, so the text of a note generally doesn’t qualify) and have a need for not blocking one on another, which is generally not the case on a mobile app - server can send the first three things you need to paint the full window first and then more later.

2024-10-20 11:38:24 GMT

- reply

I think the difference is that with ecash the buyer choose who to trust and only trusts them. With your setup the buyer needs to trust the seller to some extent to use their infra to log into a custodial wallet. I’m not sure that’s a great idea.

2024-10-20 03:17:17 GMT

- reply

Errr avoid the multi-connection (and associated initial small window sizes)/head-of-line-blocking tradeoff.

2024-10-20 03:13:32 GMT

- reply

Note that QUIC is useful on the web for helping to and the multi-connection/head-of-line blocking problem. But if you aren’t fetching a bunch of resources from the same server across different streams where you can use each resource individually on its own this doesn’t apply (and it requires integration work to make it apply).

2024-10-20 03:01:40 GMT

- reply

TLS’ only issues aren’t just CAs being a mess, it’s also an anachronistic protocol that just isn’t how you’d design something today. 1.3 is better, sure, but it carries tons of legacy garbage and most clients still have fallbacks and logic for it.
I also dislike QUIC for being a lazy, poor version of TCP. Middleboxes suck sometimes but sometimes do useful things (eg on a plane TCP is terminated before it goes to the sat, improving latency and throughput compared to UDP things with retransmissions, middleboxes can use MSS clamping to avoid fragmentation, etc). QUIC largely failed to consider these things and just said “screw all middleboxes” (compare to eg tcpinc which got similar encryption properties without being lazy). QUIC exists to rebuild TCP in user-space cause kernels sometimes suck, but for those of us with an operating system newer than five years old that’s not a problem we have. Worse, sometimes your OS has specific useful features (eg MP-TCP) that you don’t want twenty apps to have to rewrite. FFS this is literally the point of having an OS! The only promise QUIC made that isn’t as trivial in TCP is FEC, but they gave up on it cause…I dunno why.

2024-10-20 02:52:51 GMT

- reply

Mmm, right, so doesn’t work noncustodially :/. Also sketchy security :(

2024-10-19 23:55:10 GMT

- reply

That doesn’t allow a payer’s lightning wallet to access the internet, though?

2024-10-19 23:54:30 GMT

- reply

Admittedly I wasn’t really thinking about web apps in the above design though. Nothing specific shouldn’t work except that the spec explicitly says wallets can’t open a callback URI that has a scheme of http(s). I was worried about it being a way for a payee to discover the payers IP, but I think maybe it doesn’t matter.

2024-10-19 23:52:20 GMT

- reply

The web client shouldn’t be fetching the invoice, it just passes the whole offer on to the wallet and asks it to pay. When the wallet completes it does a callback to the initiating app.

2024-10-19 22:27:24 GMT

- reply

I think it’s required. If we’re flipping it to have the nostr zapper broadcast the zap (which we should) you need to cryptographically tie the nostr zapper to the payment proof somehow.
I can see the argument for returning the key explicitly (it’s simple, the initiating app is the payer, kinda), but it feels pretty gross (two copies of a key always bad if you can only have one). Seems cleaner to just pass the message in the original URI?

2024-10-19 22:22:50 GMT

- reply

Better late than never. See the Proof of Payment section at https://github.com/bitcoin/bips/pull/1555/files

2024-10-19 22:13:44 GMT

- reply

No no, for offers. Imagine Nostr app wants to zap using BOLT 12. It does a system open for bitcoin:?lno=lnoffer&pop=proofcallback, but it ultimately needs the proof to include “Bob zapped with emoji🫠”. So either the proofcallback has to include the private key or that original URI has to include the string to sign.

2024-10-19 22:06:37 GMT

- reply

Filtering the Internet such that you can connect to your LSP but nothing else is…hard?

2024-10-19 21:39:10 GMT

- reply

Maybe with some fixed prefix though.

2024-10-19 21:38:54 GMT

- reply

I wonder if the initiating app in BIP 21-replacement should be able to specify that string? Probably…

2024-10-19 21:37:22 GMT

- reply

AFAIR QUIC has the same number of round trips as normal TLS if you set the TCP options right. Basically it shaves off RTs because it begins the TLS handshake in the SYN. You can do that with TCP, too, doubly so if you aren’t using a TLS library that sets socket options for you. The claim in your diagram that you need 0 full RTs to do QUIC setup is nonsense, that’s just if you’ve spoken to the server before and it has cached keys, but the 0 RTT TLS stuff isn’t being implemented in generic HTTP stacks because of replay issues.