< dongcarl> Hi all, would like to learn about how the p2p code in bitcoind is structured... I'm guessing src/net* are the files to look at, but I can't find an "entry point" that handles and initiates TCP connections, could someone point me to the right place?
< echeveria> ProcessMessage is where the magic happens.
< dongcarl> echeveria: I'm also seeing that CConnman is also important?
< sipa> echeveria: ProcessMessage is message processing, not network code
< dongcarl> Is... ProcessMessage a 1300-line function?
< sipa> sure
< echeveria> dongcarl: look at CConnman::ThreadSocketHandler, etc.
< dongcarl> Ahhhh... anything other than CConnman?
< sipa> echeveria: almost
< sipa> socket handling deals with connections that are already open
< echeveria> sipa: can we go back to 0.1 where things make sense?
< sipa> echeveria: they didn't
< sipa> or did you really prefer having the wallet code mixed with the network code and gui calls in main.cpp?
< sipa> dongcarl: most basic is probably ConnectSocketDirectly in netbase.cpp
< sipa> dongcarl: then CConnman::ConnectNode is higher level
< sipa> then OpenNetworkConnection on top of that
< echeveria> sipa: still fascinating that it worked at all.
< midnightmagic> I didn't like the interleaved logic, but I found the old code to be extremely legible.
< echeveria> hey at least bitcoin doesn't make HTTP requests using raw sockets now.
< dongcarl> ThreadOpenConnections -> OpenNetworkConnection -> ConnectNode -> ConnectSocketDirectly ?
< dongcarl> and Start -> ThreadOpenConnections ofc
< sipa> midnightmagic: i agree, it was readable... or at least so it seemed until i tried to figure out how the wallet ever learned a particular output was being spent
< sipa> midnightmagic: turns out there was a callback from the script execution code into the wallet...
< sipa> but sure, things have gotten a lot more complicated since
< sipa> the code also does a lot more
< midnightmagic> sipa: I don't think it's more complicated in the comprehension sense, just.. harder to navigate with my preferred terminal tools is all. cscope is required (for me) now due to the logic spreading across multiple files. I don't think it's a problem, just I think peeps take some other types of tools for granted these days I guess. :)
< dongcarl> Looking into libconsensus as well... I'm wondering if the API detailed in https://github.com/bitcoin/bitcoin/issues/6714 still holds... Seems like jtimon and NicolasDorier did a bunch of work that's been closed due to inactivity?
< midnightmagic> sipa: tangentially, you ever detail your dev tools anywhere?
< dongcarl> midnightmagic: SuperCoder 2000 ofc
< sipa> midnightmagic: i only use git grep and mcedit :)
< sipa> dongcarl: i don't think the libconsensus api ever changed
< sipa> apart from the addition of tx amounts for segwit
< dongcarl> sipa: Is there a particular reason why there was lack of interest in the PRs?
< sipa> dongcarl: lack of agreement on approach, i think
< sipa> and refactorings that keep going on for a long time are annoying to other contributors
< dongcarl> sipa: are the conversations/discussions recorded somehwere?
< midnightmagic> sipa: lol dangit. I forgot you do the same sort of thing I do.
< sipa> dongcarl: irc and github...
< sipa> dongcarl: but really, there just wasn't enough momenentum i think - those kinds of changes need many people to agree on a plan first
< dongcarl> sipa: Makes sense... Would Tokyo be a good place to talk about this?
< sipa> maybe
< jarthur> Hey, I'm able to reproduce this on both Debian jessie and Debian stretch - https://github.com/bitcoin/bitcoin/issues/8749 - any of you run into it yet?
< jarthur> libboost 1.62.0.1 packages
< sipa> jarthur: have you tried reinstalling the boost packages?
< sipa> make sure they're all the same version
< sipa> if you have a locally installed version, point the configure script to it
< jarthur> sipa: using the apt packages. Will double check all the versions now. One thing I did was install the libs first, then the -dev packages.
< sipa> also try clearing your config cache
< sipa> "git clear -dfx" wipes everything not committed in the source tree
< jarthur> Using the source tgz
< sipa> in that case, delete the build dir and extract again
< sipa> (but you should really consider building from git, if you do it repeatedly)
< jarthur> sipa: confirmed all libboost pkgs show same version. Re-extracted, autogenned and such. Maybe it's an issue with using --no-install-recommends when installing the libbost-*-dev pkgs. Doing this for a large-scale docker deployment, so keeping things minimal.
< jarthur> s/libbost/libboost/
< jarthur> sipa: yea, seeing it on Ubuntu as well. If we didn't need libboost-program-options-dev before, maybe this is a new autogen macro issue. Looked back at old debs and never saw libboost-program-options-dev being pulled in as a dep or recommends.
< ken2812221> jarthur: libboost-program-options-dev is no longer required since #13482
< gribble> https://github.com/bitcoin/bitcoin/issues/13482 | Remove boost::program_options dependency by ken2812221 · Pull Request #13482 · bitcoin/bitcoin · GitHub
< Dizzle> ken2812221: yep, you're so right
< Dizzle> thanks!
< jarthur> ty
< kallewoof> How do the recoverable ecsda signatures differ from the regular ones aside from the recid + compressed prefix byte?
< sipa> not
< sipa> they're literally a normal signature + recid
< kallewoof> Great! Thanks
< sipa> also, don't use them :)
< kallewoof> I'm writing a BIP for the sign|verifymessage proposal from ML from awhile back. How would the verifier extract pubkey?
< kallewoof> +if not using recoverable sig
< kallewoof> Just brute force it?
< sipa> the script based stuff?
< sipa> script doesn't have any recoverable sigs
< kallewoof> Was gonna just say "include a 1 byte 'flags' whose lower 2 bits are the recid and upper 6 bits reserved for future flags". Yeah.
< sipa> that makes no sense
< kallewoof> Because you can just brute force it?
< sipa> they whole point is that you can just reuse script
< sipa> no
< sipa> the signature can literally just be a witness
< sipa> which for a p2wpkh output contains a pubkey+sig
< kallewoof> Doh. Yeah.
< sipa> it's a bit longer, but meh
< kallewoof> I got things mixed up. I somehow assumed I needed the pubkey
< sipa> it's super flexible, and you don't need any script modifications at all
< kallewoof> Yeah
< provoostenator> Not sure how much people rely on the "mark as resolved" feature on Github, but I've already seen it vandalized at least once by drive-by-resolvers.
< wumpus> I didn't even know such a feature existed, it's curious that it allows for drive-by-resolvers and not only the opener to resolve it as on most sites
< kallewoof> I was afraid to touch it. Anyone can resolve anything? That sounds broken
< wumpus> cannot find anything about this feature online
< wumpus> provoostenator: how would one (hypothetically speaking) go and abuse this feature?
< provoostenator> Marking a comment as resolved hides the thread for other reviewers by default. So basically you should always unfold them to see if you agree a comment was addressed.
< provoostenator> It's a rather stupid feature IMO, only the person raising an issue should be able to mark it as resolved, if anyone.
< aj> provoostenator: repo owners being able to makes sense too... i keep getting worried about misclicking on those buttons when reading reviews now :(
< instagibbs> um am i the only person getting importmulti rpc test failure on master, "bytes_to_hex_str" not defined?
< instagibbs> ok fixed just a bit ago, nvm