path: root/2f/6a43e0f419ec531a52499993b1b9010d16bf80

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--