Hi Michael, Thank you for taking the time to share such detailed feedback and references. I appreciate the context on LTANS, SCITT WG, and the existing IEC/ISO work around time-stamping services. I’ll review those links more closely to better understand the prior art and fit.
My motivation with the REM Protocol is not to portray blockchain as “magical,” but rather to explore how existing constructs (DOIs, hashes, TXIDs) can be formally packaged and archived with long-term verifiability. I see blockchain timestamping as one component, alongside notaries and receipts, rather than a wholesale replacement for established trust models. Your point about CPU cycles and practical verification is well-taken. That’s why I’m experimenting with layered proofs (DOI + hash + TXID) to minimize reliance on any single ledger or entity. My aim is to complement, not duplicate, existing timestamping solutions, while leaving an open door for interoperability via COSE/CBOR formats. I’ll dig further into LTANS and SCITT, but your note helps me clarify the scope: REM may have a role in bridging scholarly/archival artifacts with trusted time-stamping models already in play. Thanks again for pointing me in the right direction. Any additional guidance on where discussions of archival permanence + receipts would be most welcome would be greatly appreciated. Thanks again, Lawrence Reilly On Mon, Sep 22, 2025, 1:30 PM Michael Richardson <[email protected]> wrote: > > lawrence reilly <[email protected]> wrote: > > Would you suggest an alternative working group or area within IETF > that > > might be a better fit for this draft? I’d like to make sure I’m > > engaging with the right forum for further discussion and refinement. > > I think you should find an organization who believes proof-of-work > blockchain > has some ethical purpose. > > Even if changed to a shared-ledger (like Hyperledger), time-stamp services > do not generally involve mutually suspicious entities with sufficient > interest to spend the cpu cycles to verify the ledger. I don't think > anyone > wouldr spend the cpu cycles to download gigabytes of data, and verify > a block chain in order to be sure some code-signature was time-stamped > correctly before applying the patch. > > So it reduces to an entity running the time-stamping service, which singly > rooted systems such as described 20 years ago at > https://datatracker.ietf.org/wg/ltans/documents/ > would apply. Such services exist today (I see Entrust, Sectigo, Adacom > with > a trivial search). IEC/ISO did some work more recently. > So, you want COSE/CBOR format for receipts, then I'd start from LTANS, > and you'll need at least two notaries to partipate. > Here at the IETF, the SCITT WG might be interested, but I seem to think > that > they already have a solution. > > I understand that many people think that blockchain is magical, without > cost, > and will "free" you from having to make busiess relationships. > I also want a unicorn. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
