What is Nostr?
Russell O'Connor [ARCHIVE] /
npub1dw8…plrw
2023-06-07 18:18:44
in reply to nevent1q…3dpp

Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-28 📝 Original message:Hmm? If I'm following what ...

📅 Original date posted:2019-06-28
📝 Original message:Hmm? If I'm following what you mean, that's not the P2P rules, it's the
> Unserialize code, in particular:
>
> compat/assumptions.h:52:static_assert(sizeof(int) == 4, "32-bit int
> assumed");
>
> serialize.h:289:uint64_t ReadCompactSize(Stream& is)
>
> serialize.h-679-template<typename Stream, unsigned int N, typename T,
> typename V>
> serialize.h-680-void Unserialize_impl(Stream& is, prevector<N, T>& v,
> const V&)
> serialize.h-681-{
> serialize.h-682- v.clear();
> serialize.h:683: unsigned int nSize = ReadCompactSize(is);
>
> (and other Unserialize_impl implementations)
>
> However, ReadCompactSize throws "size too large" if the return value is
> greater than MAX_SIZE == 0x02000000 =~ 33.5M, which prior to the implicit
> cast to 32 bits in Unserialize_impl. And it looks like that check's been
> there since Satoshi...
>
> So as far as I can see, that encoding's just unsupported/invalid, rather
> than equivalent/non-canonical?
>

Thanks for this correction! I totally missed that MAX_SIZE == 0x02000000.
I think I mistook it for SIZE_MAX when reviewing this, or just didn't
notice it at all.

Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/e7442a36/attachment.html>;
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw