* [bitcoindev] Knowledge Gathering: SPV Proof Applications In the Wild and Proposed
@ 2026-05-14 14:46 jeremy
2026-05-14 19:09 ` [bitcoindev] " Ekrem BAL
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: jeremy @ 2026-05-14 14:46 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1281 bytes --]
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/a3049fd5-e001-4d3a-9c99-d5629f47dfd8n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 1686 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* [bitcoindev] Re: Knowledge Gathering: SPV Proof Applications In the Wild and Proposed 2026-05-14 14:46 [bitcoindev] Knowledge Gathering: SPV Proof Applications In the Wild and Proposed jeremy @ 2026-05-14 19:09 ` Ekrem BAL 2026-05-23 2:39 ` [bitcoindev] " Olaoluwa Osuntokun [not found] ` <9001a42f-b497-41c1-895d-3ec902f2413cn@googlegroups.com> 2 siblings, 0 replies; 5+ messages in thread From: Ekrem BAL @ 2026-05-14 19:09 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 2598 bytes --] Hi Jeremy, For Citrea/Clementine, we currently use SPV-style proofs in two main places. First, on the Citrea side, the Bridge system contract uses Bitcoin transaction inclusion proofs to accept peg-ins/deposits. See: <https://github.com/chainwayxyz/citrea/blob/487daa67fc54feb789b618a0ca2be1cc2f09b198/crates/evm/src/evm/system_contracts/src/Bridge.sol#L196> The contract checks inclusion through Citrea's Bitcoin light client contract. More details here: <https://docs.citrea.xyz/developer-documentation/system-contracts/bitcoin-light-client> Second, in the Clementine Bridge proof, we use SPV proofs for verifying operator payout transactions. If an operator is challenged, the operator proves that there exists a payout transaction paying the withdrawal. See: <https://github.com/chainwayxyz/clementine/blob/b711e92ef2725e8b3cdaacc2683583f11b5aec28/circuits-lib/src/bridge_circuit/spv.rs> On your question about commitment structures, I think being able to verify that a particular coin was not spent in a block might be helpful, as it could make creating SNARK proofs for operator honesty easier in some bridge designs. Best, Ekrem BAL On Thursday, May 14, 2026 at 10:47:59 AM UTC-4 jeremy 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/17f62129-3f3e-4624-ac12-2c3ede886735n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 3234 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Knowledge Gathering: SPV Proof Applications In the Wild and Proposed 2026-05-14 14:46 [bitcoindev] Knowledge Gathering: SPV Proof Applications In the Wild and Proposed jeremy 2026-05-14 19:09 ` [bitcoindev] " Ekrem BAL @ 2026-05-23 2:39 ` Olaoluwa Osuntokun [not found] ` <9001a42f-b497-41c1-895d-3ec902f2413cn@googlegroups.com> 2 siblings, 0 replies; 5+ messages in thread From: Olaoluwa Osuntokun @ 2026-05-23 2:39 UTC (permalink / raw) To: jeremy; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 3420 bytes --] 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 <jeremy.l.rubin@gmail.com> 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 bitcoindev+unsubscribe@googlegroups.com. > 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs8%3DkrFLHO1vjNitSAMLJTP7Ss%2B5auSXFf-OHEs7J1nV8Q%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4296 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <9001a42f-b497-41c1-895d-3ec902f2413cn@googlegroups.com>]
* Re: [bitcoindev] Re: Knowledge Gathering: SPV Proof Applications In the Wild and Proposed [not found] ` <9001a42f-b497-41c1-895d-3ec902f2413cn@googlegroups.com> @ 2026-06-05 3:52 ` Sergio Demian Lerner 2026-09-04 15:18 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 1 reply; 5+ messages in thread From: Sergio Demian Lerner @ 2026-06-05 3:52 UTC (permalink / raw) To: jeremy; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 4061 bytes --] Rootstock uses SPV proofs to power its Bitcoin SPV node that runs in consensus inside the Bridge smart contract. The bridge uses SPV proofs to accept peg-ins and peg-outs change, after 100 Bitcoin confirmations. The system is decentralized: any user can submit Bitcoin headers to build the Bridge view of Bitcoin. The Bridge maintains the canonical chain and all potential forks. All forks can be extended with block headers having the right PoW. The codebase is based on Bitcoinj. The system has been running since 2018 without interruptions. The SPV proof verifier is protected from Merkle node type confusions (64-byte txs). Sergio On Mon, May 25, 2026 at 3:37 PM jeremy <jeremy.l.rubin@gmail.com> wrote: > I received the below as reply-one and am forwarding with permission: > > ------ > > > Hi Jeremy, > > This is a presentation I did in 2016 on SPV as "Satoshi's scaling > solution". > > There are no new types of proofs, just old fashioned proofs-of-coin and > proofs-of-spend. My approach was to try to envision what the whole network > would need to look like. > > A common objection to SPV was that full nodes would be "overloaded", so I > introduced spv-serving light nodes with different services. > > A key idea (which is not stated explicitly in the slides) is for a node to > advertise interest in a set of tx hash stems for which it would provide > proof services, and for which it wanted to be relayed transactions. The > set would contain stems of varying lengths that could be as short as 1 hex > character or as long as some max. > > Wallets would do this same registration to cause transactions to be routed > to themselves. Nearly all of those stems would be randomly introduced for > privacy. > > Bloom filters are mentioned as part of a transaction repeater service but > that was for compatibility with existing SPV wallets of the time. The main > idea was to achieve scaling and privacy by the registration scheme. > > Hope it's useful in some way! > > > Cheers, > Tom Harding > > > On Thursday, May 14, 2026 at 10:47:59 AM UTC-4 jeremy 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 bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/9001a42f-b497-41c1-895d-3ec902f2413cn%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/9001a42f-b497-41c1-895d-3ec902f2413cn%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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKzdR-pSKPXjBnWJZMASDRZve5Y1ekeTo7eG_f%3DWV-vVn1xZPQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 6107 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [bitcoindev] Re: Knowledge Gathering: SPV Proof Applications In the Wild and Proposed 2026-06-05 3:52 ` [bitcoindev] " Sergio Demian Lerner @ 2026-09-04 15:18 ` 'conduition' via Bitcoin Development Mailing List 0 siblings, 0 replies; 5+ messages in thread From: 'conduition' via Bitcoin Development Mailing List @ 2026-09-04 15:18 UTC (permalink / raw) To: Sergio Demian Lerner; +Cc: jeremy, Bitcoin Development Mailing List [-- Attachment #1.1.1: Type: text/plain, Size: 4959 bytes --] Hey Jeremy, Just wanted to include DropKick here. DropKick is a PQ rescue protocol that uses SPV-like proofs of block inclusion to prove that an honest user knew a secret before a quantum attacker did, i.e. a commit/reveal protocol. Details here: https://conduition.io/bitcoin/dropkick/ and here: https://groups.google.com/g/bitcoindev/c/6SqWPfBf-p0 regards, conduition On Thursday, June 4th, 2026 at 10:26 PM, Sergio Demian Lerner <sergio.d.lerner@gmail.com> wrote: > Rootstock uses SPV proofs to power its Bitcoin SPV node that runs in consensus inside the Bridge smart contract. The bridge uses SPV proofs to accept peg-ins and peg-outs change, after 100 Bitcoin confirmations.The system is decentralized: any user can submit Bitcoin headers to build the Bridge view of Bitcoin. The Bridge maintains the canonical chain and all potential forks. All forks can be extended with block headers having the right PoW. > The codebase is based on Bitcoinj. > The system has been running since 2018 without interruptions. > The SPV proof verifier is protected from Merkle node type confusions (64-byte txs). > > Sergio > > On Mon, May 25, 2026 at 3:37 PM jeremy <jeremy.l.rubin@gmail.com> wrote: > > > I received the below as reply-one and am forwarding with permission: > > > > ------ > > > > > > > > Hi Jeremy, > > > > This is a presentation I did in 2016 on SPV as "Satoshi's scaling solution". > > > > There are no new types of proofs, just old fashioned proofs-of-coin and proofs-of-spend. My approach was to try to envision what the whole network would need to look like. > > > > A common objection to SPV was that full nodes would be "overloaded", so I introduced spv-serving light nodes with different services. > > > > A key idea (which is not stated explicitly in the slides) is for a node to advertise interest in a set of tx hash stems for which it would provide proof services, and for which it wanted to be relayed transactions. The set would contain stems of varying lengths that could be as short as 1 hex character or as long as some max. > > > > Wallets would do this same registration to cause transactions to be routed to themselves. Nearly all of those stems would be randomly introduced for privacy. > > > > Bloom filters are mentioned as part of a transaction repeater service but that was for compatibility with existing SPV wallets of the time. The main idea was to achieve scaling and privacy by the registration scheme. > > > > Hope it's useful in some way! > > > > > > Cheers, > > Tom Harding > > > > > > > > On Thursday, May 14, 2026 at 10:47:59 AM UTC-4 jeremy 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 bitcoindev+unsubscribe@googlegroups.com. > > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/9001a42f-b497-41c1-895d-3ec902f2413cn%40googlegroups.com. > > -- > 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 bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAKzdR-pSKPXjBnWJZMASDRZve5Y1ekeTo7eG_f%3DWV-vVn1xZPQ%40mail.gmail.com. -- 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/6Zyn9YqvVDHYG5jKAif7_3P_V4elPH3YMm9qZ2Yz6Tt45dfqnTuAVzBpGo7WjRYBaaexd9YUSGzc9mvzspsUAb_HezPe8Kjye-ZR57f-qMU%3D%40proton.me. [-- Attachment #1.1.2.1: Type: text/html, Size: 8594 bytes --] [-- Attachment #1.2: publickey - conduition@proton.me - 0x474891AD.asc --] [-- Type: application/pgp-keys, Size: 649 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 343 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2026-09-04 15:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-05-14 14:46 [bitcoindev] Knowledge Gathering: SPV Proof Applications In the Wild and Proposed jeremy
2026-05-14 19:09 ` [bitcoindev] " Ekrem BAL
2026-05-23 2:39 ` [bitcoindev] " Olaoluwa Osuntokun
[not found] ` <9001a42f-b497-41c1-895d-3ec902f2413cn@googlegroups.com>
2026-06-05 3:52 ` [bitcoindev] " Sergio Demian Lerner
2026-09-04 15:18 ` 'conduition' via Bitcoin Development Mailing List
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox