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.