< fanquake> Can someone add zeromq 4.2.2 & 4.2.3 to /depends-sources on bitcoincore.org
< spence> I have a noob-ish question. How does the code determine the buffer size when reading the blocks, like in reindexing? I'm playing around with adding my own custom data structure to blocks, and I'm getting an ioerror "read attempted past buffer limit".
< sipa> ?
< spence> sipa is that in response to me?
< meshcollider> spence: I would imagine so :) adding custom data structure to blocks sounds like ##altcoin-dev rather than this channel I think?
< Varunram> meshcollider: he quit :/
< meshcollider> Heh oh well
< viru> hi
< meshcollider> viru: hi
< echeveria> wish list: getmempoolinfo should show the size of the extra transactions pool.
< wumpus> what is the 'extra transaction pool'?
< echeveria> the compact blocks rejected transaction cache.
< wumpus> oh that, yes was confused with the mempool relationship, but sure you could add the size of that structure on some RPC
< gmaxwell> echeveria: patches welcome, that would be a oneline change.
< wumpus> maybe three lines; would need to add a function to net_processing.cpp to query it from outside, too. But yeah definitely a good first PR.
< wumpus> zelest: great to hear that the second try worked :)
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/711d16ca4a91...180a25596a29
< bitcoin-git> bitcoin/master a6365c5 Cory Fields: depends: fix libzmq's needless linking against libstdc++...
< bitcoin-git> bitcoin/master 180a255 Wladimir J. van der Laan: Merge #11981: Fix gitian build after libzmq bump...
< bitcoin-git> [bitcoin] laanwj closed pull request #11981: Fix gitian build after libzmq bump (master...fix-gitian-build) https://github.com/bitcoin/bitcoin/pull/11981
< zelest> wumpus, now it failed on Qt though.. :P
< zelest> wumpus, but I get the same errors from electrum when I start it.. I think it's related to how X is compiled :/
< wumpus> I don't think anyone ever got the GUI to work on openbsd
< wumpus> personally I've never used it with a graphical environment of any kind at all, just as server, so I don't know
< wumpus> (openbsd, that is.)
< wumpus> but please let us know (and add instructions to the openbsd build guide) if you do get it to work
< zelest> I'll do my best :)
< zelest> I use it as my primary OS since 1.5 year back so
< wumpus> I still use linux for that
< zelest> :)
< Lauda> wumpus kick in #11976, stupidly missed 1 link
< gribble> https://github.com/bitcoin/bitcoin/issues/11976 | [Doc] Fix link to installation script by laudaa · Pull Request #11976 · bitcoin/bitcoin · GitHub
< zelest> Lauda, i should've reported that myself :D
< Lauda> If you do find more errors in the docs, please do
< Lauda> this was broken for about a month I think :x
< zelest> as wumpus said, not many people use openbsd as their desktop OS :)
< zelest> also, this build fail is OpenBSD related..
< Lauda> True, but when I found the error I was checking other files for broken links
< zelest> Lauda, yeah :)
< luke-jr> will zelest become our new OpenBSD support dev? :P
< Lauda> uh oh, that would be nice
< zelest> Haha, if I only knew enough about coding :P
< zelest> However, I'll do my best :) OpenBSD does have some nice malloc features.. which basically make it a rather unpleasant OS for poorly written software..
< zelest> So it's nice to find bugs with :)
< bitcoin-git> [bitcoin] laanwj opened pull request #11984: doc: Update OpenBSD build instructions for 6.2 (master...2017_12_openbsd_build_update) https://github.com/bitcoin/bitcoin/pull/11984
< bitcoin-git> [bitcoin] laanwj closed pull request #11976: [Doc] Fix link to installation script (master...master) https://github.com/bitcoin/bitcoin/pull/11976
< bitcoin-git> [bitcoin] fanquake opened pull request #11986: [depends] zeromq 4.2.3 (master...zeromq-4-2-3) https://github.com/bitcoin/bitcoin/pull/11986
< zelest> aha! success!
< * zelest> will add some updates to the OpenBSD build guide :D
< jonasschnelli> zelest: thanks
< wumpus> zelest: please base it on https://github.com/bitcoin/bitcoin/pull/11984, so we can do the changes in one go
< zelest> just need to read up on the routines and such regarding forking and creating pull requests.. sadly at work atm as well :)
< zelest> ahh
< wumpus> you can also just comment on the review then I'll update the document
< zelest> I will setup a VM with a fresh install and verify all steps though
< zelest> as there's a few more packages that needs in (if one wish to run GUI)
< wumpus> GUI is not currently part of the description at all, would add that in a separate section at least
< zelest> yeah
< bitcoin-git> [bitcoin] janstary opened pull request #11987: Tweak the OSX build instructions (master...macos) https://github.com/bitcoin/bitcoin/pull/11987
< bitcoin-git> [bitcoin] AkioNak opened pull request #11988: Reduce redundant code of prevector and speed it up (master...prevector) https://github.com/bitcoin/bitcoin/pull/11988
< locus_> What happen to Bitcoin network ? no block since 12 hours, Is the price is falling due this issue?
< jouke> I just received a block a couple of minutes ago.
< bitcoin-git> [bitcoin] Sjors opened pull request #11989: [build] .gitignore: add QT Creator artifacts (master...ignore-qt-creator-artifacts) https://github.com/bitcoin/bitcoin/pull/11989
< jouke> It's not that uncommom to wait for a block for more than an hour.
< provoostenator> loucs_: #bitcoin is more appropriate for these questions.
< provoostenator> I mean locus_
< wumpus> Last block was 500527, on Fri Dec 22 11:41:18 2017
< wumpus> well if it was bitcoin core he's running and it's stuck for 12 hours that might be a bug report, but he's already left
< meshcollider> where should the actual code to register args for each module go do you think
< meshcollider> the RPC stuff has a separate rpc/register.h header for the registration functions, and then the functions are spread over multiple files
< zelest> When downloading and synking the full blockchain, is it the bandwidth that's the bottleneck or is it computationally heavy to validate it all?
< meshcollider> but using a struct to hold the globals for the args for each module was suggested right? So where would be the best place for each struct and the corresponding registration code
< zelest> syncing*
< meshcollider> zelest: computationally heavy, verifying the signatures
< zelest> Ah, gotcha :)
< wumpus> meshcollider: in an init function per module, I guess
< wumpus> meshcollider: same as how the RPC registration works
< meshcollider> wumpus: I imagine all registration should happen during init and then call parseparameters, but how does that interact with -help, because -help should be checked before init proceeds further right?
< meshcollider> so really -help needs to be checked before the registration of args and thus before parseparameters?
< wumpus> meshcollider: I guess the registration needs to happen before -help handling
< meshcollider> wumpus: alright, seemed a little unnatural to me to put arg registration for everything even before that, but I guess it makes sense
< wumpus> meshcollider: that is kind of annoying, but no way around it, as -help is an argument itself *and* it needs access to all the registered other arguments
< wumpus> yes it seems kind of unnatural, but the alternative would be to make -help handling special, in that it separately calls the registration functions, I don't think that's better
< meshcollider> wumpus: no, I agree
< meshcollider> wumpus: So when you refer to "modules", do you mean like bitcoind, wallet, bitcoin-cli, bitcoin-qt and bitcoin-tx?
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/180a25596a29...f19ca129ffd7
< bitcoin-git> bitcoin/master 5cbbbd7 Sjors Provoost: [Wallet] Use RBF by default in QT only...
< bitcoin-git> bitcoin/master f19ca12 Wladimir J. van der Laan: Merge #11605: [Wallet] Enable RBF by default in QT...
< bitcoin-git> [bitcoin] laanwj closed pull request #11605: [Wallet] Enable RBF by default in QT (master...rbf-default) https://github.com/bitcoin/bitcoin/pull/11605
< meshcollider> wumpus: or more like wallet stuff, blockchain stuff, meta stuff like help/debug, etc.
< meshcollider> in terms of dividing up the structs of globals
< wumpus> meshcollider: I mean separate implementation units
< wumpus> meshcollider: yes, the second
< wumpus> the idea is keep the options as close to the code that uses them as possible
< wumpus> this allows for localized changes, without generating merge hotspots
< meshcollider> wumpus: does a new directory for arg files, which contains one for each "type" of args along with the function to register it all make sense?
< meshcollider> a bit like the rpc/ dir with register.h header
< wumpus> no, definitely not
< wumpus> you don't want to group the args together
< wumpus> you want to group the args with the code that uses them
< meshcollider> ah I see, hmm
< wumpus> creating a directory 'arg' would be like creating a directory 'types' which contains all types. It's not a useful semantic grouping :)
< meshcollider> wumpus: true haha
< meshcollider> I feel like this is going to be quite messy to decide where each arg goes though and what groupings make sense
< meshcollider> especially if certain args are used in multiple places
< wumpus> I agree it's a bit funny in the rpc case, why would rpcblockchain be under rpc and not under 'block chain functionality' but beh
< wumpus> grouping things is hard
< wumpus> meshcollider: yes...
< meshcollider> wumpus: and also, I have not thought much yet about how to replace SoftSetArg and ForceSetArg, the former being difficult to tell if a value has been set or not using just a pointer to a variable
< meshcollider> ForceSetArg should be ok I think
< wumpus> yes, this is quite an annoying project in that regard, having handle so many concerns at the same time
< meshcollider> mhm its a little overwhelming compared to what I have worked on up to this point :) good experience though
< ryanofsky> meshcollider, there should be no need for arg registration init functions in typical case. just declaring an arg could add it to global list of args as in https://gflags.github.io/gflags/#define
< ryanofsky> maybe you should describe what the proposed interface for registering and accessing args somewhere, before going to refactor all the code
< meshcollider> I was thinking to have a function like gArgs.RegisterArg("-foo", {"-foo", "does something", ARG_BOOL, &foo, false});
< meshcollider> Where second parameter is an enum with the info needed
< meshcollider> Then ParseParameters is called as normal which populate all the variables, and then those variables can be used directly without needing gArgs anymore?
< ryanofsky> meshcollider, that seems ok, but it is a little more verbose compared to gflags where you can just declare a global variable anywhere you want and don't need to write manual init code
< ryanofsky> also unclear why "-foo" option name needs to be repeated twice and why ARG_BOOL couldn't be derived from the type of &foo
< bitcoin-git> [bitcoin] Sjors opened pull request #11991: Segwit qt bech32 receive (master...segwit-qt-bech32-receive) https://github.com/bitcoin/bitcoin/pull/11991
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f19ca129ffd7...8f68fd281eec
< bitcoin-git> bitcoin/master 31a0135 Jonas Schnelli: Add required package dependencies for depends cross compilation...
< bitcoin-git> bitcoin/master 8f68fd2 Jonas Schnelli: Merge #11903: [trivial] Add required package dependencies for depends cross compilation...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #11903: [trivial] Add required package dependencies for depends cross compilation (master...2017/12/depends_pkg) https://github.com/bitcoin/bitcoin/pull/11903
< phantomcircuit> im not sure how i did this
< phantomcircuit> but everytime i issue the help rpc command
< phantomcircuit> my wallet is rescanned
< achow101> lol
< achow101> phantomcircuit: did you change any of the code?
< phantomcircuit> nope
< phantomcircuit> 18a1bbad98bd4321f15e7921d9aec91661499d90
< phantomcircuit> 2017-12-22 22:51:08 RescanFromTime: Rescanning last 500604 blocks
< achow101> That happens every time you use the help command?
< phantomcircuit> yeah
< phantomcircuit> actually i wonder if this binary is the one where i added my own rescan command
< phantomcircuit> hmm
< gmaxwell> did you add it to the wrong place?
< phantomcircuit> gmaxwell, nope
< phantomcircuit> i did not acquire locks correctly
< phantomcircuit> so
< phantomcircuit> rng behavior i guess?
< ryanw> just getting spun up for the first time, do people use qt as their ide like it mentions in the install docs?