Re: Scaling and anonymizing Bitcoin at layer 1 with client-side validation

Re: Scaling and anonymizing Bitcoin at layer 1 with client-side validation
2023-06-05 18:09 ` Peter Todd
  
From: Dr Maxim Orlovsky @ 2023-06-01 17:21 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 2885 bytes --]

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/

As LNP/BP Standards Association we are setting a working group which will be focused on formal specification and reference implementation of this new layer - and will gladly accept everybody who wishes to cooperate on this topic. We also plan educational and workshop activities to make community understand the underlying technology better and take educated decision on its adoption.

We believe that this infrastructural effort must not be managed by a for-profit company - or a commercial group with its interests, and the only proper way of funding such an effort should be through non-profit donations. We do plan a fundraising campaign, so everyone interested in driving the Bitcoin evolution forward please contact us at ukolova [at] lnp-bp.org. For-profit organizations can also become members of the Association [3] and get to the committees defining the shape of the future Bitcoin technologies.

Dr Maxim Orlovsky
on behalf of LNP/BP Standards Association
https://lnp-bp.org/
GitHub: github.com/LNP-BP
Twitter: @lnp_bp
Nostr: npub13mhg7ksq9efna8ullmc5cufa53yuy06k73q4u7v425s8tgpdr5msk5mnym

[1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021554.html
[2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-April/021577.html
[3]: https://www.lnp-bp.org/membership

[-- Attachment #2: Type: text/html, Size: 5748 bytes --]

 permalink raw reply	[|nested]


  2023-06-03 17:17   ` Dr Maxim Orlovsky
  
From: John Tromp @ 2023-06-03 13:30 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

> The white paper describing the proposal can be found here:
> https://github.com/LNP-BP/layer1/

Some questions about the Bitcoin PoW anchoring:

What if a miner spends the current miner single-use-seal while
creating a commitment, but makes the PMT only partially available, or
entirely unavailable ?

How do other miners reach consensus on whether a protocol reset is
required? It seems impossible to agree on something like PMT
availability (much like mempool contents).


 permalink raw reply	[|nested]
2023-06-03 13:30 ` [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation John Tromp

  
From: Dr Maxim Orlovsky @ 2023-06-03 17:17 UTC (permalink / raw)
  To: john.tromp, bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]

Hi John,

Thank you for the question. We have discussed this case in the paper, second paragraph of the “Bitcoin PoW Anchoring” Section:

> If a party spends current miner single-use-seal without creating a commitment - or committing to a header without sufficient PoW, such closing is considered invalid; in this case, any party is allowed to create a special bitcoin transaction providing publically-identifiableOP_RETURNinformation ("announcement") about a new miner single-use-seal (protocol reset); only the firstOP_RETURNannouncement which is closed with a proper procedure is considered valid under the consensus rules.

Kind regards,
Maxim Orlovsky

On Sat, Jun 3, 2023 at 4:30 PM, John Tromp via bitcoin-dev <[bitcoin-dev@lists•linuxfoundation.org](mailto:On Sat, Jun 3, 2023 at 4:30 PM, John Tromp via bitcoin-dev <<a href=)> wrote:

>> The white paper describing the proposal can be found here:
>> https://github.com/LNP-BP/layer1/
>
> Some questions about the Bitcoin PoW anchoring:
>
> What if a miner spends the current miner single-use-seal while
> creating a commitment, but makes the PMT only partially available, or
> entirely unavailable ?
>
> How do other miners reach consensus on whether a protocol reset is
> required? It seems impossible to agree on something like PMT
> availability (much like mempool contents).
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3108 bytes --]

 permalink raw reply	[|nested]
2023-06-01 17:21 Dr Maxim Orlovsky

  2023-06-14 20:14   ` Dr Maxim Orlovsky
  
From: Peter Todd @ 2023-06-05 18:09 UTC (permalink / raw)
  To: Dr Maxim Orlovsky, Bitcoin Protocol Discussion

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

 permalink raw reply	[|nested]
2023-06-05 18:09 ` Peter Todd

  
From: Dr Maxim Orlovsky @ 2023-06-14 20:14 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion, Peter Todd

Hi Peter,

Thank you for your comments. My replies are below:

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

I agree the section should be extended.

I use the term timestamping to specify that some set of facts was known prior
to some moment time in the past. This is done via headers committing to the
previous header AND to the Merkle root of the commitments to the facts 
(single-use-seals closings).

The stronger guarantees are absent on the level of the header-producing miners
("timestamping layer"). They appear on the level of PMT and client-side-
validated data, which is not timestamping (and not named that way).
Giacomo Zucco in private conversation suggested using "timesealing" for that
part of the system.


> Similarly, I see you using the term "timechain" - stop that. Unless you are
> genuinely talking about timestamping, "timechain" is an atrocious term.

I am afraid you are talking to the wrong person: the only way I use the term 
"timechain" is as a reference to the way Satoshi Nakamoto named it in the
Bitcoin whitepaper. That is a historical fact that can't be changed.

None of the components of the system I described is named "timechain".


> 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

This does scale since the consensus layer includes only headers of the fixed
size (~200 bytes), which doesn't need sharding. All other data are client-side
and shared by the network users such that each user tracks and keeps only
the data related to his part of the state history. The miners producing
headers and PMTs act independently; the only part which may be large is 
PMT, but (1) they are ephemeral, (2) they are not validated, (3) their knowledge
is not needed to produce the next block. This all is explained in the paper.


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

The system doesn't require miner collaboration to create Merkle trees.
A miner who does the creation is elected as a leader via consensus protocol
(for instance using PoW) and acts independently - the same way as in Bitcoin
blockchain.


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

I agree that this is the main problem, as well as the only problem which is not
addressed in the paper. I think the data availability problem should be abstracted
from the main proposal (like smart contracts and P2P) and I see several ways of
solving it - all these proposals should be evaluated separately from the main
idea (how to do proof-of-publication single-use-seals without blockchain).

The most promising way for my opinion is to use the following scenario:
- in the next (few) header(s) anyone may witness that a miner hasn’t released 
  some or all of the data from a previous PMT
- the miner can appeal and demonstrate that data in the following (few) headers
  by including them in the next header(s)
This should be enhanced with fees cryptoeconomics (the miner should lose fees 
if not providing the data).

In other words, if a miner does not release a tree - or releases it partially -
anybody can witness that fact by including unreleased paths to the next header. 
Then the miner will be penalized for the fees. If this witnessing was false,
the miner has an option to include these paths claimed to be unknown in the 
next headers(s) - get all his fees.


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

Yes, it is proof-of-publication-based single-use-seal

>    Smart contract protocol, operating with client-side-validated data and
<...>
> Discussing this aspect at this moment in detail is putting the cart before the
> horse.

That is exactly why I do not discuss it in detail in the paper, covering it
in just one short paragraph. :)


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

That is exactly what is said in the paper:

    "We deliberately do not address the question of P2P network structure in this
    proposal, since multiple alternative systems may co-exist and compete in a 
    market-driven way."


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

I will work on extending explanations in the paper in the places where the exact
mechanism of how the problems you have mentioned are addressed.


Kind regards,
Maxim Orlovsky




 permalink raw reply	[|nested]