path: root/3f/b3c65dbdaa6c074bb2acc26c44f238f8f9b2f9

Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9458EC0029
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jun 2023 18:47:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 5C0AB60E3E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jun 2023 18:47:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 5C0AB60E3E
Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm1 header.b=i/1S9pgO
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vL4aJDf-ex7u
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jun 2023 18:47:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F35F860E71
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29])
 by smtp3.osuosl.org (Postfix) with ESMTPS id F35F860E71
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  5 Jun 2023 18:47:07 +0000 (UTC)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id B42365C07B1;
 Mon,  5 Jun 2023 14:47:06 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Mon, 05 Jun 2023 14:47:06 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm1; t=1685990826; x=1686077226; bh=beUNR3ZaliF47
 9/l/Rk4dfMskdUM/EQabfL331Yb9M0=; b=i/1S9pgOLgLPth23ToYe4gE4mmA+q
 in+CJcNKQfrteu50LHtDiYFZxeXb62dwwVPBqDRAbuDJQTJuAEvxzxCTh+yNKQdn
 7nFKeOBJuYxCeOKPbq//IT9SnRcXHL3wPduV7qwQcpHVpkFpvZKlHcVIL8Obozce
 4G0fCjwnHar5OfixSgmsU8ErCqjQ5Yh50HyyAZH+0v6R/jfmm+U8i84XlgXLc19F
 qF40b03BD2+utwvjILooooQou6CGToaocDSIjLbhZW+NI3nztguBgxULyqst497/
 6AJrEu+iVtNsxK1HegDLENXZ16ozSCBaEt03z+DhWrJIMqrqqpHobscAg==
X-ME-Sender: <xms:qS1-ZNd0Cyk3dj_tvt12pLrda4yc74tnLrCvrnXD8JwDH9TWxPW3uA>
 <xme:qS1-ZLMFBDXgvM6ddA7kmZn4OoHaQ3MRkK2Q3z3fSWQc3LLvoN8HiJoDnzdZUpFMb
 m5_ssJ96xSMh1RGp3U>
X-ME-Received: <xmr:qS1-ZGiXOaK5tW1Y83a0I849dM5d18h8XWF10jKkaSbqkMzuclm1rNkT-Q>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelledgudefudcutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpeevieduieetieefvefhteeiudeuteeggeekgfejgeeikeeludettdfftedvtdek
 hfenucffohhmrghinhepiigvrhhoshihnhgtrdhorhhgpdhpvghtvghrthhouggurdhorh
 hgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgv
 thgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:qi1-ZG9TUNnd0oYT-5nXh1TcNxWEGyY1FpOevKUjPeqLOvxpytLKxA>
 <xmx:qi1-ZJsEwRpQysbtc9f_wqsf1mM-LMpOVYPTWeiyTIBGdgotWB-bcA>
 <xmx:qi1-ZFHUHPhSpvhdCjckwX2qmrqXtFsQfGxkyxaJv6PB1zThaFeIyQ>
 <xmx:qi1-ZBIT88ezl3IgJkhU_oiqtZsPK_fz4ATJ2t5u_5-Om8A5rXZ4EQ>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon,
 5 Jun 2023 14:47:05 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id 1442A5F81D; Mon,  5 Jun 2023 18:47:03 +0000 (UTC)
Date: Mon, 5 Jun 2023 18:47:03 +0000
From: Peter Todd <pete@petertodd.org>
To: Robin Linus <robin@zerosync.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZH4tp5U7F658M+hn@petertodd.org>
References: <C45891F8-2AE4-4D26-B98A-0E983935A83E@zerosync.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="P7y0cSQvWa0lKWHq"
Content-Disposition: inline
In-Reply-To: <C45891F8-2AE4-4D26-B98A-0E983935A83E@zerosync.org>
Subject: Re: [bitcoin-dev] ZeroSync: Introducing Validity Proofs to Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jun 2023 18:47:09 -0000


--P7y0cSQvWa0lKWHq
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 12, 2023 at 02:12:03PM +0200, Robin Linus via bitcoin-dev wrote:
> Hi all,
>=20
> Today we are publishing a summary of our research on "ZeroSync: Introduci=
ng Validity Proofs to Bitcoin".
>=20
>=20
> Here's the preface:
>=20
> We introduce ZeroSync, the first-ever proof system addressing Bitcoin=E2=
=80=99s scalability challenges with Succinct Non-Interactive Argument of Kn=
owledge (SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a =
compact proof of validity, enabling instant verification and unlocking vari=
ous innovative applications. We discuss our prototype implementation of a c=
hain state proof, utilizing the Cairo language, Utreexo, and recursive STAR=
Ks. Our work enables diverse applications, including quick bootstrapping of=
 full nodes, trustless light clients, enhanced Lightning Network privacy, a=
nd secure cross-chain bridges. Chain state proofs require no consensus chan=
ges, which is crucial as forks in Bitcoin are challenging to implement and =
achieve consensus for. Despite the existing bottleneck of prover performanc=
e, we present a range of optimization strategies and demonstrate the practi=
cality of generating a complete chain state proof.=20
> Finally, we introduce zkCoins, a client-side validation protocol combined=
 with zeroknowledge SNARKs, drastically improving privacy and throughput of=
 token transactions. In combination with future Bitcoin features, such as S=
implicity, zkCoins also enables private and more scalable BTC transactions.=
=20
> The groundbreaking compression capabilities of SNARKs initiated a paradig=
m shift in cryptocurrency design, and ZeroSync is pioneering their applicat=
ion to Bitcoin.
>=20
>=20
> You can find the full paper here: https://zerosync.org/zerosync.pdf <http=
s://zerosync.org/zerosync.pdf>
> Happy to receive any comments and answer any questions the bitcoin dev co=
mmunity may have about the paper!

Two serious issues with this proposal:

1) You're creating an alternative implementation of the Bitcoin protocol. T=
here
is a _long_ history of such implementations failing to implement an exact c=
opy
of the consensus rules, leading to potential forks. Obviously, if only used=
 by
otherwise lite clients, there is less of a risk associated with this. But t=
he
risk is there and will expand as this tech is used for more sophisticated
things.

2) If the tech advances to the point where proof-generation is fast enough =
to
happen in real time, Bitcoin miners adopting it along with and other wideps=
read
adoption it may cause Bitcoin to lose its decentralization. At the heart,
Bitcoin's consensus is a proof of publication scheme: miners are (weakly)
forced to publish blocks by the fact that users and other miners demand blo=
cks
to both validate their coins, and mine further. Without blocks themselves b=
eing
published on a timely basis, the censorship resistance of Bitcoin fails bec=
ause
only a subset of miners actually have the necessary block data to create new
blocks with transactions in them. There's also other scenarios where these
capabilities could be abused, eg with "illegal data" being published in the
chain.

Re: #2, the Bitcoin technical community would be smart to find ways to *def=
eat*
ZKP schemes, with the goal of making it technologically infeasible to use t=
hem
for recently created blocks (eg the last few days worth).

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--P7y0cSQvWa0lKWHq
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmR+LaQACgkQLly11TVR
LzcnBQ//R301vIatkpLiDu0OCUAr4vr/1OFHL+sWx2YWm8Lw+SCr5BvaTbOix+iB
JeXnWaDYTjPWxXVUhJIFp9cx35Gqe62UBlrRldVPSHMW/khcHZPHqHchDQ7TlCx8
npJbc4iYgky/i0Vft/HSiromP18Ts03bm6NAyEd13GlL0llNJzr7Id47N1d+q6UU
TqcPKpzXOwyuEiBSBU2fDEONcsTKB5e2g/i9ZWoqkI1yO3lexgD/IkwTaABqZM22
0wK6cFgys6i1tHrKyvTlBO3fFku7FhZ4I0yDTdBb031a3e37i+hERhCIFc+xU+gD
pLClikev5cAETVeCpsQoKw/lBJGEWWhjKyq53bCWpCtHojMfKAFqvNDJUDgQz3tr
sFy2FFNUzskhDr/L0am0DtqFvIFac3XrX928AUmzViUlWi0O10ZzjhmUPCU8cjHh
owqnKygIyH6ubBTFaK0muZ68c+g3yQriyVtP65+CAFLzMF1amLLCP2bMsJ+M8WzA
avp67iSR9o+4T4j6CT9HHfj1EL9+vCoz342tgeda1J16hb5hKd5uSStKRGJXwJt4
VZcb8rsfi0vIT3ekouP2Fhrbk1O8K4Dd8950HZ2F2nFBhA1/JUzBFA1MdvUkqZA8
RdV6RB1gVu0oqaHTApPHF+cV5nPWob8oaOvabtbXxABB/ukrjos=
=ztbC
-----END PGP SIGNATURE-----

--P7y0cSQvWa0lKWHq--