< fanquake> Hopefully no-one has to clean any toilets.. https://github.com/bitcoin/bitcoin/pull/16248#issuecomment-510831024
< bitcoin-git> [bitcoin] Sjors opened pull request #16377: [rpc] don't automatically append inputs in walletcreatefundedpsbt (master...2019/07/walletcreatefundedpsbt_addinputs) https://github.com/bitcoin/bitcoin/pull/16377
< bitcoin-git> [bitcoin] Sjors opened pull request #16378: [WIP] The ultimate send RPC (master...2019/07/send) https://github.com/bitcoin/bitcoin/pull/16378
< sdaftuar> if we're making a regular outbound connection and our peer has fRelayTxes=false when we connect (ie because that node is running in -blocksonly mode, i'm guessing?) should we disconnect?
< sdaftuar> now that -blocksonly is not a hidden option, i think we should probably do something to ensure we have sufficient tx-relay peers
< sdaftuar> opinions?
< jamesob> sounds reasonable to me. I'd say this would be especially important if we're more lenient with fRelayTxes=false peers re: eviction based on some kind of inactivity ("I haven't received an INV from this peer in n minutes") but I don't think that's the case at the moment
< jamesob> the rationale being that it'd take fewer resources to sybil broadly with a bunch of -blocksonly nodes, but again I don't think that's the case atm
< sdaftuar> i don't think there's a partition risk introduced by this, i'm more thinking that we have no protections in our code against our 8 regular outbounds all being run in -blocksonly mode and so there's an edge case where we are surprised to not receive transactions at all
< sdaftuar> i'm not sure how much transaction-relaying peers is sufficient, but it'd be easy to detect a blocksonly peer when we're looking for a regular peer and just disconnect, i think. might be too heavy-handed though?
< jamesob> is ensuring some min ratio of regular peers too special casey?
< sdaftuar> well, there are only 9 values to choose from when it comes to the number of blocksonly peers you'd tolerate as a "regular" outbound, so i think we can just pick where to set that threshold :)
< sdaftuar> (i don't think we should include inbounds in that calculation)
< gleb> hi
< gleb> sdaftuar: Why there is no explicit p2p message when "fRelayTxes=false"?
< sdaftuar> it's a hack -- we use a bit added to version messages when bip37 was rolled out to communicate that we don't want to enable transaction relay
< gleb> So why we don't want to keep using this bit when identifying a fRelayTxes=false on other side?
< sdaftuar> because bip37 allows for transaction relay to be re-enabled later in the connection's lifetime
< sdaftuar> i'm not sure whether bip37 support is currently default on or off right now in our software, but we should do something more explicit for blocksonly connections in the future, i think.
< gleb> Oh, I See. So something like an explicit message? :)
< sdaftuar> yes
< lightlike> sdaftuar: looks like bip37 support is on per default, but will possibly be disabled if #16152 is merged
< gribble> https://github.com/bitcoin/bitcoin/issues/16152 | Disable bloom filtering by default. by TheBlueMatt · Pull Request #16152 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] hebasto opened pull request #16379: Fix autostart filenames Linux for testnet/regtest (master...20190712-fix-autostart) https://github.com/bitcoin/bitcoin/pull/16379
< BlueMatt> seems like something that should just get merged :)
< bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/735d6b57e795...3453cf26dbaf
< bitcoin-git> bitcoin/master 3e80ec3 Carl Dong: contrib: Add deterministic Guix builds.
< bitcoin-git> bitcoin/master 8dff3e4 Carl Dong: contrib: guix: Clarify SOURCE_DATE_EPOCH.
< bitcoin-git> bitcoin/master cd3e947 Carl Dong: contrib: guix: Various improvements.
< bitcoin-git> [bitcoin] laanwj closed pull request #16310: refactor: small optimization for IsHex method (master...master) https://github.com/bitcoin/bitcoin/pull/16310
< bitcoin-git> [bitcoin] laanwj merged pull request #15277: contrib: Enable building in Guix containers (master...2019-01-guix) https://github.com/bitcoin/bitcoin/pull/15277
< instagibbs> BlueMatt, marked "waiting for author" for some reason....
< achow101> so are we now using guix for deterministic builds instead of gitian?
< BlueMatt> instagibbs: dunno why?
< BlueMatt> looks fine to me
< instagibbs> Marco said stuff in his ACK, but you need to say "Shove it" and he'll merge
< instagibbs> ;)
< BlueMatt> right, I dont know that the release note categories are
< instagibbs> achow101, https://github.com/bitcoin/bitcoin/tree/master/contrib/guix looks like you're supposed ot be able to use it
< dongcarl> achow101: This section was written specifically for you: https://github.com/bitcoin/bitcoin/tree/master/contrib/guix#speeding-up-builds-with-substitute-servers
< dongcarl> <3
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #16380: Remove unused bits from the service flags enum (master...1907-netRemoveUnusedServiceBits) https://github.com/bitcoin/bitcoin/pull/16380
< emilengler> Can someone help me? I'm currently stucking at a PR and I have no idea why the travis build is failing on the tests (https://travis-ci.org/bitcoin/bitcoin/jobs/557960750)
< MarcoFalke> Looks like a segfault in your code
< MarcoFalke> Run a getblockbyheight locally and you get the error
< wumpus> yea, 'waiting for author' just means 'author needs to reply', it doesn't mean that the author needs to do everything (including cleaning toilets) that the reviewers propose :p
< wumpus> it's fiine to say 'this is out of scope of this PR'
< MarcoFalke> A p2p network change is not a command line change
< wumpus> I'd even encourage that to make sure that progress is made and things don't get held up in a back-and-forth forever
< wumpus> MarcoFalke: definitely
< MarcoFalke> If there is feedback and multiple reviewers agree on it, it shouldn't be ignored
< MarcoFalke> If it was a whitespace nit or something, yeah maybe ignore it
< wumpus> it should never be *ignored*
< wumpus> saying 'no' is ok, ignorning not
< MarcoFalke> Agree
< MarcoFalke> Knowing the reason that some feedback has not been addressed gives helpful insights
< MarcoFalke> s/that/why/
< wumpus> I mean reviewers spend time in writing review comments so the least you can do is respond to it, with reasoning
< wumpus> right
< bitcoin-git> [bitcoin] laanwj pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/3453cf26dbaf...536590f358dc
< bitcoin-git> bitcoin/master 604e2a9 Carl Dong: test: rpc_users: Add function for auth'd requests.
< bitcoin-git> bitcoin/master c73d871 Carl Dong: test: rpc_users: Add function for testing auth params.
< bitcoin-git> bitcoin/master 830dc2d Carl Dong: test: rpc_users: Also test rpcauth.py with specified password.
< bitcoin-git> [bitcoin] laanwj merged pull request #16334: test: rpc_users: Also test rpcauth.py with password. (master...2019-07-rpcauth-passwd-specified-case) https://github.com/bitcoin/bitcoin/pull/16334
< emilengler> MarcoFalke, it works without any issues on my system (Debian Buster, amd64), thats really strange
< MarcoFalke> Oh, you might have to compile with --enable-debug
< MarcoFalke> ./configure --enable-debug
< MarcoFalke> if that doesn't help, run the server in valgrind and call the rpc again
< emilengler> Ok thanks
< midnightmagic> dongcarl: Any experience yet with non-arm/x86 hosts for guix..?
< emilengler> Is it normal that when you compile with --enable-debug bitcoind quits after one RPC command#
< emilengler> Nevermind, it is a problem of my code
< midnightmagic> the guix guy's gpg key is expired as of four days ago.
< midnightmagic> rsa4096/090B11993D9AEBB5 -> expired: 2019-07-08
< dongcarl> midnightmagic: Not really, I know MIPS is supported well
< dongcarl> I've been porting things to riscv64, but have only gotten it working as a build target
< dongcarl> midnightmagic: Try refreshing it
< dongcarl> you might have pulled it a few months ago
< dongcarl> he refreshes every few months I believe
< emilengler> Thanks to whoever has restarted the build ^^ :-)
< midnightmagic> dongcarl: no, I pulleld it literally minutes before I mentioned it in here..?
< midnightmagic> based on the install script suggestion for import anyway