Taproot Assets uses SPV proofs in the proof file format for an asset. Each asset starts at a gensis point, then proves that the rules of the overlay layer were followed each each new state transition. Each state transition includes an SPV proof of the transaction that commits to the state transition.
An upcoming revamp of the LN gossip protocol also has a cut out to optionally include an SPV proof with a channel announcement message. This makes the protocol more light client friendly, as otherwise a light client would need to fetch tens of thousands of blocks to verify that a channel actually exists. It isn't specified today, but a future extension to the `channel_update` message could include a merkle proof of a _spent_ funding output to provide a verifiable gossip layer proof that a channel has been closed. Today setting a disabled bit in the channel update is used in place, but that's overloaded with other signals (eg: the peer is offline). > does not spend a coin If the Merkle Tree were actually a Sparse Merkle Tree, then we'd have a succinct way proving that a given transaction wasn't in a block. If such a commitment were added over the set of spent outputs, then you could also succinctly prove that a transaction wasn't spent in a block. Such an STXO commitment would also be useful for SwiftSync as then peers are able to verify the integrity of the undo data. -- Laolu On Thu, May 14, 2026 at 7:47 AM jeremy <[email protected]> wrote: > Dear Bitcoin Developers, > > SPV proofs are an important part of Bitcoin's Design, after all Satoshi > thought they were worth including in the whitepaper! > > As far as I'm aware, they have somewhat limited usage in the wild, mainly > in Electrum and in Layer 2 Bridges, but it is important that they work > correctly. > > I'd like to gather a bit more detailed information on where and how SPV > proofs are currently used, as well as any other proposed uses of SPV proofs. > > In this Knowledge Gathering, I'd also like to glean a better understanding > of what types of commitment structures might work "better" than others for > SPV -- e.g., ability to cheaply verify if a block pays a particular > address, spends a particular coin, and the exclusion forms (does not pay an > address, does not spend a coin) etc, especially in the context of Layer 2 > Bridging. > > Happy International Chihuahua Appreciation Day, > > Jeremy > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/a3049fd5-e001-4d3a-9c99-d5629f47dfd8n%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/a3049fd5-e001-4d3a-9c99-d5629f47dfd8n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs8%3DkrFLHO1vjNitSAMLJTP7Ss%2B5auSXFf-OHEs7J1nV8Q%40mail.gmail.com.
