"Pest" v. 0xFD.

This is a continuation of "Pest" v. 0xFE.

There is a pretty-printed mirror of this page.

There is now a prototype! (Thank you, thimbronion!)

14 Dec 2021: And there is now a second prototype! (Thank you, jonsykkel!)

There is a working draft of v. 0xFC. (Note: it may change without warning!)

The document (very much a work in progress!) is available as a vtree. You will need:

Add the above vpatches and seals to your V-set, and press to pest_spec_FD.kv.vpatch.

To "compile" the document to HTML, run make (this requires the "markdown2" utility.)

Please submit any proposed changes to this spec in vpatch form.

The full text is reproduced below, and any reader able to spare the time for a careful reading is invited to comment!
This version is obsolete! Please read v. 0xFC !

Click here for a printer-friendly version of this text.

This entry was written by Stanislav , posted on Friday November 19 2021 , filed under Bitcoin, Cold Air, Computation, Cryptography, Friends, Hot Air, Idea, Mathematics, ModestProposal, NonLoper, P2P, Pest, Progress, SerpentCipher, ShouldersGiants, SoftwareSucks . Bookmark the permalink . Post a comment below or leave a trackback: Trackback URL.

4 Responses to “"Pest" v. 0xFD.”

  • bonechewer says:

    I am enjoying reading the pest draft spec.

    You have probably already considered this, but it occurs to me that a possible risk of having GetData successively request older and older messages until it reaches the last seen SelfChain or NetChain, is that if there is high latency, the oldest messages get more and more likely to have expired from a peer's ring buffer before they are requested.

    I suppose one alternative would be a command like GetData that contained two hashes, ChainFirst and ChainLast. Receipt of such a command would cause the receiving station to search the chain of messages from a given peer backwards from ChainLast until it either found ChainFirst or encountered the beginning of its ring buffer, then send the messages found to the requesting station. If the requesting station knows it is getting the oldest stuff first, it should need to do less buffering.

    If you have already considered and rejected this, and there is something I am missing, I shall be glad of the education.

    • Stanislav says:

      Dear bonechewer,

      Notionally a station will retain older messages (i.e. ones which have exited the in-memory ring buffer) on disk, indexed by hash; but I have not explicitly mandated this in the spec; hence the "best effort" verbiage.

      Re: ChainFirst and ChainLast -- I'd rather not have Bitcoin-style "one request, potentially over9000 replies" mechanisms. One packet -- one response, is IMHO the Right Thing. And that way the station issuing the request always knows what the expected hash of the incoming message is, and knows to check the hash of incoming messages prior to the timestamp if and only if it is expecting a GetData response.

      The other thing is, if the requested missing messages are broadcasts, it makes sense to request them stepwise from the entire WOT, rather than from only one peer.


      • bonechewer says:

        Ah, okay, if old messages can still be retrieved after aging out of the ring buffer, then that changes things entirely. Might be worth alluding to that possibility explicitly in the spec since somehow unimaginative me failed to consider that possibility.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre lang="" line="" escaped="" highlight="">

MANDATORY: Please prove that you are human:

6 xor 13 = ?

What is the serial baud rate of the FG device ?

Answer the riddle correctly before clicking "Submit", or comment will NOT appear! Not in moderation queue, NOWHERE!