Peter Todd

> Yes, I plan to run opentimestamps-server with a custom config to support faster transaction timestamping (for internal use). Faster timestamping on Bitcoin? Or on a different chain?

> On Bitcoin, I assume passing `--max-pending 1` lets the server create and broadcast a tx right away. Nope. `--max-pending 1` does the opposite actually: it would only allow one...

@giahuy98 FYI on my todo list is to also add a feature to the calendar to allow an upstream calendar to be used for the actual timestamp transactions, with the...

NACK without fixing the lack of an expiration time. Rational: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021849.html IMO better to discuss this issue on the bitcoin-dev mailing list, as it's relevant to all potential new address...

> If you wanted to champion carving out a standardness exception for unstructured annex data, I think that would be a worthy cause, and would allow this to come closer...

> Do you think there's a scenario where it makes sense for consensus-critical _and_ non-consensus-critical data to live in the annex? There definitely could be. For example my OP_Expire proposal...

@casey > One thing that would be nice about a TLV encoding is that different non-consensus metaprotocols and future consensus transaction metadata could all coexist in the same annex. In...

@joshdoman Yes, that'd be similar to the Lightning wire protocol's "it's ok to be odd" rule for tags. That said, note that I didn't actually propose a TLV scheme; I...

> I meant multiple non-consensus uses of the annex. Sure, you can do that with that I'm proposing too. Those uses just need to come up with their own protocol...

Concept NACK There's no reason to limit this behavior to TRUC/V3 transactions. The implementation should not ship with this restriction.