Include recent blockhash

[nostr-protocol]

Include recent blockhash

[fiatjaf]

Good point. Let's do it.

[fiatjaf]

@sdgathman I don't know why you commented on this issue since it is very unrelated to what you're talking about, but fine. Maybe https://github.com/nostr-protocol/nips/discussions will be a better place.

Or https://t.me/nostr_protocol.

That's in case you don't want to just open https://coracle.social, https://snort.social or https://nostrudel.ninja and write stuff on Nostr. Feel free to tag me in there: https://njump.me/fiatjaf.com

[sdgathman]

I've since learned that the "blockhash" referred to is not a previous nostr event (as I assumed coming from SSB), but the bitcoin blockchain - used as an authoritative event ordering source. So yes, my already disclaimed comment is ignorant. My initial comment on SSB not actually needing to store the entire history is correct, however.

[MaxHillebrand]

Notice that including the current tip of the heaviest chain is subject to reorgs. For security it does make sense to have a threshold number of confirmations. However, for best UX and narrowest time window, it would be better to include the most recent.

This can be solved inefficiently by including two block hashes, the most recent and the one with 6 confirmations.

[sdgathman]

The README.md asks (for SSB protocol): "each server/user needs to store all the chain of posts to be sure the new one is valid. Why? (Maybe they have a good reason.)"

The answer is, they really only need to store the chain since a known good post - but no one has gotten around to writing code to expunge old posts, garbage collect media files, and mark the new origin as previously verified (before deleting history), and signing said mark. (SSB style would be a new post type.) This was discussed on SSB among devs.

Similarly, it is not actually necessary to have the entire blockchain for Bitcoin/Namecoin on every node - as long as you have a trusted more recent origin.

Disclaimer: just examining NOSTR, so the following may reflect ignorance:

But is is necessary to either include a sequence number in the signature for NOSTR events, or include the hash of the previous event for a pubkey. You should probably detect "forks" (duplicate sequence for a pubkey) as well like SSB. This could mean a privkey has been compromised - or it could mean users really want multiple devices, and NOSTR should implement some kind of event ordering resolution between user devices/sessions a la Matrix protocol. (Not sure how that would work for mostly offline usage.)

[MaxHillebrand]

I've since learned that the "blockhash" referred to is not a previous nostr event

I've updated the top comment to be more clear, sorry for the confusion.