From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 02 May 2026 13:07:29 -0700 Received: from mail-oa1-f64.google.com ([209.85.160.64]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wJGca-0000ST-Ej for bitcoindev@gnusha.org; Sat, 02 May 2026 13:07:28 -0700 Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-43013bffd49sf8849441fac.0 for ; Sat, 02 May 2026 13:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777752442; x=1778357242; 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=XJEv3ctFqRSji+77TgeH/oUwToPhWegIl3BROPZ0x+I=; b=Rg8c7mPD4o4JkGPgXvpt/n26wsZut0fOiXPQPG6guqzv9/2UFskKybwA/wDZkWE8+x jn08L09powwpIoezqxR23uXQgNNQChtA4sdI3AeF1CJejkLIliDyCpEQNAp1XiYQX1DW WlSL/zl5WmdaporWxrxkZ8dNQRinarfOtyFVeewsg1DHVNWaQenmjBgVakcE4UG42whH D3E6ZpL64ULmaJZrzUS2wPsIMYYtT8G8VWuG4ZNsVj7v/jqUq9a8BUWNWTQ3DvhS0wgF PMwT1rXyYXzi0qTd8d8yESfyC50S8dUNRqAgvvL4WjsM6ydYB4tK0vqmq0yNeqFU2l97 17yw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777752442; x=1778357242; 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=XJEv3ctFqRSji+77TgeH/oUwToPhWegIl3BROPZ0x+I=; b=cwwGxlak3Bg16eoCZNFDF+54xttuL5BnYwOmKmkvyKF2iZik1/pjpp+Ek2MtkQILnv UZBfpqZH/3X0+cCbiWX2zWbg35FpGTUYSUW4Krra1qBvD85tdpr4PRcr9a3Z8SGSXnmo 2IxAeSngFdiadXyLm62QhGHCB5weQQ+Ep1gi5gYHmOYp8KagOMC3HLXtL0Kgz37uACPH 0TEW9FD/Nd8X7YK8Q5cGkqeecme+ii8iD3eVAdngCdspRXYIRcmsLQSHlNqCN98grmm/ 5LecRedPtY0BdLL+x3Yr/KFqOdbL1FcDXQhbFn5D5L+mybyz5gPnLxEwbYSy41aNS332 rxQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777752442; x=1778357242; 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=XJEv3ctFqRSji+77TgeH/oUwToPhWegIl3BROPZ0x+I=; b=cSzcO1XYoIdxPqvYRrhp5/zPdaBNnn3PwLoISOU+WV4mKaKkEmYz7/LR4i4Fhgh1yH WW8/WI6hurRo6T7uyCRkmtwrYGb1/Pb0bVbfNiXbjiApVzfAH9Ppi4erngMlyHoKI7/I l9plu1ll4FFrWkD4h7JC2pS/6xxnS+47/W7jWeXkj8ED1djl8lJej63uj9Dtg1Fhq2BT UELwAeZ6KQzv+36rUjFU6k+lHCPfyLrR8XlDG8zRgZyKRAtzxpv92ehgquygPAxlUC4y DtnTYqGj2A97ISzHDraQb2Veh9RD4MTtK6bi9Wjscxv5+/FrnQlzIVAV+51niaBnkbDt rUdQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ/hDad52ki3hXQ8RVk23Pjei3/XNmmm78slv5IHMfQwI2xZfvaLmO7rehE6ISmcmILzx2c4HNZXCSKR@gnusha.org X-Gm-Message-State: AOJu0YwFvcpq1sezvPuUb7K6minCGvWbEKp0cG6m29CO1daporNjAo3C Jx7uccWveuPZBG82y/ftVRnRnQzi7X1rjSE9usQtdWxgnd/qEA4Ill8P X-Received: by 2002:a05:6870:391e:b0:41b:e8a0:8d8a with SMTP id 586e51a60fabf-43475fbf1e2mr1865572fac.4.1777752442099; Sat, 02 May 2026 13:07:22 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMOTa7//sh750HPUI6k6E0DzjwViDYsVSoTnwEOEqCkmtg==" Received: by 2002:a05:6870:e98a:b0:430:b76:607f with SMTP id 586e51a60fabf-4340b4f5b7bls1088264fac.2.-pod-prod-00-us-canary; Sat, 02 May 2026 13:07:17 -0700 (PDT) X-Received: by 2002:a05:6808:6f91:b0:47a:499:b616 with SMTP id 5614622812f47-47c89294b62mr1821453b6e.16.1777752437140; Sat, 02 May 2026 13:07:17 -0700 (PDT) Received: by 2002:a05:690c:578f:b0:79a:c9dc:1f8d with SMTP id 00721157ae682-7bd7670b083ms7b3; Sat, 2 May 2026 12:23:43 -0700 (PDT) X-Received: by 2002:a05:690c:d96:b0:79b:e346:9813 with SMTP id 00721157ae682-7bd55ed791fmr93848157b3.10.1777749822397; Sat, 02 May 2026 12:23:42 -0700 (PDT) Date: Sat, 2 May 2026 12:23:41 -0700 (PDT) From: Zac Mitton To: Bitcoin Development Mailing List Message-Id: <4cd9d2bd-28f8-47a5-95f5-a7c9ae222835n@googlegroups.com> In-Reply-To: <69c7bb7f-5bf5-40f1-a2fd-a985ec88ddd7n@googlegroups.com> References: <1283ada3-6231-4e18-b8a3-056a8f142babn@googlegroups.com> <69c7bb7f-5bf5-40f1-a2fd-a985ec88ddd7n@googlegroups.com> Subject: [bitcoindev] Re: Fly Client Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_389160_910536643.1777749821925" X-Original-Sender: zacmitton22@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_389160_910536643.1777749821925 Content-Type: multipart/alternative; boundary="----=_Part_389161_580961211.1777749821925" ------=_Part_389161_580961211.1777749821925 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It makes sense that a STARK proof can do similar, however the 2 benefits to= =20 this would be that (1) This doesnt require (any) more strict assumptions=20 which I'm assuming STARKS do, and (2) just the sheer simplicity of its=20 design. Sorry to bring up a touchy topic but is the STARK version quantum= =20 safe, for instance? The flyclient version requires no new cryptographic=20 assumptions beyond the "honest mining majority" used currently. Admittedly my dumb brain understands it better. I assume it would get=20 grouped into some larger softfork rollout... On Friday, May 1, 2026 at 5:03:47=E2=80=AFAM UTC-4 Nuh.dev wrote: > FlyClient is very useful compared to SPV client, especially for=20 > blockchains with much more headers per day than Bitcoin. But fortunately,= =20 > this is one of the few soft forks that we don't actually need, because we= =20 > can substitute with a STARK proof as you can see here;=20 > https://github.com/starkware-bitcoin/raito ... so any energy for=20 > gathering consensus for a soft fork, before Bitcoin ossifies forever, is= =20 > better spent elsewhere. > > On Thursday, 30 April 2026 at 21:55:05 UTC+3 Super Testnet wrote: > >> Seems pretty cool. It looks like it has similar trust assumptions as a= =20 >> standard light client: the light client trusts the merkle root once it i= s=20 >> buried under several blocks of proof of work, believing that an attacker= is=20 >> unlikely to do all that work just to fool a light client (especially whe= n=20 >> they could have been actually mining bitcoin with all that hashrate). A= =20 >> nice property is that, to get started, a fly client does not have to=20 >> download a variable number of block headers (namely, all of them, howeve= r=20 >> many there are), only a constant number of block headers, and it's a pre= tty=20 >> small total number. That property seems to make fly clients more efficie= nt=20 >> than standard light clients. >> >> On Wednesday, April 29, 2026 at 5:03:36=E2=80=AFPM UTC-4 Zac Mitton wrot= e: >> >>> Hi, Ive been looking into FlyClient first described here=20 >>> . I don't see = any=20 >>> BIPs, or previous discussion in this forum about it either. >>> >>> On bitcoin It could allow a light-client to verify the entire work of= =20 >>> the heaviest chain with a single ~100KB proof. >>> >>> It can theoretically be done as a soft-fork by injecting a single hash= =20 >>> into the coinbase tx (similar to how segwit is committed to).=20 >>> >>> What do you guy's think? >>> >> --=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/= 4cd9d2bd-28f8-47a5-95f5-a7c9ae222835n%40googlegroups.com. ------=_Part_389161_580961211.1777749821925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It makes sense that a STARK proof can do similar, however the 2 benefits to= this would be that (1) This doesnt require (any) more strict assumptions w= hich I'm assuming STARKS do, and (2) just the sheer simplicity of its desig= n. Sorry to bring up a touchy topic but is the STARK version quantum safe, = for instance? The flyclient version requires no new cryptographic assumptio= ns beyond the "honest mining majority" used currently.

Admittedly my dumb brain understands it better. I assume it would get grou= ped into some larger softfork rollout...

On Friday, May 1, 2026 at = 5:03:47=E2=80=AFAM UTC-4 Nuh.dev wrote:
FlyClient is very useful compared to SPV client,= especially for blockchains with much more headers per day than Bitcoin. Bu= t fortunately, this is one of the few soft forks that we don't actually= need, because we can substitute with a STARK proof as you can see here; https://github.= com/starkware-bitcoin/raito ... so any energy for gathering consensus f= or a soft fork, before Bitcoin ossifies forever, is better spent elsewhere.=

O= n Thursday, 30 April 2026 at 21:55:05 UTC+3 Super Testnet wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1p= x solid rgb(204,204,204);padding-left:1ex">Seems pretty cool. It looks like= it has similar trust assumptions as a standard light client: the light cli= ent trusts the merkle root once it is buried under several blocks of proof = of work, believing that an attacker is unlikely to do all that work just to= fool a light client (especially when they could have been actually mining = bitcoin with all that hashrate). A nice property is that, to get started, a= fly client does not have to download a variable number of block headers (n= amely, all of them, however many there are), only a constant number of bloc= k headers, and it's a pretty small total number. That property seems to= make fly clients more efficient than standard light clients.

On Wednesday, A= pril 29, 2026 at 5:03:36=E2=80=AFPM UTC-4 Zac Mitton wrote:
Hi, Ive been looking into FlyClient f= irst described here. I don't see any BIPs, or pre= vious discussion in this forum about it either.

On bitco= in It could allow a light-client to verify the entire work of the heaviest = chain with a single ~100KB proof.

It can theoretical= ly be done as a soft-fork by injecting a single hash into the coinbase tx (= similar to how segwit is committed to).=C2=A0

What= do you guy's think?
<= /blockquote>

--
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/4cd9d2bd-28f8-47a5-95f5-a7c9ae222835n%40googlegroups.com.
------=_Part_389161_580961211.1777749821925-- ------=_Part_389160_910536643.1777749821925--