Oddbean new post about login | logout well, at least make a loud pronouncement about not making odd npubs lol
I think this might be an acceptable solution. I suppose it cuts the key-space in half though?
that was implicit and is mentioned in BIP-340 just keep in mind that as it was, the bit-strength of secp256k1 is about 126 effective bits, and this only shaves off half a bit the permutations of those bits is an extra factor of two for every bit so it's not a linear relation, losing one bit is really losing 1/126th of the security the chances of collision are doubled and the time to average brute force is half, yes, but we are talking about a process that would take hundreds of years for one key with all the computers in the world
no, i think that's a bad idea. its doubling down on a bad design choice. lots of things will and should produce odd npubs, like hardware wallets etc. and there already are many users with '3', its not fair to invalidate, deprecate or cancel those accounts. just let 2s be 2s and 3s be 3s. and find work arounds such as kind=0. in any case im not touching it, because the protocol might get even more broken by well-intended efforts to fix a bad original choice. and we cant cancel half the user base, the system is already running... use workarounds!
i understand your point but the change i propose only affects two points of the system, where your proposal means a whole shitload of code has to be rewritten to accept 64 or 66 character pubkeys in the event, this is a larger compliance burden
To be clear. I propose no change. The protocol is working. I propose dont change it, and dont touch it. Find a NIP work around for one of the other NIPs that's fine. Let 2s be 2s and 3s be 3s, because we already have a user base of 2s and 3s and cant change that now. Extending profiles is a good way. I actually think profiles should be extensible by design, in a permissionless way.
you are saying allow 66 character pubkey fields tho, or what?
No. Let me be very clear now. Dont change the protocol. Let 3s exist on the network. Dont touch it, dont break what we have. I have no proposal. Whatever workaround you want, is find by me. Just dont change the protocol. Im specifically not getting involved, because I dont want the protocol to change. I'll just cross my fingers on that, tho!
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.
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
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.
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