Feedback-ID: i525146e8:Fastmail
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
Precedence: list


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