From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 14 May 2026 12:33:06 -0700 Received: from mail-oa1-f62.google.com ([209.85.160.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wNbnt-00031H-IT for bitcoindev@gnusha.org; Thu, 14 May 2026 12:33:06 -0700 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-439bb670a3csf5062221fac.2 for ; Thu, 14 May 2026 12:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1778787179; x=1779391979; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=yQ3qqwWEjCgZh2jHoVnFYK9V6Oi13gVhBHiMdzmvP04=; b=Mo6ZcqpYgbE4t55Rgo5BljYxHA2obcx5oVBC15PwqLBLepGd1wAoD96qhcBKZGS/6e k8phjdI417tT1w2xkrkwWthKSwHP3Ki+cmQHkStsnP4Jz7xLC8dbcR2rhk5pVN9giJyz yxxkYwABo+11ytt6ssX/X7+2olEqVNHSCOT1FlQGgGZXOURGIBcvLf/4qcvQ7N7rEwW8 gGkX0uf+yzPcNs7LERM3UPHpTdslU2ANU81V5Smq2hAW8Z4ni2s4B9jF/4C5B6J/0gCA wCKEzkHE1SD3vD17knESsV9Ir1esgpyusIpTFob703gxN0B+Z5utPAX5k2sFJ9NoYfUR Yi1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778787179; x=1779391979; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=yQ3qqwWEjCgZh2jHoVnFYK9V6Oi13gVhBHiMdzmvP04=; b=D4QYvTD//57yBbMfh0cHDVfa1X3tVuJOlu7tMvmhLGoKPm38ZeT0TxAKd6ZqRFfJfY pPRg27B1Pm9ugFRri3Nn6/VIfifLmRlgPbr1zB/vRRaZvWHDcEwBoVmdB5JYhqG593sq lN4lFkjzVSpq169FQCD7ITGBJYIXLfF5xQlQl5Fh05bfQ74GBJ7Op5U6dpA4I8GB1+xg XurtLNGiCJ/qyiEMa8oJVKmrOVfykKjNP4g/Eb7KMqZ7Q8qrAVC4Ddm92Vaw07nJ7Z/Q iwgDlfGzP1HsksiG+8/PfPLgWJjK5LFM0CidXVO/wQc+s+uVEJZB/ZQdkjhx90Pt279p ElsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778787179; x=1779391979; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=yQ3qqwWEjCgZh2jHoVnFYK9V6Oi13gVhBHiMdzmvP04=; b=AYFvzecHgY2CmT3bmeGxBV4z30SQ/uvzScawEtdVV2Y240AOdmKXVfjwNahy/Prmxr 5TOeZn8113F659ILBT9ydxSXytttvPm10JPG4R18fHYfQDpKrMcOdzcEhrnE+9Q2B+Mu JxLSBWm3G22lNkY15bZEakqXcw2xa/fIpCVqVpbEWT3JtPWNvKeFFIBRyFnHgmBqlb4D ZJQRvzexTIiaSh6GDoN/DOxDLze1YGj2JQ4UvM0d3IVdHykzKmttcNQdjgtIllYiPxwd TD9QDjug557RxILYdKosgLvQHr+R5RsCtGCuv946vUoCHOTolmX/wjsQksJLNQqhIcFH oGJA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/dQ66a6YPZcd5OzbmCs8Kl9Drly4egcUwvx3ii2K64x50qDxu97nkO146yXih+jAcjlFpzz4elqU85@gnusha.org X-Gm-Message-State: AOJu0YzvO+STm4tgUrB6HWcNoCGAUha4UfeXYL1nk/Gl7F7/qjHUWWqe 3kySl/A241q4akxHcHBG5zyeq3liBGF1LySY4VzZHxxK4MDAVy7w6+eV X-Received: by 2002:a05:6820:16a6:b0:699:96b4:719c with SMTP id 006d021491bc7-69c9431b96cmr568533eaf.25.1778787178888; Thu, 14 May 2026 12:32:58 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOeQXOS1zB5q9RR6E+4gx6yEx9ecgoMJYCgAOij/pQ68A==" Received: by 2002:a05:6870:2405:b0:439:c5b3:2fc0 with SMTP id 586e51a60fabf-43a01f30b7dls660805fac.2.-pod-prod-02-us; Thu, 14 May 2026 12:32:53 -0700 (PDT) X-Received: by 2002:a05:6808:e65b:b0:479:ac7d:6d91 with SMTP id 5614622812f47-482e58d8c09mr397657b6e.39.1778787173109; Thu, 14 May 2026 12:32:53 -0700 (PDT) Received: by 2002:a05:690c:4507:b0:7b3:13f7:5f3a with SMTP id 00721157ae682-7c698ddb9c3ms7b3; Thu, 14 May 2026 12:09:05 -0700 (PDT) X-Received: by 2002:a05:690c:9988:b0:7ba:f2f1:86c0 with SMTP id 00721157ae682-7c95ac54f91mr7819867b3.12.1778785744381; Thu, 14 May 2026 12:09:04 -0700 (PDT) Date: Thu, 14 May 2026 12:09:03 -0700 (PDT) From: Ekrem BAL To: Bitcoin Development Mailing List Message-Id: <17f62129-3f3e-4624-ac12-2c3ede886735n@googlegroups.com> In-Reply-To: References: Subject: [bitcoindev] Re: Knowledge Gathering: SPV Proof Applications In the Wild and Proposed MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_305842_163616718.1778785743801" X-Original-Sender: mail.ekrembal@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_305842_163616718.1778785743801 Content-Type: multipart/alternative; boundary="----=_Part_305843_692361744.1778785743801" ------=_Part_305843_692361744.1778785743801 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=20 transaction inclusion proofs to accept peg-ins/deposits. See: The contract checks inclusion through Citrea's Bitcoin light client=20 contract. More details here: Second, in the Clementine Bridge proof, we use SPV proofs for verifying=20 operator payout transactions. If an operator is challenged, the operator=20 proves that there exists a payout transaction paying the withdrawal. See: On your question about commitment structures, I think being able to verify= =20 that a particular coin was not spent in a block might be helpful, as it=20 could make creating SNARK proofs for operator honesty easier in some bridge= =20 designs. Best, Ekrem BAL On Thursday, May 14, 2026 at 10:47:59=E2=80=AFAM UTC-4 jeremy wrote: > Dear Bitcoin Developers, > > SPV proofs are an important part of Bitcoin's Design, after all Satoshi= =20 > thought they were worth including in the whitepaper! > > As far as I'm aware, they have somewhat limited usage in the wild, mainly= =20 > in Electrum and in Layer 2 Bridges, but it is important that they work=20 > correctly. > > I'd like to gather a bit more detailed information on where and how SPV= =20 > proofs are currently used, as well as any other proposed uses of SPV proo= fs. > > In this Knowledge Gathering, I'd also like to glean a better understandin= g=20 > of what types of commitment structures might work "better" than others fo= r=20 > SPV -- e.g., ability to cheaply verify if a block pays a particular=20 > address, spends a particular coin, and the exclusion forms (does not pay = an=20 > address, does not spend a coin) etc, especially in the context of Layer 2= =20 > Bridging. > > Happy International Chihuahua Appreciation Day, > > Jeremy > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 17f62129-3f3e-4624-ac12-2c3ede886735n%40googlegroups.com. ------=_Part_305843_692361744.1778785743801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy,

For Citrea/Clementine, we currently use SPV-style pro= ofs in two main places.

First, on the Citrea side, the Bridge sy= stem contract uses Bitcoin transaction inclusion proofs to accept peg-ins/d= eposits. See:

<https://github.com/chainwayxyz/citrea/blob/487= daa67fc54feb789b618a0ca2be1cc2f09b198/crates/evm/src/evm/system_contracts/s= rc/Bridge.sol#L196>

The contract checks inclusion through Cit= rea's Bitcoin light client contract. More details here:

<http= s://docs.citrea.xyz/developer-documentation/system-contracts/bitcoin-light-= client>

Second, in the Clementine Bridge proof, we use SPV pr= oofs for verifying operator payout transactions. If an operator is challeng= ed, the operator proves that there exists a payout transaction paying the w= ithdrawal. See:

<https://github.com/chainwayxyz/clementine/bl= ob/b711e92ef2725e8b3cdaacc2683583f11b5aec28/circuits-lib/src/bridge_circuit= /spv.rs>

On your question about commitment structures, I thin= k being able to verify that a particular coin was not spent in a block migh= t be helpful, as it could make creating SNARK proofs for operator honesty e= asier in some bridge designs.

Best,
Ekrem BAL
On Thursday, May 14, 20= 26 at 10:47:59=E2=80=AFAM UTC-4 jeremy wrote:
Dear Bitcoin Developers,

S= PV 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 corr= ectly.

I'd like to gather a bit more detailed in= formation on where and how SPV proofs are currently used, as well as any ot= her 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, s= pends 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.<= /div>

Happy International Chihuahua Appreciation Day,

Jeremy

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/17f62129-3f3e-4624-ac12-2c3ede886735n%40googlegroups.com.
------=_Part_305843_692361744.1778785743801-- ------=_Part_305842_163616718.1778785743801--