Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
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
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
On Thu, Jun 01, 2023 at 05:21:39PM +, 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
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
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 < 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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
> 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
[bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
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___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
