Oddbean new post about | logout
▲ ▼
mleku | 4 months ago (raw) | root | parent | reply | flag +1 
 ah, yes, so you are gonna do the same as what the rest of them do because of the survivorship bias of not seeing the users who left for reasons of not being able to use DMs, helpful.
▲ ▼
mleku | 4 months ago (raw) | root | parent | reply | flag 
 it is the fault of the NIP maintainers also, btw, because BIP-340 clearly states this

but then again BIP-340 is horribly worded as well, it took me some time to figure a lot of it out... my fork of btcec has the extra 4 test vectors in the test suite that roasbeef refused to bother to complete, i even handed it to him on a platter
▲ ▼
melvincarvalho | 4 months ago (raw) | root | parent | reply | flag 
 It's not that.  There's tons of ways to do a DM already.  They all work.  Cant really invalidate user accounts on an existing system, that prides itself on users not being able to be cancelled.  That would go against the marketing.  Devs will just have to find another way, of which there are multiple, and they'll figure something out.
▲ ▼
mleku | 4 months ago (raw) | root | parent | reply | flag +1 
 yeah, i've been thinking about it, because i have part way done the tooling to manage a paid relay service using DMs and for the customer side we need to be able to tolerate anything, so there's things that can be done

one, the relay will never generate or use 3 keys, that's now fully fixed in my codebase

two, the initial messages with a user will send out assuming both 2 and 3, and each one will have a different string that the user is asked to paste and return, and this will confirm, and if 3 keys are discovered they will be stored in the database - probably just make a public event with a note saying "this key is an odd key" so others can discover this after that

i think that is enough measures

other than simply pointing it out to the nip guardians that their protocol uses ecdh without strict odd prohibition (as you say, you can either roll again for a 2 or you can modulo subtract the curve order G from the key and voila - considering this avoids needing to derive the key again i might need to revisit this option