Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C9886C0029 for ; Wed, 14 Jun 2023 20:14:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 1101360FBF for ; Wed, 14 Jun 2023 20:14:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1101360FBF Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=lnp-bp.org header.i=@lnp-bp.org header.a=rsa-sha256 header.s=protonmail2 header.b=iFO2SJuB X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wGqKUGE9TdI for ; Wed, 14 Jun 2023 20:14:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4F50C60F35 Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch [185.70.41.103]) by smtp3.osuosl.org (Postfix) with ESMTPS id 4F50C60F35 for ; Wed, 14 Jun 2023 20:14:44 +0000 (UTC) Date: Wed, 14 Jun 2023 20:14:26 +0000 Authentication-Results: mail-41103.protonmail.ch; dkim=pass (2048-bit key) header.d=lnp-bp.org header.i=@lnp-bp.org header.b="iFO2SJuB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lnp-bp.org; s=protonmail2; t=1686773671; x=1687032871; bh=PaMnVKsIRN6qi0MrU0RcxusEH26EHjGYh+/m2YzJCIg=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=iFO2SJuBjZb/z70MCmuvE6G+njDIwC2eGcZyV5EKKHofyy6Woroq/P9329LWw3Eng Gp5PZXXC4AJ2zbOA/fnVALo19L3WzVDh80GVs6O1+3tPCoLPjNpYPkqMUFl5DI81kQ 1FuSN1V7/6CCxT45xzmTE4CmioHssEd6acR88/VEVa8rtVNz8tlp6sKY6QBRPCE8cl WPBeF70XUjDa7RCNeNGZYqLxnH80gCmjIl+dgoQeeYLPoCWYjW1YRLh0GguUsinUrB mvENIlFXGJR60+3FMGjj9j4Djai49eW372aw7+E+6E9Ec+6lgr3Jt3P1fL4wrBk3p7 KMTu4FtH3KQ3A== To: Bitcoin Protocol Discussion , Peter Todd From: Dr Maxim Orlovsky Message-ID: In-Reply-To: References: Feedback-ID: 18134079:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 14 Jun 2023 20:19:33 +0000 Subject: Re: [bitcoin-dev] Scaling and anonymizing Bitcoin at layer 1 with client-side validation X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2023 20:14:47 -0000 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