OpenAuspex: Bitcoin-anchored warrant canaries for Nostr \ ~hyperlinks

pull down to refresh

OpenAuspex: Bitcoin-anchored warrant canaries for Nostr www.openauspex.dev/

655 sats \ 7 comments \ @Scoresby 12 Jun tech bitcoin

I'm not sure I fully understand the value of this:

I think I understand how a canary is useful, but I don't necessarily see the innovation with this particular canary protocol.

What is the value of adding open timestamps to this?

view all related items

248 sats \ 6 replies \ @optimism 12 Jun

What is the value of adding open timestamps to this?

Remember the link from our previous discussion.

The value is you know that a statement was made before time $t$ (with some mediantime consensus limit fuzziness) of the block timestamp it was included into, and if you have chained your statements to include the publication block hash of the previous message (just like how the bitcoin chain itself works) you also learn that the statement must have been made after $t_{- n}$ (of $b l oc k_{- n}$ ). So you can with confidence state that the message was created between $t_{- n}$ and $t$

Practical examplePractical example

I'm replacing ots with OP_RETURN <hash> and removing signing, for simplicity

Message 1:

PrevBlock: none
PrevMessage: none
Local Date: 2026-05-01
Statement: opti has not been bribed by the spooks

Message sha256: d623c64ed711932043d5057d37b108801df20a39dd9eba1c791e72c10736ac60
Post to chain OP_RETURN d623c64ed711932043d5057d37b108801df20a39dd9eba1c791e72c10736ac60.

This gets mined straight by Ocean cuz we not spamming, at timestamp 1777597200 (05/01, 1am UTC). Fictional blockhash: 0000000000000000000000000000000000000000000000000000000000000069

Message 2:

PrevBlock: 0000000000000000000000000000000000000000000000000000000000000069
PrevMessage: d623c64ed711932043d5057d37b108801df20a39dd9eba1c791e72c10736ac60
Local Date: 2026-06-01
Statement: opti has not been bribed by the spooks

Message sha256: f866376da13d0d5ff671deeb51b7b39158933cae317e6db947c23215c6598cf0
Post to chain OP_RETURN f866376da13d0d5ff671deeb51b7b39158933cae317e6db947c23215c6598cf0

This takes a day to get mined because fee pressure, at timestamp 178036200 (06/02, 1am UTC).

What we learn from this:

opti made statement 1:
- before 05/01, 1am UTC, or it couldn't have been included in the block
opti made statement 2:
- before 06/02, 1am UTC, or it couldn't have been included in the block
- after 05/01, 1am UTC, or opti couldn't have known the previous block the previous message was included in
If opti is not lying (and authenticating this, and opti's key isn't compromised, and SHA256 remains unbroken for (second) pre-image security), opti was not bribed by the spooks until at least 05/01, 1am UTC

In short: opentimestamps helps with this because we have trustless (=non-authoritarian) evidence about the window in which something was published.

113 sats \ 5 replies \ @Scoresby OP 12 Jun

Thank you for the detailed explanation. As you point out, even with the open timestamp, I'm trusting that opti's key is not lying (authenticating the canary even though opti has made a deal with the govt to share all comms) and not compromised.

But if I am willing to trust opti's key to do this, why would I not trust it to tell the truth about the date of the signature?

In the canary use-case, it seems to me that I am trusting the signer to not lie to me and that their key isn't compromised. If I am already trusting the signer on these counts, why would I not also trust them about the date of the signature?

146 sats \ 4 replies \ @optimism 12 Jun

You're not wrong about that. The timestamp now requires less trust than the rest of the canary. Lowest common denominator is still the trust on the author and the key.

In practice we anyway often see canaries expire through human error (and then technically we should burn that relation, but we rarely do) so generally a canary offers no protection at all. You're too late by the time you figure out something is up through the canary anyway.

That's why running a canary isn't really useful. I certainly don't consume them because the only way to deal with the type of nasty situations that a canary alludes to is prevention: if I don't provide any sensitive information to you, it doesn't matter if you are compromised.

92 sats \ 3 replies \ @Scoresby OP 12 Jun

I still think about your comment in the discussion about OpenSats letting their canary expire last December (#1334028) -- probably more often than I should.

For a canary to be useful, it seems that we must treat it with deadly seriousness. If we treat it that way, it must be used perfectly or not at all.

Still feeling weird about Open Sats.

125 sats \ 2 replies \ @optimism 12 Jun

If we treat it that way, it must be used perfectly or not at all.

Still feeling weird about Open Sats.

Right! So let's believe them at face value and they just forgot to renew it. They suffered reputation loss for letting the canary expire (at least they did with me and sounds like they did with you too) which is exactly why they shouldn't have had the canary in the first place. Because without it, there wouldn't have been a problem.

I understand that it is totally relevant to people that had to doxx themselves for receiving some sats. But... it doesn't help. They have your data. A subpoena won't be prevented by it. Them cooperating won't be prevented either, nor will them getting hacked. You lost all your financial privacy the moment you sent them that W9; not when you read that the canary didn't refresh.

I'd recommend against canaries. Better to spend energy on figuring out ways to not doxx your trading partners.

71 sats \ 1 reply \ @Scoresby OP 12 Jun

but canaries are sexy

2 sats \ 0 replies \ @optimism 12 Jun

(ps: generating this image without firing up a big inference machine privately got rejected in any form thinkable on every platform I tried... except Grok. Thanks SpaceX ~lol)