pull down to refresh

It’s base32, not base256

reply

So, does that mean each byte is 5 bits?

reply
reply

0x01 = 00001
0x0c = 01100
0x12 = 10010
0x1f = 11111
0x1c = 11100
0x19 = 11001
0x02 = 00010

00001 01100 10010 11111 11100 11001 00010

5bit byte to 8bit byte

00001011 = 0x0b
00100101 = 0x25
11111110 = 0xfe
01100101 = 0x65
00001101 = 0x0d
00000100 = 0x04

0b25fe650d04!

reply

This is such a good skill to have.

reply

Yes, I’m embarrassed it didn’t occur to me to interpret my 5-bit bytes as 8-bit bytes, haha

reply

Don't be. This is exactly why teamwork is important.

reply

Nice, thank you so much!! I literally spent multiple days on this hahaha

But you've made a mistake, it should have been:

01100100 = 0x64

instead of

01100101 = 0x65

Then it's 0b25fe64500d04, but 0x0d != 0x50, 0x04 != 0x0d.

Probably some encoding / endianess thing.

Edit: I think I just copied too many timestamp bytes, so 0x50, 0x0d and 0x04 aren't actually part of the timestamp.

reply

Must've been a copy/paste screw-up. Did you figure out the conversion yet? I tried it again and fail at hex 0x02.

0x01 = 00001
0x0c = 01100
0x12 = 10010
0x1f = 11111
0x1c = 11100
0x19 = 11001
0x02 = 00010

00001011001001011111111001100100010 -> 1496314658 ✔️
00001011 00100101 11111110 01100100 010
0x0b 0x25 0xfe 0x64 0x02

Those 3 bits (0x02) might already be part of the next byte. Makes sense 'cause 0x50 is 01010000.

reply

I think what's going on here is that to go from 010c121f1c1902 in base32 to 0b25fe64 in base256, we group the bits into 8 bits from the left and pad at the right after 35 bits:

00001 01100 10010 11111 11100 11001 00010
 0x01  0x0c  0x12  0x1f  0x1c  0x19  0x02

00001011 00100101 11111110 01100100 010ppppp
    0x0b     0x25     0xfe     0x64     0x40
                                          ??

This is what you've shown in #1342878.

But to interpret the bytes in base32 as bytes in base256 that can then be interpreted as the timestamp, we actually need to group the bits into 8 bits from the right and pad at the left after 35 bits:

00001 01100 10010 11111 11100 11001 00010
 0x01  0x0c  0x12  0x1f  0x1c  0x19  0x02

ppppp000 01011001 00101111 11110011 00100010
     0x0     0x59     0x2f     0xf3     0x22

and 0x592ff322 in base256 is indeed 1496314658.

Or you can just shift 0x0b25fe64 5 bits to the right to remove the padding on the right, and you get 0x592ff322!

reply
00001011 00100101 11111110 01100100 010ppppp
    0x0b     0x25     0xfe     0x64     0x40
                                          ??

this 👇

from https://github.com/lightning/bolts/blob/0cf21511a781c295b9374aeaef37cf9c4d193502/11-payment-encoding.md?plain=1#L396

6c6e62630b25fe6450

ppppp = 0x10 (bin: 1 0000)

0101 0000 = 0x50

deleted by author