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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
