From: Dr Maxim Orlovsky <orlovsky@lnp-bp•org>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Peter Todd <pete@petertodd•org>
Subject: Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation
Date: Wed, 14 Jun 2023 20:14:26 +0000 [thread overview]
Message-ID: <JNQbiVJqZED3JoewXguJDlyB-2j15z-t6UQT9Fz1MyeRuReASMHqgtuX-VeM6s6aN3SMvloNpThPqhO-UBUK9HcyRFAvabU3_YdSlzfhFgc=@lnp-bp.org> (raw)
In-Reply-To: <ZH4k0Zv6r2wgHqr5@petertodd.org>
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
next prev parent reply other threads:[~2023-06-14 20:14 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
2023-06-14 20:14 ` Dr Maxim Orlovsky [this message]
[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='JNQbiVJqZED3JoewXguJDlyB-2j15z-t6UQT9Fz1MyeRuReASMHqgtuX-VeM6s6aN3SMvloNpThPqhO-UBUK9HcyRFAvabU3_YdSlzfhFgc=@lnp-bp.org' \
--to=orlovsky@lnp-bp$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(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