From: Peter Todd <pete@petertodd•org>
To: Dr Maxim Orlovsky <orlovsky@lnp-bp•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
Date: Mon, 5 Jun 2023 18:09:21 +0000 [thread overview]
Message-ID: <ZH4k0Zv6r2wgHqr5@petertodd.org> (raw)
In-Reply-To: <W-qyMFEGyTIpuZXvGiif_9Funkz7LLwtl6Iyv_yxxouiSwygBVOq5MM6CX4Pr2CCenCzginP4cn5csOar3gyYN20I6Izhr_mvOeCzbRYk2w=@lnp-bp.org>
[-- Attachment #1: Type: text/plain, Size: 6149 bytes --]
On Thu, Jun 01, 2023 at 05:21:39PM +0000, Dr Maxim Orlovsky via bitcoin-dev wrote:
> Dear community,
>
> Some time ago we (LNP/BP Standards Association) announced the release of RGB smart contract system [1]. In the subsequent discussion, we have referenced [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 privacy problems. While client-side validation requires consensus protocol and some layer 1 (for the proof of publication), this layer can be implemented in a more efficient way than the Bitcoin blockchain.
>
> Today we are glad to present Prime: a proposal to upgrade Bitcoin protocol with the new scalable (up to billions of tx per minute) and fully anonymous (opaque) layer 1, moving most validation work into the client-side validation 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 other layer 2 systems redundant. Finally, it will make things like BRC20, inscriptions, ordinals etc. impossible; all proper assets, NFTs etc. will be done with RGB smart contracts, not forcing non-users to store, validate and use their network bandwidth for the unpaid third-party interests.
>
> 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 comment
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/cdd038fefadd9c3c74c691a72efe22d229cc41af
> # 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 enough
to understand what the timestamping service is exactly. Also, I strongly
suspect you are misusing the term "timestamping" to refer to something entirely
different.
Remember that timestamping merely proves data existed in the past. Using that
term to refer to something with stronger guarantees is an abuse of terminology
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 alongside
> headers. The proofs are not required to be stored by the network and are
> parsed into individual proofs kept by the users of the protocol in their
> client-side-validated data storages (named stashes).
The proofs section claims that "Each network user tracks all new PMTs". This 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 the
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 with
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 access
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 attacks.
Single-use-seals are a *concept*, a mathematical abstraction. You should be
clear about which specific type of single-use-seal you are actually proposing
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 linked
> 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. Smart
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 exact
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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-06-05 18:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 17:21 Dr Maxim Orlovsky
2023-06-05 18:09 ` Peter Todd [this message]
2023-06-14 20:14 ` Dr Maxim Orlovsky
[not found] <mailman.110973.1685749706.956.bitcoin-dev@lists.linuxfoundation.org>
2023-06-03 13:30 ` John Tromp
2023-06-03 17:17 ` Dr Maxim Orlovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZH4k0Zv6r2wgHqr5@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=orlovsky@lnp-bp$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox