Date: Wed, 14 Jun 2023 20:14:26 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Peter Todd <pete@petertodd.org>
From: Dr Maxim Orlovsky <orlovsky@lnp-bp.org>
Message-ID: <JNQbiVJqZED3JoewXguJDlyB-2j15z-t6UQT9Fz1MyeRuReASMHqgtuX-VeM6s6aN3SMvloNpThPqhO-UBUK9HcyRFAvabU3_YdSlzfhFgc=@lnp-bp.org>
In-Reply-To: <ZH4k0Zv6r2wgHqr5@petertodd.org>
References: <W-qyMFEGyTIpuZXvGiif_9Funkz7LLwtl6Iyv_yxxouiSwygBVOq5MM6CX4Pr2CCenCzginP4cn5csOar3gyYN20I6Izhr_mvOeCzbRYk2w=@lnp-bp.org>
 <ZH4k0Zv6r2wgHqr5@petertodd.org>
Feedback-ID: 18134079:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with
	client-side validation
Precedence: list

Hi Peter,

Thank you for your comments. My replies are below:

> The section describing this timestamping service simply isn't detailed en=
ough
> to understand what the timestamping service is exactly. Also, I strongly
> suspect you are misusing the term "timestamping" to refer to something en=
tirely
> 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 termin=
ology
> 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 pri=
or
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=20
(single-use-seals closings).

The stronger guarantees are absent on the level of the header-producing min=
ers
("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 tha=
t
part of the system.


> Similarly, I see you using the term "timechain" - stop that. Unless you a=
re
> 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 ter=
m=20
"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". T=
his of
> course does not scale, contradicting your scalability claims. To make thi=
s
> scalable, you have to explain how to shard the consensus layer, eg as I h=
ave
> done in:
>=20
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
>=20
> as well as:
>=20
> https://petertodd.org/2014/tree-chains-preliminary-summary

This does scale since the consensus layer includes only headers of the fixe=
d
size (~200 bytes), which doesn't need sharding. All other data are client-s=
ide
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=20
PMT, but (1) they are ephemeral, (2) they are not validated, (3) their know=
ledge
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 t=
he
> creation of them to call your solution scalable. If you don't, mining wil=
l 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 Bitcoi=
n
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 a=
ccess
> 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 abs=
tracted
from the main proposal (like smart contracts and P2P) and I see several way=
s of
solving it - all these proposals should be evaluated separately from the ma=
in
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=E2=80=
=99t released=20
  some or all of the data from a previous PMT
- the miner can appeal and demonstrate that data in the following (few) hea=
ders
  by including them in the next header(s)
This should be enhanced with fees cryptoeconomics (the miner should lose fe=
es=20
if not providing the data).

In other words, if a miner does not release a tree - or releases it partial=
ly -
anybody can witness that fact by including unreleased paths to the next hea=
der.=20
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=
=20
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 propo=
sing
> here. If I am not mistaken, you are proposing a proof-of-publication-base=
d
> 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 befor=
e 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 e=
xact
> 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 i=
n this
    proposal, since multiple alternative systems may co-exist and compete i=
n a=20
    market-driven way."


> To summarize, I strongly suggest that you (re)read these two papers of mi=
ne in
> detail:
>=20
> https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
> https://petertodd.org/2014/tree-chains-preliminary-summary
>=20
> I believe what you are trying to do is very similar to these ideas. But y=
ou'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