395 / 736CORALLO

Matt Corallo

Developer known as TheBlueMatt

When a new Bitcoin block appears, the other computers need to hear about it. Matt Corallo worked on delivering those data with less bandwidth and delay. He also helped build software that developers use to create Lightning applications.

Matt Corallo, known as TheBlueMatt, is a Bitcoin developer associated with Compact Block Relay, the FIBRE relay network and rust-lightning. A practical question connects this work: how can networks and applications run better without mistaking speed for assurance that everything is correct?

On GitHub, Matt Corallo uses TheBlueMatt. His profile notes that many repositories have moved to git.bitcoin.ninja. A repository holds source code and its change history, so an empty older location does not necessarily mean a project was abandoned. To establish who contributed what, follow that history, the proposals and their authors. Corallo’s work offers a path from more efficient block transmission to tools for Lightning. [1]

Computers validating Bitcoin continuously exchange unconfirmed transactions. By the time a block arrives, they may already know much of its content. Compact Block Relay takes advantage of this. BIP 152, the public technical specification, names Corallo as author and thanks Gregory Maxwell for the initial idea, design work and testing. Its primary aim is to save bandwidth. Delivery can also become faster, but the rules determining a block’s validity do not change. [2]

Imagine a shared list of documents: you have most already and just need to know which belong in the new package. BIP 152 similarly uses short transaction identifiers and the mempool, a local store of unconfirmed transactions. The receiver requests missing data with getblocktxn. Identifiers can collide, meaning different transactions share the same short label. Saving bandwidth therefore does not remove the need to obtain the actual data and check that the right block was reconstructed. [2]

Under specified conditions, BIP 152 allows a compact announcement before the sender has fully checked every transaction. This is not permission to relay anything: the header, its connection to the validated chain, proof of work and commitment to the included transactions must be checked. After reconstruction, the block is processed normally. The receiver still checks that existing funds are spent according to the rules. “The block arrived” and “the block is valid” are different statements. [2]

The internet sends data in small pieces called packets. If one is lost, waiting for retransmission adds delay. On 7 July 2016, Corallo described FIBRE, combining compact blocks with UDP, a transport without automatic retransmission of lost packets, and FEC, coding for recovering missing pieces. Extra data let the receiver reconstruct content without another request. The trade-off is sending more data; it is not a promise of flawless transmission under every condition. [3]

FIBRE can forward individual packets before checking them. That saves time, but requires strong internal trust among its nodes. It is not an invitation for arbitrary unchecked connections. Public code lets others establish a network, but an operator can still choose peers for their particular network. The FAQ says w0xlt and Justin of Localhost Research took over maintenance in 2025, advised by Corallo and Maxwell. Other people thus continue the project’s history. [4]

Another strand of Corallo’s work concerns Lightning, a network for payments through channels on top of Bitcoin. The manifest, or package description, for lightning in rust-lightning names Matt Corallo as author. Written in Rust, the library supplies core Lightning functions while letting an application choose its wallet, blockchain interaction, storage and networking. That attribution does not mean one person wrote every later change, or that the library alone is a finished wallet. [5]

LDK integrates into an application as an SDK, a toolkit for developers. They must connect storage and other required components. A payment’s result need not arrive when it is initiated: LDK reports success or failure later through an event the application handles. Starting the operation does not confirm success. For the person holding the wallet, the practical requirement is simple: the screen must distinguish a payment in progress from one that has completed. [6]

For the clearest picture, read this entry together with Gregory Maxwell, Luke Dashjr, Satoshi Nakamoto. The reverse links also lead from Stratum V2, Gregory Maxwell, Luke Dashjr.

DOC · 001GitHub — Matt CoralloDocumentation DOC · 002BIP 152 — Compact Block RelayDocumentation DOC · 003Matt Corallo — The Future of The Bitcoin Relay NetworksDocumentation DOC · 004FIBRE — FAQDocumentation DOC · 005rust-lightning — package manifestDocumentation DOC · 006LDK — ArchitectureDocumentation
Revised: Source-first · No investment advice