From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 02 May 2026 14:26:14 -0700 Received: from mail-oo1-f63.google.com ([209.85.161.63]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1wJHqn-0001IU-AY for bitcoindev@gnusha.org; Sat, 02 May 2026 14:26:13 -0700 Received: by mail-oo1-f63.google.com with SMTP id 006d021491bc7-6947f168159sf6981313eaf.2 for ; Sat, 02 May 2026 14:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20251104; t=1777757167; x=1778361967; 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=fbQsBb2TacXi+U215fvd8oWBmV9Q3XRjdHlyyqcp+vo=; b=qTF92roETjkg+wTwKJO/sthkLCXYD+awoMx+SclV08/WA4IlUNWn/qPDt8oiLtJvZE cWG2JWE7oZeba1gTF5A/2qo8s+TXDXLUMr6KA8YYr0S+vmsNfDkUxnrlNmrKJ2cc6y9H 70b85bKhiNv5enW/eR2RiCcP8gHVwnzQXu4Bsr288/bXGKRcdO991VBi4pZuW/pYzZHB aYFflMO6yOCo24A8RQf0GptIln1V1iXRX5Dc1p8gWdQAKYDazadLj9N+yqsUQZKY0k3A SanRpcsOCS/6LVzOqivRUuKh/Cjj9T2xkeeq6XE9m+IGPxK46gRJpp5WILRyed2l3iK3 SoDg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777757167; x=1778361967; 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=fbQsBb2TacXi+U215fvd8oWBmV9Q3XRjdHlyyqcp+vo=; b=oY5n4sRzEy7lBRuOQiLJ1BdhgYuLO2k1dUK8iFHbCmi+HquUkJs/Uaowc/YkwFc/1i bsiXcQPFX9p1/Ih6YEWKf0Akk9QWUTjLF5KVXPL0Lf8MfIl/dIDviC3ueKwToecCpBbj xN4KfMxTFfp/+0B9ciHZxpR2sL7RrbANeFNlfFWBrT/iEujJKne/hBRZ5I22JFQxERCf qrFdGGytHHE6YPjPtYXkGoGuEJvsdIdyPUP2R8jqhB8GWO4gQ7YrPGOkig1TNgVBfjwb 25UQdjv5sZZDRfzKn6IdQczo0DaulCjUBWG7+OaRtH0giINdlc8BPFYCwR3YevntWp5T rQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777757167; x=1778361967; 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=fbQsBb2TacXi+U215fvd8oWBmV9Q3XRjdHlyyqcp+vo=; b=tBU1yvCpjmccP+iAH3crrhn4ultk2F5Gp2as046SixO9AqHZ+uLq70WsufxCXH9nFT kPBOXtWzYPQeu80dPpKv8i13BL9Gp/J873UIi16fB7ewm2+gh49PzUth6DZ6dwaLtdxb XlZNqf4RIE5BMG+W0GBaIsouEHOjn760PpMruPGEeHWUrJ3VSVQuPmqn0M+gPZRIy3W3 8RAY1hiuGexVbAipst+YXZCjgh5X8T47oPpXbE8IwLeAXk+sQLsKx+XPDcQRY3232qTZ U3vkGpdf+gytloc81SLgRS3GS00AXIVko2k+QPZIekUjSm7BOIbohrtRzSjnaoe9rAkS 9pVA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AFNElJ9ZmN38ZSzkbh6Q/5c0A3NCXhBq0wwusgIVzh6JI2FLTJpGSoMzVqT4lu5d3tV6DzNUmC10QV3Uvz/Q@gnusha.org X-Gm-Message-State: AOJu0YxYpejy2d3wuihwVUMvpdjYEBlHKJ4cbVdrRx/PtJLtqebZuJFx TMXCCKIUGtTRcXkCfBMVHBNaQ+FFODwwk4qY9eD5b/mnuu3qwM77nELt X-Received: by 2002:a05:6820:807:b0:68b:990a:8eb3 with SMTP id 006d021491bc7-69697c40800mr2140468eaf.34.1777757166985; Sat, 02 May 2026 14:26:06 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h="AUV6zMMv97svz+/+01u0Xxs4ldFnzJZa33Wg/NYl2mIA5+MlNA==" Received: by 2002:a05:6871:3607:b0:42f:d2f7:3841 with SMTP id 586e51a60fabf-4342f16df6els1728139fac.0.-pod-prod-04-us; Sat, 02 May 2026 14:25:42 -0700 (PDT) X-Received: by 2002:a05:6808:4f27:b0:467:2509:c20a with SMTP id 5614622812f47-47c89314c89mr2339550b6e.47.1777757142234; Sat, 02 May 2026 14:25:42 -0700 (PDT) Received: by 2002:a05:690c:578f:b0:79a:c9dc:1f8d with SMTP id 00721157ae682-7bd7670b083ms7b3; Sat, 2 May 2026 14:24:27 -0700 (PDT) X-Received: by 2002:a05:690c:c4e8:b0:7ba:f056:9e06 with SMTP id 00721157ae682-7bd7700205bmr47259037b3.21.1777757067177; Sat, 02 May 2026 14:24:27 -0700 (PDT) Date: Sat, 2 May 2026 14:24:26 -0700 (PDT) From: "Nuh.dev" To: Bitcoin Development Mailing List Message-Id: <85d0e4fb-26d5-44be-8c1b-461607b2fc28n@googlegroups.com> In-Reply-To: <4cd9d2bd-28f8-47a5-95f5-a7c9ae222835n@googlegroups.com> References: <1283ada3-6231-4e18-b8a3-056a8f142babn@googlegroups.com> <69c7bb7f-5bf5-40f1-a2fd-a985ec88ddd7n@googlegroups.com> <4cd9d2bd-28f8-47a5-95f5-a7c9ae222835n@googlegroups.com> Subject: [bitcoindev] Re: Fly Client Proposal MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_404608_925198234.1777757066533" X-Original-Sender: Ar.Nazeh@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_404608_925198234.1777757066533 Content-Type: multipart/alternative; boundary="----=_Part_404609_68523469.1777757066533" ------=_Part_404609_68523469.1777757066533 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, STARK proofs are post quantum secure, as they don't require much more= =20 than polynomials and hash functions, and they don't have trust assumptions= =20 like SNARKs, which is why they are called scalable Transparent arguments of= =20 knowledge. STARKs are not too difficult to vaguely understand, and in fact they aren't= =20 too different from FlyClient, both start from an interactive proof, then=20 use Fiat-Shamir heuristic too convert it into a non-interactive proof, the= =20 major difference is that FlyClient does that over a specific function (sum= =20 of Work), whereas STARK needs to prove arbitrary functions, usually a CPU= =20 instruction set. Finally, there will most likely not be any future soft forks, not even=20 string concatenation in Script, so we are lucky this one doesn't need=20 consensus change.=20 On Saturday, 2 May 2026 at 23:07:22 UTC+3 Zac Mitton wrote: > It makes sense that a STARK proof can do similar, however the 2 benefits= =20 > to this would be that (1) This doesnt require (any) more strict assumptio= ns=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 w= e=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 = is=20 >>> buried under several blocks of proof of work, believing that an attacke= r is=20 >>> unlikely to do all that work just to fool a light client (especially wh= en=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, howev= er=20 >>> many there are), only a constant number of block headers, and it's a pr= etty=20 >>> small total number. That property seems to make fly clients more effici= ent=20 >>> than standard light clients. >>> >>> On Wednesday, April 29, 2026 at 5:03:36=E2=80=AFPM UTC-4 Zac Mitton wro= te: >>> >>>> 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/= 85d0e4fb-26d5-44be-8c1b-461607b2fc28n%40googlegroups.com. ------=_Part_404609_68523469.1777757066533 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, STARK proofs are post quantum secure, as they don't require much more = than polynomials and hash functions, and they don't have trust assumptions = like SNARKs, which is why they are called scalable Transparent arguments of= knowledge.

STARKs are not too difficult to vaguely understand, = and in fact they aren't too different from FlyClient, both start from an in= teractive proof, then use=C2=A0Fiat-Shamir heuristic too convert it into a = non-interactive proof, the major difference is that FlyClient does that ove= r a specific function (sum of Work), whereas STARK needs to prove arbitrary= functions, usually a CPU instruction set.

Finally, there will m= ost likely not be any future soft forks, not even string concatenation in S= cript, so we are lucky this one doesn't need consensus change.=C2=A0
<= br />
On S= aturday, 2 May 2026 at 23:07:22 UTC+3 Zac Mitton wrote:
It makes sense that a STARK proo= f can do similar, however the 2 benefits to this would be that (1) This doe= snt require (any) more strict assumptions which I'm assuming STARKS do,= and (2) just the sheer simplicity of its design. Sorry to bring up a touch= y topic but is the STARK version quantum safe, for instance? The flyclient = version requires no new cryptographic assumptions beyond the "honest m= ining majority" used currently.

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

On Friday, May 1, 2026 at 5:03:47=E2=80=AFAM UTC-4= Nuh.dev wrote:
FlyCli= ent is very useful compared to SPV client, especially for blockchains with = much more headers per day than Bitcoin. But 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 for a soft fork, before Bitcoin = ossifies forever, is 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 assumptio= ns as a standard light client: the light client trusts the merkle root once= it is buried under several blocks of proof of work, believing that an atta= cker is unlikely to do all that work just to fool a light client (especiall= y 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 do= wnload a variable number of block headers (namely, all of them, however man= y there are), only a constant number of block headers, and it's a prett= y small total number. That property seems to make fly clients more efficien= t than standard light clients.

On Wednesday, April 29, 2026 at 5:03:36=E2= =80=AFPM UTC-4 Zac Mitton wrote:
Hi, Ive been looking into FlyClient first described here. I don't see any BIPs, or previous discussion in th= is forum about it either.

On bitcoin It could allow a li= ght-client to verify the entire work of the heaviest chain with a single ~1= 00KB proof.

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

What do you guy's thin= k?

--
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/85d0e4fb-26d5-44be-8c1b-461607b2fc28n%40googlegroups.com.
------=_Part_404609_68523469.1777757066533-- ------=_Part_404608_925198234.1777757066533--