Subnostr

so i guess you like it then :D cool! pls nag the nip guardians to merge it

you may want to have implementations add a word at the start to distinguish it from BIP-39

just “nsec” should work

XORing the checksum by 128 instead of OR would also guarantee it is rejected by BIP-39 implementations

also, small typo: “the most significant

byte (bit 8) is set to one”

I think you meant bit

ok, making these fixes now

Thoughts on Alby and how long the waitlist...noob here.

off topic but i have two invite codes if you want an alby account, you need an email address for the login

Sorry bout OT, I posted a couple days ago asking anyone but nothing hear ;o)

How would I get the code?

I'm super green here. I see you message but no reply button and don't know how to DM here. Are you guys not using Alby because need email and using private key diif way? Sorry to bother you, I will just search online for ways unless you have link for info, etc. I'm using nostter client right now.

Alby 1y ago

dm nostr:npub14wxtsrj7g2jugh70pfkzjln43vgn4p7655pgky9j9w9d75u465pqvagcye he was quite generous with invites as well

Thank you for everything!

very odd for some reason i can't reply to nostr:nprofile1qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyr2enmkd6g40evtzaavjwrw62sn4ndhwg9p9yvzlzm4vy8h35zdc229yqyk 's note here on coracle but i asked foro the email to put in for the invite but never saw it

I see your message now, I notice when on diff clients see some same messages and some I don't see. will catch over on our chat

i just needed you to DM me an email address for you to use

no, you don't understand the reason for the MSB being 1

it has to be 1

you could XOR it if it doesn't have a 1 in the MSB but this complicates the logic versus just using OR to force the bit on, and it's a trivial improvement of check strength, that isn't really worth the extra algorithm complexity IMO

when the MSB of the 33 bytes is force-set to 1, the division/modulo operation will always generate 24 values of 11 bits each by dividing/modding by 2048, it's just simpler than more logic to handle small keys (think like proof of work stupid secret) - it does happen, that random values could have 11 zeroes in the most significant bits, so avoiding them being swallowed by the division operation just simplifies it

i don't think it shifts around the bits but you can't just slap a zero word (abandon) back on it and it' works, that is broken

you shouldn’t be interpreting it as an integer either way and instead decode it to bits word by word

it's a simpler implementation, the implementation is not material to the encoding except for that first word and 1 bit out of 8 for a simpler encoding that runs an iterative word-wise division and multiplication series is simpler shorter code

i thought about drawing 256 bits in a line and creating a scheme to encode the bitshifts required for each group of bytes but - it's just more complex and error prone, it will be a longer piece of code compared to a big integer division and multiplication function

mainly, it requires a another table, which i estimate would be about 96 bytes long to hard-encode all the decisions required to do it by bit shifting

because our divisor is a power of two, the CPU is also optimizing this heavily as it knows that it's a shift of 11 in either direction

because our bit-size is a power of to, 2^11, the CPU can optimize the operation as bit shifts along 64 or 32 bit wide segments of the number anyway, it is a false economy using a table of bitshifts, you can do it this way destructively, just like in my algorithm

the big number integer math library does not do anything complex for this operation, it's shift and overflow/underflow, because it's a power of 2

also, btw, if you switch it over to arrays of 64 bit words the operation is easy to see how fast it actually will be run by the - each 11 bit division round is done by shifting 5 64 bit words right (from right to left

I also don’t see the benefit of having the MSB as 1: you can pad the serialized result anyway

and about decoding to an array of bytes, both strategies are possible depending on your platform since 24 words is 33 bytes exactly means both approaches produce the same result if using big endian.

there is no way around the intermediate stage of 11 bit words spread out... the bech32 encoder does the same thing on bytes, it has an operator that expands the bits and then lookup table to get the characters from the charset

because the division operation won't yield the first x groups of MSB zeroes, it operates from right to left

it could be the msb or the 11th msb, but with all zeroes in the first 1 or 2 11 bit parts of the number the division doesn't see them, you go to zero and then you have 23 or 22 or 21 11 bit values

just try modifying the implementation to skip the check and assume 33rd byte is all zero, and see what happens when first X of the 11 bit fields are also zero

the way you are proposing forces you to copy 32 byte segments on each operation to another position whereas the division lets you do it as 5 64 bit right shifts copying the overflow into the 11 bit field array

24 right shifts on 5 64 bit words versus 24 copy-and-shift operations, plus you have to have a lookup table to decide the shift at each point because they only coincide at 88 bit boundaries

11 and 8 is nasty, and 64 bit processor will optimize if you just use division and multiplication with powers of 2

i used to think it would be like you but go look it up, power of two in integer division and multiplication is optimized into bitshifts and bitshifts are funneled down in a second decision step to use the multiply/divide circuit

oh yeah, this is probably a big part of the reason why btcec is so much slower than libsecp256k1 too, because the secp256k1 library does it via 64 bit word multiplication and division operations, catching the result in the overflow register

why can’t you separately store the length of the integer with zeroes included?

you can implement it how you like

is there a practical reason why putting a sentinel in the MSB is a problem for your implementation?

not really, but it could be viewed as odd by most implementors and feels kind of pointless

I would also recommend XORing the other 7 bits by a constant, to ensure that it can never match BIP39 seeds

if you don't have a bit turned on in the first 11 bits, you can't use a "is it zero" test to terminate the div/mod operation encoding it...

this is an operation that is going to be done on a computer, not on an embedded chip, it's less complex logic than running an iteration counter, in terms of C code it's one of the `for` clauses empty, because you only need the test in the middle, and don't need a counter

you have to do a test in the for loop anyway so being able to omit the counter is an optimization of complexity

i don't see what the point of this XOR operation means, 99.9999% of valid encodings are going to not satisfy the invariant of the check bytes of a BIP-39 master key mnemonic, how many bytes is the check? 24? 32? that's a lot of bits that are not gonna be right for a genuine random 32 byte key, more likely fail parity than not

also, isn't the BIP-39 check on the right side?

it's beyond an edge case, because it's also a user error on top of an infinitesimally small probability that a random key has a valid check

oh, right

yes, that was why i put it in there, simplicity

also i checked, the check bytes of BIP-39 are a byte on the right hand side

firstly, if your hardware supports this, it can rule out any string that puts a 0 on the MSB on the left as being nostr key

secondly, the bip-39 check on the LSB is highly unlikely to match up, it is a 0.5% chance of a valid bip-39 key being imputed from a nostr secret key mnemonic, probably you can cut that in half even since the MSB has to be a 1