Constant

1mo ago

People are worried about their keys getting compromised, and they want fancy systems.
Yet i dont see any of you timestamping your content, which regardless of how you handle moving to a future key, is needed to 'protect' all your existing content based on the old one.

Normalize timestamping before we do anything else

See translation

5
4
1
0
0


Do you have thoughts?

Log in to leave a comment


Replies

Bitbilly

@Bitbilly

1mo ago

Whatchoo talkn bout Willis, please explain.

See translation

1

2
0
0
0

Constant

@Constant

1mo ago

NIP-03 specifies how to use Bitcoin Opentimestamps on Nostr events; the result is that you have a proof an event atleast existed at that time. If you apply this consistently, you can proof your older posts are indeed old.

The moment your key gets compromised, nothing stops an attacker creating events with bullshit timecodes, pretending to be old events from the past, eventhough they are just freshly created. But when you applied opentimestamps, the attack cant produce those (because it cant turn back (Bitcoin-)time), so i can never confincingly lie about your past, only lie about the present/future.

If you publish the fact that a key is compromized, and timestamp that; the attacker can no longer confincingly attack your future either.

See translation

1

10
3
0
91

Bitbilly

@Bitbilly

♥︎ by author

1mo ago

Wow, thank u for that

See translation

0

1
0
0
0

plantimals

@plantimals

1mo ago

do you mean the open timestamps nip03 style?

See translation

1

0
0
0
0

Constant

@Constant

1mo ago

Yes, i do.
I know amethyst has atleast some sort of implementation ( you need to do it manually, but it works). Don't know about other clients

See translation

0

0
0
0
0