What blocks the attacker to go back in time and publish a second pubk B? How do you know which event to trust if you have two of them?
Discussion
Couple of solutions could be
1 Relays relaying meta data about when they received it. Means bigger nips.
2 Relays not accepting 'declaration of successor' more than 7 days old. Not sure if this needs a nip.
What if you are using the Gossip Model (Auto finding relays) and the attacker gets a hold of your keys, changes your relay to their custom relay and remove those protections?
I think easiest is to block successor events that are older than 7 days. I could do this on nos.lol with plugin. Anybody can query it then to find the earliest successor event for a given pub.
NIP-03: OpenTimestamps Attestations for Events
"While OpenTimestamps can create timestamps without a local Bitcoin node, to verify timestamps you need a local Bitcoin Core node (a pruned node is fine)."
OpenTimestamps looks like overkill.
What do you think of 'declaration of successor' events to be blocked by relays when they are older than lets say 7 days?
Relays shouldn't have to be trusted.
It's not really true that you need a full node to verify OTS timestamps, you can use an SPV-like trust model where you just have the Bitcoin block headers and check their POW. The headers are just 80 bytes per block.