< promag_> achow101: do you have a newer Qt version available
< achow101> promag_: I can do a depends build
< promag> achow101: when I was doing #15153 usually I tested with -nowallet
< gribble> https://github.com/bitcoin/bitcoin/issues/15153 | gui: Add Open Wallet menu by promag · Pull Request #15153 · bitcoin/bitcoin · GitHub
< promag> it is kind of a surprise to see your behavior
< promag> I don't see any reason to be different with Qt 5.7 to be honest
< promag> is 5.7 what comes with debian
< promag> ?
< achow101> I think so
< promag> I'm downloading debian now to check it out
< promag> btw I'm working on top of your branch
< promag> gui-create-wallet
< achow101> originally I thought it was a problem with my branch, but i checked with my build of the master branch and it had the same problem
< promag> and there is nothing in .conf that could interfere?
< achow101> hmm. there's a wallet specified in there
< achow101> well commenting that out didn't change anything
< promag> I'll let you know how my debian test went
< booyah> 5.7.1 (plus custom patches)
< promag> booyah: ty
< achow101> promag: the depends build works. it doesn't have that issue
< achow101> so it must be some problem with 5.7.1
< promag> mother of god
< achow101> promag: when I was testing gui-create-wallet, if i used the create wallet option when -nowallet was set, it would create the wallet and load it
< achow101> the only difference between that and the open wallet option when it comes to loading the wallet is that open wallet uses a signal to call setCurrentWallet while create wallet called it directly
< achow101> and then open wallet works fine if used after create wallet
< promag> achow101: there is currently a problem
< promag> this was already identified
< promag> if that is called before WalletFrame::addWallet then it wouldn't show the wallet
< achow101> promag: but then why does different qt versions matter?
< promag> I'm guessing signal/slot ordering and because OpenWalletActivity is on a different thread
< promag> if that's the reason behind that problem I'm currently fixing it
< promag> I think you can call WalletFrame::addWallet in WalletFrame::setCurrentWallet to see if that's the problem
< achow101> ah, so the problem is likely that addwallet isn't being called before setcurrentwallet
< promag> yap
< achow101> promag: that fixed that problem but introduced a whole new one
< achow101> none of the tabs work and the dropdown for the wallet selector isn't there (i tried to load multiple wallets)
< promag> I said "to see if that's the problem"
< achow101> yes that is the problem
< promag> I think that new issue is because "BitcoinGUI::addWallet" wasn't called or something
< promag> don't worry about this
< achow101> ok
< promag> I'll try to give instructions on how to reproduce and submit a fix
< fanquake> I can confirm achow101's problem with qt 5.7.1
< fanquake> spun up a debian vm and get the same behaviour
< benthecarman> Hey what would be people's thought on adding rpc/cli commands to change config options
< benthecarman> My thoughts were for specifically rpcalllowip because it'd be nice to give an ip permission without needing to restart the node everytime
< sipa> that's a common suggestion
< sipa> and it certainly makes sense for a few things (rpcallowip is a good example)
< sipa> though it's very hard to do generically (because values of config options often affect how various derived variables are initialized stc)
< benthecarman> Yeah I imagine, need to write to file and change the permissions while running. If a PR was made, would it likely be approved however?
< gmaxwell> I'm unsure, the change would likely be highly disruptive and might not be justified for the benefit. :(
< gmaxwell> Sometimes we can't really tell if a change would be accepted until its done.
< gmaxwell> I think if you go read past discussions (which you absolutely should do before attempting or it probably won't be accepted!), you'll see that it's not really a simple question.
< sipa> benthecarman: oh, there is a PR to introduce a sepaeate writable config file for this purpose
< tryphe> what about accepting a dns/alias in addition to a netmask/CIDR? then you would just depend on the system to resolve the alias, and avoid remote changes
< gmaxwell> from a programming perspective sticking a DNS query in is pretty awful... as you now have network interaction in an otherwise trivial code path. DNS is also almost universally deployed in an insecure manner, so making your auth triggered by DNS usually immediately exposes it to attacks.
< gmaxwell> elsewhere where we've had dns resolution it's resulted in stupid bugs.
< tryphe> yeah, it would suck to switchover like 12 hours later because of dns caching, lol
< gmaxwell> (e.g. addnode)
< gmaxwell> sooo I'd really prefer not to. the rpc is really not intended to be used outside of a single host/vms/physically isolated lan/ etc.
< sipa> tryphe: if the expected behavior is that it is resolved once at startup time it is very easy to implement... but perhaps undesirable or at least unintuitive
< tryphe> yeah, or if you needed to, more practical to run a tunnel
< gmaxwell> yup which is also what we recommend.
< wumpus> yes tunneling is definitely the way to go for remote RPC, this is also what is suggested in `doc/JSON-RPC-interface.md`
< wumpus> it's cool that we're pretty much on schedule for 0.18 branch-off, two pulls to go for now https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.18.0
< IZooo> Hello :)
< wumpus> hi !
< droark> Hi. In testnet, it appears that dust limits for outputs (dustrealyfee) are ignored. Can somebody point out where in the code this exception occurs? I'm getting lost trying to find it.
< wumpus> droark: the dust check is done in policy.cpp, IsStandardTx, this isn't checked for regtest and testnet by default, but can be overridden using `-acceptnonstdtxn`
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/f9775a865597...3e1ca1348cbd
< bitcoin-git> bitcoin/master 745a2ac Hennadii Stepanov: Improve PID file removing errors logging
< bitcoin-git> bitcoin/master 561e375 Hennadii Stepanov: Make PID file creating errors fatal
< bitcoin-git> bitcoin/master 3782075 Hennadii Stepanov: Move all PID file stuff to init.cpp
< bitcoin-git> [bitcoin] laanwj merged pull request #15278: Improve PID file error handling (master...20190128-pidfile-logging) https://github.com/bitcoin/bitcoin/pull/15278
< droark> @wumpus - Thanks! Much appreciated. Missed the greater context.
< wumpus> yw
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3e1ca1348cbd...4d126f289c7d
< bitcoin-git> bitcoin/master 901baf2 fanquake: doc: update FreeBSD build guide for 12.0
< bitcoin-git> bitcoin/master 4d126f2 Wladimir J. van der Laan: Merge #15416: doc: update FreeBSD build guide for 12.0
< bitcoin-git> [bitcoin] laanwj merged pull request #15416: doc: update FreeBSD build guide for 12.0 (master...docs-freebsd-120) https://github.com/bitcoin/bitcoin/pull/15416
< wumpus> #15267 adds some documentation comments, would be nice if someone with a good grasp of the mempool/caching logic (sipa, sdaftuar ?) could review them for correctness
< gribble> https://github.com/bitcoin/bitcoin/issues/15267 | doc: explain AcceptToMemoryPoolWorkers coins_to_uncache by jamesob · Pull Request #15267 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4d126f289c7d...b853746d4a8a
< bitcoin-git> bitcoin/master 55e05a8 Martin Erlandsson: Added some factors that affect the dependency list
< bitcoin-git> bitcoin/master b853746 Wladimir J. van der Laan: Merge #15222: docs: Add info about factors that affect dependency list
< bitcoin-git> [bitcoin] laanwj merged pull request #15222: docs: Add info about factors that affect dependency list (master...patch-2) https://github.com/bitcoin/bitcoin/pull/15222
< wumpus> luke-jr: I've sent the addrv2 message draft BIP to the mailing list, can you assign me a BIP number please?
< bitcoin-git> [bitcoin] riordant opened pull request #15456: Enable PID file creation on WIN (master...master) https://github.com/bitcoin/bitcoin/pull/15456
< gmaxwell> If anyone is getting bored waiting for 0.18 to ship to get moving on other work... libsecp256k1 has a couple PRs that could just use some C code review:
< gmaxwell> also https://github.com/bitcoin-core/secp256k1/pull/584 (cross compiling build system review)
< wumpus> I'll take a look
< gmaxwell> and one final one https://github.com/bitcoin-core/secp256k1/pull/568 (which mostly I want plain C code review-- as it previously had a silly pointer vs int bug, though this one touches more complicated code that might leave people unfamilar with the library feeling lost)
< gmaxwell> wumpus: that would be great, thank you!
< bitcoin-git> [bitcoin] Sjors opened pull request #15457: Check std::system for -[alert|block|wallet]notify (master...2019/02/std__system) https://github.com/bitcoin/bitcoin/pull/15457
< bitcoin-git> [bitcoin] promag opened pull request #15458: refactor: Drop redundant wallet reference (master...2019-02-interfaces-wallet) https://github.com/bitcoin/bitcoin/pull/15458
< bitcoin-git> [bitcoin] marcoagner opened pull request #15459: [doc] release process: how to calculate m_assumed_blockchain_size and m_assumed_chain_state_size (master...doc_blockchain_and_chainstate_size_calculation) https://github.com/bitcoin/bitcoin/pull/15459
< jnewbery> Hi all. dongcarl is doing great work picking up the p2p refactor project (https://github.com/bitcoin/bitcoin/projects/4). I think it makes sense for him to have write access so he can update that board. Due to github permissions, that would also allow give him write access to do things like tag and close issues. It would *not* give him commit permissions.
< jnewbery> any objections?
< wumpus> no, sgtm
< gkrizek> I updated #15255 with MarcoFalke 's suggestions if anyone cares to take another look.
< gribble> https://github.com/bitcoin/bitcoin/issues/15255 | [tests] Remove travis_wait from lint script by gkrizek · Pull Request #15255 · bitcoin/bitcoin · GitHub
< provoostenator> Would be nice to get this one line documentation change in: #13676
< gribble> https://github.com/bitcoin/bitcoin/issues/13676 | Explain that mempool memory is added to -dbcache by Sjors · Pull Request #13676 · bitcoin/bitcoin · GitHub
< luke-jr> wumpus: I don't see a PR? (nor ML discussion, but maybe the subject is just non-obvious?)
< wumpus> luke-jr: sure, I can make a PR, but though that'd only make sense if there is a bip number
< luke-jr> BIP 2 put PR before number assignment
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b853746d4a8a...a83aedca1889
< bitcoin-git> bitcoin/master 7cb1a14 Sjors Provoost: Explain that unused mempool memory is added to -dbcache
< bitcoin-git> bitcoin/master a83aedc Wladimir J. van der Laan: Merge #13676: Explain that mempool memory is added to -dbcache
< bitcoin-git> [bitcoin] laanwj merged pull request #13676: Explain that mempool memory is added to -dbcache (master...2018/07/dbcache-ibd-mempool) https://github.com/bitcoin/bitcoin/pull/13676
< wumpus> luke-jr: ok, thanks
< promag_> no meeting?
< * luke-jr> meets with promag_
< jnewbery> hi
< jamesob> I think it was done earlier due to a conf-related timezone shift?
< kanzure> hi
< promag_> luke-jr: o/
< achow101> jamesob: no?
< moneyball> oh?
< achow101> \me performs the wumpus summoning ritual
< jamesob> nvm I'm full of it probably
< luke-jr> XD
< jnewbery> #action hunt the wumpus
< kanzure> wumpus is an endangered species and we probably shouldn't hunt to extinction
< promag_> anyway bbl
< luke-jr> promag_: ⁈
< luke-jr> ok, let's all discuss promag_'s PRs behind his back
< MarcoFalke> Let's start by proposing topics
< MarcoFalke> s/start/wait/
< * sipa> half online from FC19
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Feb 21 19:06:25 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< wumpus> sorry
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb
< MarcoFalke> heh, I don't think there is much to discuss anyway?
< moneyball> no proposed topics during the week
< gmaxwell> HI
< MarcoFalke> Has anyone seen issues after the feature freeze that are not related to emojis?
< promag_> I'll submit a couple of fixes for 0.18, then help achow101 on create wallet, cheers
< moneyball> and congrats to everyone for completing feature freeze!
< promag_> emojis ^
< wumpus> the good news is, we're very well on schedule; there's two PRs left to be merged for 0.18 #15402 #15401
< gribble> https://github.com/bitcoin/bitcoin/issues/15402 | Granular invalidateblock and RewindBlockIndex by sipa · Pull Request #15402 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/15401 | rpc: Actually throw help when passed invalid number of params by MarcoFalke · Pull Request #15401 · bitcoin/bitcoin · GitHub
< achow101> MarcoFalke: #15453. promag_ and I figured out it's a signalling order problem with qt 5.7.1
< gribble> https://github.com/bitcoin/bitcoin/issues/15453 | Starting bitcoin-qt with -nowallet and then opening a wallet does not show the wallet · Issue #15453 · bitcoin/bitcoin · GitHub
< MarcoFalke> oh, so not related to the filename?
< achow101> no
< achow101> well there's that too I think
< achow101> (different issue)
< wumpus> please let me know if anything needs tagging for 0.18
< kanzure> hi
< luke-jr> <.<
< wumpus> that's a short meeting I guess
< wumpus> no topics, nothing to discuss for 0.18 ?
< jnewbery> I imagine the same will be true for a wallet meeting tomorrow. Do we want to postpone that until next week?
< wumpus> please help reviewing the last PRs then
< moneyball> it gives developers time to do some extra reviews such as the PRs gmaxwell referred to earlier today
< wumpus> so the aim for the 0.18 branch split-off is 2019-03-01, I guess we're going to make it this time :)
< wumpus> yes, gmaxwell mentioned some secp256k1 PRs that need reviewing
< luke-jr> [12:21:31] <gmaxwell> If anyone is getting bored waiting for 0.18 to ship to get moving on other work… libsecp256k1 has a couple PRs that could just use some C code review:
< luke-jr> [12:21:34] <gmaxwell> in particular: https://github.com/bitcoin-core/secp256k1/pull/578
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Feb 21 19:16:34 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jnewbery> meshcollider: any thoughts about postponing wallet meeting to next week?
< gmaxwell> It isn't critical, but I've been trying to catch up the enormous backlog of PRs on libsecp256k1. (I merged ~11 PRs yesturday). What I asked about in here were ones probably anyone in here could give a useful review to...
< gmaxwell> I'm trying to get all the small improvements that were sitting around merged so as only to cause ~1 rebase cycle for the other inflight more significant pieces of code. (e.g. schnorr signatures)
< luke-jr> ah, not crypto-heavy
< wumpus> no, some build system and refactoring
< wumpus> some of it is very scary though
< jnewbery> I have one other announcement: we're closing applications to the residency on Sunday. We've found that some of our best applicants have been referrals, so if you know anyone who you think would be a good Bitcoin contributor, please send them our way! https://residency.chaincode.com
< gmaxwell> mostly because I already merged all the stuff that was trivial. :P
< luke-jr> gmaxwell: unrelated to the PR itself, shouldn't there be checks that pos isn't beyond the end of input here? https://github.com/bitcoin-core/secp256k1/pull/578/files#diff-894075824bb67186a1d4e4cc3961644eR57
< luke-jr> or is this assuming some degree of well-formed input?
< gmaxwell> it certantly should not be assuming well-formed input.
< gmaxwell> well to be clear, earlier code in the function probably checks a minimum size.
< luke-jr> am I missing where it gets checked? hopefully I'm not leaving incorrect review comments :x
< gmaxwell> so if thats what you meant by assuming some degree of well formed, that could be the case.
< gmaxwell> luke-jr: your thought that its missing a check looks correct to me.
< gmaxwell> there is a check before each prior one, but I don't see a check after that last postincrement.
< gmaxwell> thought IIRC there is a pretty good fuzzing based tester for that function, so I'm surprised that if its got a bug there it hasn't been noticed.
< meshcollider> jnewbery: postponing tomorrows wallet meeting sounds sensible yep
< wumpus> what caused the lack of interest in the meting ? is there anything special this week?
< sipa> wumpus: number of people at financial crypto
< sipa> (BlueMatt, sdaftuar, cfields_, me, ...)
< sipa> after this week i have no travel plans for a few months
< wumpus> right! thanks
< jamesob> "i have no travel plans for a few months" bet you're excited sipa
< dongcarl> jonasschnelli: Any thoughts on this: https://github.com/bitcoin/bitcoin/pull/8888#issuecomment-457003118, I might remove #8888 from the board since it's really old (but has a very lucky issue number!)
< gribble> https://github.com/bitcoin/bitcoin/issues/8888 | CConnman: Remove some global usage in the gui by theuni · Pull Request #8888 · bitcoin/bitcoin · GitHub
< jonasschnelli> sry. missed the meeting
< wumpus> heh it wasn't much anyway
< jonasschnelli> just saw that it was pretty short...
< jonasschnelli> dongcarl: no real thoughts on that. But I think it would be nice if you pick it up
< dongcarl> Cool
< dongcarl> I'm seeking context on libevent in bitcoin
< dongcarl> it seems that for the node, we had select only, then pstrateman implemented poll
< dongcarl> I see that libevent is being pulled in as a dependency for the RPC server as well
< dongcarl> But #11227 for node socket handling wasn't completed.
< gribble> https://github.com/bitcoin/bitcoin/issues/11227 | WIP: switch to libevent for node socket handling by theuni · Pull Request #11227 · bitcoin/bitcoin · GitHub
< dongcarl> Do people still think this is valuable/worth doing?
< jamesob> dongcarl: my impression is that (i) long-term we'd like to use libevent in lieu of poll() but (ii) it will require more substantial net refactoring and (iii) there are probably additional considerations around the use of another external library for something so critical - e.g. might be prudent to maintain our own fork a la leveldb
< jamesob> AFAIK poll() was a sort of mid-state along the way to libevent that didn't require as much code churn
< dongcarl> jamesob: Right, that makes a lot of sense.
< dongcarl> Poor BSD folks, no kqueue for so long
< jamesob> better than a broken kqueue implementation *cough*Darwin*cough* :)
< dongcarl> lol
< dongcarl> I remember hearing about libev used somewhere in bitcoin
< dongcarl> But I might be imagining things
< dongcarl> Nothing in issues or PR, must be from my dreams
< jarthur> There are some non-Core softwares out there that use it. cbitcoin and libbitc
< dongcarl> jarthur: libev you mean?
< jarthur> yes
< dongcarl> Right, from skimming the two libraries I think libev is probably more minimal and (supposedly) better designed, but it'd be another depedency :-/
< jamesob> dongcarl: confusingly there's also "libuv" (which looks way too bloated for us)
< dongcarl> jamesob: Yeah. I want to try out libev. It actually has a "libevent emulation layer" which might be a good step to switching.
< dongcarl> According to http://libev.schmorp.de/bench.html you just switch out the header file