diff options
| author | Peter Todd <pete@petertodd.org> | 2023-06-05 18:09:21 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-06-05 18:09:29 +0000 |
| commit | ff3fa6960c46ee05c0fd221dc59f16ca3c11a090 (patch) | |
| tree | d4fffc32b0f1b285a9008732a6f8658ca45949e0 | |
| parent | c2608ebc9337eceee604740239c1aaf60fdaed86 (diff) | |
| download | pi-bitcoindev-ff3fa6960c46ee05c0fd221dc59f16ca3c11a090.tar.gz pi-bitcoindev-ff3fa6960c46ee05c0fd221dc59f16ca3c11a090.zip | |
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
| -rw-r--r-- | 2f/6a43e0f419ec531a52499993b1b9010d16bf80 | 277 |
1 files changed, 277 insertions, 0 deletions
diff --git a/2f/6a43e0f419ec531a52499993b1b9010d16bf80 b/2f/6a43e0f419ec531a52499993b1b9010d16bf80 new file mode 100644 index 000000000..f9cd918c4 --- /dev/null +++ b/2f/6a43e0f419ec531a52499993b1b9010d16bf80 @@ -0,0 +1,277 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 94D3EC0029 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Jun 2023 18:09:29 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id D729C4059B + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Jun 2023 18:09:28 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D729C4059B +Authentication-Results: smtp2.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=vCOCPjCX +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 smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 66pzkE3HTCLy + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Jun 2023 18:09:27 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org BF07B4037E +Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com + [66.111.4.29]) + by smtp2.osuosl.org (Postfix) with ESMTPS id BF07B4037E + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 5 Jun 2023 18:09:26 +0000 (UTC) +Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) + by mailout.nyi.internal (Postfix) with ESMTP id B6CFB5C07E4; + Mon, 5 Jun 2023 14:09:24 -0400 (EDT) +Received: from mailfrontend1 ([10.202.2.162]) + by compute4.internal (MEProxy); Mon, 05 Jun 2023 14:09:24 -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=1685988564; x=1686074964; bh=UUsNtgSnhypzp + ZDkpZdv8P4mjD/8/K/hIVDjTa4+BI4=; b=vCOCPjCXktuKlN543i/pXuuqLGnJb + NqvKxQ5NQaTD1eWDNiSama4carTr+ixbD8LbHYPeUTq6qov8Aqv9kkOspEcl61jD + GIUPzDYtOH1uvLV7F5UTjPFUUyhiKJz9jqdGjQULaPwvZJwvh2Iv/XEthksJWqYq + CjjNfHZWNx9ltHf75tABPv00n2XjbmQUDFKoBDqEgP1dZF/pkce4ro0V84BLK04D + tHhGtTHe/xL8fQfQAHwBt45GZRmjgLEYnVcCn3KGIlRacrdZLnf7TpdEt4vgvjSs + 65nxamcAcU99KG2iMEvja3tOax6Nz09C1+T8NlYAhF8j+C3+8/s+ij4tw== +X-ME-Sender: <xms:1CR-ZPB6iwB4CoGw0dzmEoVhzIo7CQQzt1WM5JWXLnxoHoZ9YP_Yiw> + <xme:1CR-ZFgUDUlR46laEArXuGBd_wR6A6yuwc4pot6oxNXLGNtEuZAL5IjoaUL7Jap5I + 7pV9akKiTU04e0E-Ng> +X-ME-Received: <xmr:1CR-ZKkRWePo43X2VVQU-q7JADTSaxH0a2MiNacwiEmFTyiTe-yYpDIN4A> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelledguddvfecutefuodetggdotefrod + ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh + necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd + enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv + rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth + gvrhhnpeeklefffeefhfdugfeuvefffeethfevhfevudfhvdetteeggfevvdfhieetledu + keenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgne + cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgv + sehpvghtvghrthhouggurdhorhhg +X-ME-Proxy: <xmx:1CR-ZBzHee1ED9eA6cLikuPu8b9ZddlOkOKSKizx6FtaJHpRZDHzQg> + <xmx:1CR-ZESz0JfjwZ7Q5zH4I8hWEGE6n_Si8Sx03ug6pRjYmSnAtOsSyw> + <xmx:1CR-ZEYIguAKb_puxMxCt-eEgJqCkIeAApw59HYTcNck2Utodq5_yQ> + <xmx:1CR-ZKfwrEX3YidKMgU4GXfkMjOyU-QdvC4J2F7lYKYp_9cfxM8Fjg> +Feedback-ID: i525146e8:Fastmail +Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, + 5 Jun 2023 14:09:23 -0400 (EDT) +Received: by localhost (Postfix, from userid 1000) + id 701695F81D; Mon, 5 Jun 2023 18:09:21 +0000 (UTC) +Date: Mon, 5 Jun 2023 18:09:21 +0000 +From: Peter Todd <pete@petertodd.org> +To: Dr Maxim Orlovsky <orlovsky@lnp-bp.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <ZH4k0Zv6r2wgHqr5@petertodd.org> +References: <W-qyMFEGyTIpuZXvGiif_9Funkz7LLwtl6Iyv_yxxouiSwygBVOq5MM6CX4Pr2CCenCzginP4cn5csOar3gyYN20I6Izhr_mvOeCzbRYk2w=@lnp-bp.org> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="brZCBkCvk9o825Rl" +Content-Disposition: inline +In-Reply-To: <W-qyMFEGyTIpuZXvGiif_9Funkz7LLwtl6Iyv_yxxouiSwygBVOq5MM6CX4Pr2CCenCzginP4cn5csOar3gyYN20I6Izhr_mvOeCzbRYk2w=@lnp-bp.org> +Subject: Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with + client-side validation +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:09:29 -0000 + + +--brZCBkCvk9o825Rl +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Thu, Jun 01, 2023 at 05:21:39PM +0000, Dr Maxim Orlovsky via bitcoin-dev= + wrote: +> Dear community, +>=20 +> Some time ago we (LNP/BP Standards Association) announced the release of = +RGB smart contract system [1]. In the subsequent discussion, we have refere= +nced [2] that the introduction of client-side validation has the potential = +for upgrading Bitcoin layer 1 - blockchain, which has become an unnecessary= + limiting factor for the Bitcoin ecosystem, creating both scaling and priva= +cy problems. While client-side validation requires consensus protocol and s= +ome layer 1 (for the proof of publication), this layer can be implemented i= +n a more efficient way than the Bitcoin blockchain. +>=20 +> Today we are glad to present Prime: a proposal to upgrade Bitcoin protoco= +l with the new scalable (up to billions of tx per minute) and fully anonymo= +us (opaque) layer 1, moving most validation work into the client-side valid= +ation system. It leaves BTC (Bitcoin as money) and the rest of the Bitcoin = +ecosystem (including PoW) intact. It may be deployed without a softfork and= + miners upgrade, but can certainly benefit from it. It doesn't affect those= + users who are not willing to upgrade and doesn't require any consensus or = +majority for the initial deployment. It also makes Lightning Network and ot= +her layer 2 systems redundant. Finally, it will make things like BRC20, ins= +criptions, ordinals etc. impossible; all proper assets, NFTs etc. will be d= +one with RGB smart contracts, not forcing non-users to store, validate and = +use their network bandwidth for the unpaid third-party interests. +>=20 +> The white paper describing the proposal can be found here: +> https://github.com/LNP-BP/layer1/ + +IMO you should have posted the white paper itself to the mailing list rather +than just posting a link. The purpose of the mailing list is to invite comm= +ent +and critique: having the text right here best serves that purpose. To that = +end, +I'm including the parts I'm replying to directly as quotes below. To be +specific, the exact version I'm responding to is: + +https://github.com/LNP-BP/layer1/tree/cdd038fefadd9c3c74c691a72efe22d229cc4= +1af + +> # Design +> +> The proposed system (codenamed Prime) consists of four main components: +> +> Timestamping service, generating a sequence of compact (~100 bytes) +> headers, which periodicity can be 10 minutes or less (up to 10 seconds= +), +> improving finality properties; + +The section describing this timestamping service simply isn't detailed enou= +gh +to understand what the timestamping service is exactly. Also, I strongly +suspect you are misusing the term "timestamping" to refer to something enti= +rely +different. + +Remember that timestamping merely proves data existed in the past. Using th= +at +term to refer to something with stronger guarantees is an abuse of terminol= +ogy +and has caused endless confusion by convincing people that OpenTimestamps (= +and +similar schemes) can do things it simply can not. + +Similarly, I see you using the term "timechain" - stop that. Unless you are +genuinely talking about timestamping, "timechain" is an atrocious term. + +> Proofs: ephemeral public data produced and published by miners alongsi= +de +> headers. The proofs are not required to be stored by the network and a= +re +> parsed into individual proofs kept by the users of the protocol in the= +ir +> client-side-validated data storages (named stashes). + +The proofs section claims that "Each network user tracks all new PMTs". Thi= +s of +course does not scale, contradicting your scalability claims. To make this +scalable, you have to explain how to shard the consensus layer, eg as I have +done in: + +https://petertodd.org/2017/scalable-single-use-seal-asset-transfer + +as well as: + +https://petertodd.org/2014/tree-chains-preliminary-summary + +Secondly, even with a way for *users* to shard that data, you also need to = +find +a way for the creators of those merkle trees to *collaborate* together in t= +he +creation of them to call your solution scalable. If you don't, mining will = +be a +central point of failure. Again, this was exactly what I was trying to do w= +ith +tree-chains. + +Finally, you have a serious data availability problem. The nature of +proof-of-publication-based single-use-seals is that being unable to get acc= +ess +to the publication data - even for a *single* step means you are unable to +close the seal. You need to discuss this issue in detail, as I do in both +references above. + +> Single-use-seal protocol, providing protection from double-spending at= +tacks. + +Single-use-seals are a *concept*, a mathematical abstraction. You should be +clear about which specific type of single-use-seal you are actually proposi= +ng +here. If I am not mistaken, you are proposing a proof-of-publication-based +single-use-seal. + +> Smart contract protocol, operating with client-side-validated data and +> providing programmability and rich state. Each piece of business logic= + in +> the system, including mining fees, is defined as a separate smart +> contract. Individual contracts are sharded and their history is not li= +nked +> directly (in the future it may be linked with zero-knowledge proofs). A +> ready-to-go solution is to use RGB, however, other systems may be +> developed as well. + +Discussing this aspect at this moment in detail is putting the cart before = +the +horse. You need to nail down exactly how double-spend prevention works. Sma= +rt +contract stuff is just an implementation detail in comparison - it's just a +sophisticated type of public key crypto scheme. + +> # P2P Network + +Similarly, this whole section is putting the cart before the horse. The exa= +ct +details of the P2P network don't matter at this point. + + +To summarize, I strongly suggest that you (re)read these two papers of mine= + in +detail: + +https://petertodd.org/2017/scalable-single-use-seal-asset-transfer +https://petertodd.org/2014/tree-chains-preliminary-summary + +I believe what you are trying to do is very similar to these ideas. But you= +'re +missing important parts, some of which I've covered before. + +--=20 +https://petertodd.org 'peter'[:-1]@petertodd.org + +--brZCBkCvk9o825Rl +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmR+JM4ACgkQLly11TVR +LzfrShAAnVxOBNMNNMcEIb0tfGTtzMJsl2Yohhg3plU70MxWujkaUXjq961bwm2U +LK2FGqXQJNoD1Jy5U2BkW4SCHd3OLY48HweaIccQL5sQXS6BVxMjwWqCtr4Smjon +uA1w2aRqApKdfHyYKH/2WM786ztnHjXr0bM9U074t6GYlSlOqXY7yHwpnXGv5MU2 +vkILQ+A1QmI0wWnbGUnd2gnbcdVBtaLx3F45nrycRgnYVHmmQlBOWCZzvyMDvvOe +QKYFcayT6gvJvhHtzumonh21mlP6im7NSUw4yyYnktx5IjDMLlbJ+fr7KF/fjuDz +UDUYk8gVE8Lfj7uug/1g4uXSZxuhDdSb+wSkfuaUyQARepUBnJNCnO7vwiendYDU +lzfXVC9RP7I139sCMnvaoQONiLpinrZkAEvz0u2HNZxmnIdbXh7tv/r1B+uRdFkN +ANPQ5OR27vD5WaRgZwXV4RnRqBPAn0m9MGBmmVwDbs8jlshvEHcNiYg2TGaaNoKK +6pR1+ILYrhoC/4Z4mPJgs0qivYkIsfec1LjAbYTIEuI4fsL9wFGFaVh1JHPrsYlw +Bv7Wdczb4yv669f1FVxs13tvlPBciI8h4EdE5jO3G7MT8pPeHG/peh7fITXt10qo +hzq6s/20medgdXxigOMuabNUs9Fz7NYgoDdCQlGTL8Hzvtvi7Rc= +=xfei +-----END PGP SIGNATURE----- + +--brZCBkCvk9o825Rl-- + |