pull down to refresh

100 sats \ 2 replies \ @0xbitcoiner 11h \ parent \ on: Excuse me, but wtf is `0b25fe64500d04` in this bolt11 test vector?? lightning
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.
write
preview
33 sats \ 1 reply \ @ek OP 10h
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
0 sats \ 0 replies \ @0xbitcoiner 9h
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
reply