reply on: Excuse me, but wtf is `0b25fe64500d04` in this bolt11 test vector?? \ stacker news ~lightning

pull down to refresh

0 sats \ 11 replies \ @ek OP 22h \ parent \ on: Excuse me, but wtf is `0b25fe64500d04` in this bolt11 test vector?? lightning

It’s base32, not base256

0 sats \ 10 replies \ @0xbitcoiner 22h

So, does that mean each byte is 5 bits?

21 sats \ 9 replies \ @ek OP 22h

Yes

5142 sats \ 8 replies \ @0xbitcoiner 21h

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!

100 sats \ 2 replies \ @optimism 20h

This is such a good skill to have.

100 sats \ 1 reply \ @ek OP 20h

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

148 sats \ 0 replies \ @optimism 20h

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

33 sats \ 3 replies \ @ek OP 20h

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.

100 sats \ 2 replies \ @0xbitcoiner 16h

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.

33 sats \ 1 reply \ @ek OP 15h

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!

100 sats \ 0 replies \ @0xbitcoiner 15h

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

0 sats \ 0 replies \ @0xbitcoiner 17h

deleted by author