it's 5:30a the following day and i'm having trouble moving my legs. i'm outdoors under a tarp shelter I put up recently, in four nested sleeping bags. it's raining on the tarp and dry in here. since I was having trouble standing I was looking through opentimestamps a little on my phone, which disabled airplane mode on its own some time while I was asleep. it looks like the calendar servers also do blockchain publishing remotely, and their protocol doesn't appear to require data other than the op_return payload, although i'm not certain of this. here's what I found: - they take only this payload when publishing - they expect a bitcoin daemon to be running on the server since the client also locally performs bitcoin publishing, they probably minimize their use of their blockchain, dunno. it's 5:34 and maybe i'll stand up! pretty hard. hmm. it's easier to stand up when there's a confident reason. let's check out that opentimestamps server behavior. the server is at https://github.com/opentimestamps/opentimestamps-server possibly. 535 -> the max length accepted is a constant called MAX_DIGEST_LENGTH 537 the timestamp is submitted to an aggregator attribute of the rpc handler self.aggregator.submit(digest) . I don't see where aggregator is set yet. the max digest length appears to be 64 bytes. 539 aggregator is manually set by StampServer which accepts it to its constructor second parameter, after address 541 the otsd entrypoint is in the root folder of the repo it instantiates an Aggregator class 543 Aggregator is in calendar. in its submit function it has further code for adding a nonce server-side, with specific purpose of preventing control of published data by the client. it's possible this was done poorly, but it seems calendar servers are unlikely to be good for publishing data.