07:28 < jonasschnelli> what is the best strategy to deserialize a varlen string from a stream with unknown length (burst read)

07:29 < jonasschnelli> NetMessage reads in bytes with unknown length, so it is unknown if the varstring is complete in buffer

07:29 < jonasschnelli> I'd like to figure out if the all bytes for the varlen-string are copied to the buffer

07:58 < fanquake> wumpus 13796 and 13852 (both 0.16) should be able to go in.

08:16 < wumpus> jonasschnelli: I'm confused--the normal varstring is unknown length isn't it?

08:16 < wumpus> fanquake: thanks will take a look

08:17 < jonasschnelli> wumpus: the problem is more complicated. I'm reading in bytes from a socket and I'd like to deserialize a varstring,... but need to know how many bytes I need to read from the socket

08:18 < jonasschnelli> So I need to look at the varint part of the varstring to know when I have finished readin the buffer that contains the whole varstring

08:18 < jonasschnelli> Since it can be 1 byte to n bytes

08:18 < jonasschnelli> not n but a verstring of 64bit length

08:21 < wumpus> the only way to do that would be to have a fixed-sized header that specifies the length to read, although this is typically DoS-prone especially if the buffer is allocated at once and remote can specify a very large buffer

08:22 < jonasschnelli> wumpus: Yes. But nevermind. I think i'm creating a non-existing problem

08:22 < jonasschnelli> I'm implementing BIP151 message structures: https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki#encrypted-messages-structure

08:23 < jonasschnelli> And the varstring command made me some problems... But I forgot that the inner message structure is always present at complete length (since it's MAC has must been checked beforehand)

15:03 < gmaxwell> lordcow in #bitcoin reports a compile failure on freebsd: https://pastebin.com/wBN0YChc

15:04 < gmaxwell> 08:02:23 < LordCow> gmaxwell: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512

15:14 < wumpus> hmm let me try

15:15 < wumpus> I did a recompile on freebsd yesterday so I'd be surprised

15:17 < wumpus> of master, though

15:22 < wumpus> anyhow probably best for them to create an issue w/ all the version information

15:23 < wumpus> it is possible that #13442 fixes it because it converts the failing inline assembly to intrinsice

15:23 < gribble> https://github.com/bitcoin/bitcoin/issues/13442 | Convert the 1-way SSE4 SHA256 code from asm to intrinsics by sipa · Pull Request #13442 · bitcoin/bitcoin · GitHub

18:24 < jimpo> Would love more reviews on #12254

18:24 < gribble> https://github.com/bitcoin/bitcoin/issues/12254 | BIP 158: Compact Block Filters for Light Clients by jimpo · Pull Request #12254 · bitcoin/bitcoin · GitHub

18:26 < jonasschnelli> jimpo: Will do... almost forgot about it. But I guess its something for 0.18 which means its not pressing

18:27 < jimpo> thx

18:37 < jimpo> Not sure about the release schedule, but it's blocking further progress on block filter indexing and ultimately BIP 157 P2P support

18:40 < jonasschnelli> jimpo: Yes. Review can always happen,.. a merge though requires spun off of the 0.17 branch (since we are in feature-freeze currently)

18:40 < jonasschnelli> But we all want to see progress on BIP157...

22:02 < gmaxwell> MarcoFalke: sipa: is anyone running 13907 on a listening node? I need feedback on if I'm going to have to increase the limit to 100 or not.

22:07 < sipa> will run

22:08 < gmaxwell> (i just don't want to bother updating it to pull the tests without knowing what threshold we're going to use)

22:17 < sipa> running

22:26 < gmaxwell> sipa: thanks

22:26 < gmaxwell> sipa: grep log for "locator" after a bit