< 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>
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`
< 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`
< 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
< 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?
< 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>
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.
< 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:
< 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>
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.
< 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.