Bech32 encoding is relaxed about padding,
That is the part missing from the bip...
Topic: How are BIP173 test vectors "valid"? (Read 208 times)
That is the part missing from the bip...
I don't see anything wrong with these test vectors:
A12UEL5L
a12uel5l
an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharacter sbio1tt5tgs
?1ezyfcl
(empty data part, blue HRP, green checksum)
abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw
11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqc8247j
split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w
(red data part, blue HRP, green checksum)
Bech32 encoding is relaxed about padding, segwit address format requires padding when applicable, these test vectors are not segwit addresses, just some arbitrary bech32 encoded strings.
A12UEL5L
a12uel5l
an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharacter sbio1tt5tgs
?1ezyfcl
(empty data part, blue HRP, green checksum)
abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw
11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqc8247j
split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w
(red data part, blue HRP, green checksum)
Bech32 encoding is relaxed about padding, segwit address format requires padding when applicable, these test vectors are not segwit addresses, just some arbitrary bech32 encoded strings.
There are 7 test vectors at the top of the list that are supposed to be "valid Bech32" but I can't see how they are valid.
These have no data since the bytes after the separator is the 6 byte checksum:
A12UEL5L
a12uel5l
an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharacter sbio1tt5tgs
?1ezyfcl
These have data but none of them are properly padded! They all have leftover non-zero bites (3 or 5)!
abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw
11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqc8247j
split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w
I can get the first group being valid since that is just encoding of empty data (which is not SegWit address and just encoding) but the second group doesn't make sense, shouldn't the data be properly padded in those too?
These have no data since the bytes after the separator is the 6 byte checksum:
A12UEL5L
a12uel5l
an83characterlonghumanreadablepartthatcontainsthenumber1andtheexcludedcharacter sbio1tt5tgs
?1ezyfcl
These have data but none of them are properly padded! They all have leftover non-zero bites (3 or 5)!
abcdef1qpzry9x8gf2tvdw0s3jn54khce6mua7lmqqqxw
11qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq qqqc8247j
split1checkupstagehandshakeupstreamerranterredcaperred2y9e3w
I can get the first group being valid since that is just encoding of empty data (which is not SegWit address and just encoding) but the second group doesn't make sense, shouldn't the data be properly padded in those too?
Jump to: