On Wednesday, June 7, 2017 at 9:11:22 PM UTC+2, Peter Todd wrote: > > On Mon, Jun 05, 2017 at 02:21:34PM -0700, Axel wrote: > > > > > > On Monday, June 5, 2017 at 10:52:25 PM UTC+2, Chris Laprise wrote: > > > > > > Can OpenTimestamps be easily reconfigured to use a blockchain system > > > other than Bitcoin? > > > > > > Chris > > > > > > > From OpenTimestamps.org: "OpenTimestamps aims to be a standard format > for > > blockchain timestamping. The format is flexible enough to be vendor and > > blockchain independent" > > Yup, OpenTimestamps proofs can contain attestations from multiple > different > notaries simultaneously. Multiple attestations is also backwards > compatible, in > that a Bitcoin-only verifier will simply ignore attestations using other > mechanisms that it doesn't know about. > > Currently the only code that's been written in addition to Bitcoin is > preliminary Ethereum support, however that was only added at the > insistence of > a banking client; I personally don't think it's particularly valuable to > have. > Ethereum doesn't provide a very different guarantee than Bitcoin does, and > in > practice it's suffered a lot of consensus issues; what exactly Ethereum is > isn't well-defined. The Ethereum chain also in practice timestamps the > Bitcoin > chain anyway, as there's a few Ethereum contracts that follow the Bitcoin > chain > for various reasons, and timestamp proofs can be extracted if needed from > those > contracts. >
> More interesting will be when we add support to OpenTimestamps for > notaries > with very different trust models, namely trusted timestamping schemes like > Roughtime. Such schemes will add both diversity, and can add much higher > precision timestamps that a decentralized system never could. > Here's an idea for you: Make that a centralized process! * Set up a process that regularly collects proofs of freshness from many diverse sources, including news sources, all blockchains you can think of, and other kinds of notaries like selected, known roughtime servers. * Make "history" documents that include all these proofs of freshness, as well as root hashes from the OTS calendar servers. * Make proofs of existence of the history documents with many diverse methods, including publishing to all blockchains you can think of, and other kinds of notaries. * Store these history documents, or historical artifacts :-), together with their rather large .ots proofs in a repository that people are encouraged to mirror, and find ways to include it in several save-for-the-future initiatives, including archive.org. * Standardize a format for history documents, and add an expression in the OTS standard to refer to such a document, e.g. HistoryDocument(hash, optional suggestion of how to retrieve). Using a hash there ensures that no consensus is necessary. * Naturally, the hash of a history document should be included in the next history document, in effect creating a blockchain (except no consensus is necessary) for time proofs that interlink with so many beautiful things. This would make the world a better place in many ways, including these: * .ots proof files would become more secure since they would in effect refer to more things than a user otherwise would care to reference. * .ots proof files would remain small despite the added security if the .ots generator defaults to include the latest HistoryDocument, and at most one other source (that stamps the same calendar root hash). A second thing would be included only in order to protect against HistoryDocument data unavailability. * .ots proof files would become more accurate, since the hash can be published to pretty much the first block of any blockchain that happens to form after the stamping. * For the same reasons, proofs of freshness would also become more secure and more accurate. * Proofs of freshness would actually become smaller than they are now. No need to include many things, just the latest HistoryDocument hash and at most one other thing e.g. a bitcoin block an hour old. * You said something about not giving people incentive to mess with Bitcoin block time. This would create a powerful deterrent. There is no way an adversary could dream of influencing all those notaries concurrently, and if they mess enough with one blockchain, anyone will be able to actually prove it, rather than just notice. * Since anyone can see, use, and tie information to/from this meta-chain, it could benefit other projects, e.g. it could strengthen the roughtime system as well. I think this process can be optimized somewhat: * A history document only needs to include hashes from chains that has published a new block since the last history document. * Similarly, if a new history document is created before a certain blockchain has confirmed the publication of the last one, an attempt should be made to override the transaction so as to include the latter history document instead of the former and save on transaction fees. Depending on the blockchain in question I assume this could be done by double-spending with a slightly higher fee. * These two optimizations would provide higher granularity without creating excessive data. > > > IIUC, Stampery is a free of charge service that produces OTS proofs tied > to > > both Bitcoin and Ethereum concurrently. See > > https://api.stampery.com/#stampery-api-usage-downloading-ots-receipts > > I'm not sure whether or not Stampery's OTS proofs actually include the > Ethereum attestations. > > In any case, there's a system of 100% free calendar servers, currently > operated > by myself and another OpenTimestamps team member, that also allow you to > produce OTS proofs. In addition, this system allows you to produce OTS > proofs > *instantly*, without waiting for confirmation in the Bitcoin blockchain. > These > calendars run on open-source software, and all data associated with them > is > freely available for anyone to download and mirror. I'd strongly suggest > OTS > users use those calendars. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/12b97188-7a8b-4364-b405-668ef76cf7da%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
