< luke-jr> NicolasDorier: stop using Windows kthx
< luke-jr> test/functional/p2p_permissions.py is missing +x
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/7d6f63cc2c2b...6519be605480
< bitcoin-git> bitcoin/master 9b92538 Matt Corallo: Remove unused fScriptChecks parameter from CheckInputs
< bitcoin-git> bitcoin/master 6519be6 fanquake: Merge #13868: Remove unused fScriptChecks parameter from CheckInputs
< bitcoin-git> [bitcoin] fanquake merged pull request #13868: Remove unused fScriptChecks parameter from CheckInputs (master...check-inputs-script-checks) https://github.com/bitcoin/bitcoin/pull/13868
< wumpus> emilengler: fanquake: done
< fanquake> wumpus: thanks
< meshcollider> sipa: Q about the bech32 code in bitcoin. Shouldn't the encode function error if the HRP it is given is capitalised?
< meshcollider> i think encoding currently just uses it as-is which means the checksum it creates will be over a mixed case address and will always be invalid, even if you manually change capitalisation afterwards
< meshcollider> Compare with the C implementation which explicitly checks this https://github.com/sipa/bech32/blob/master/ref/c/segwit_addr.c#L59
< meshcollider> Just wanted to confirm with you before I PR
< meshcollider> the go implementation just converts to lowercase automatically
< bitcoin-git> [bitcoin] darosior opened pull request #16787: Human readable network services (master...services_for_humans) https://github.com/bitcoin/bitcoin/pull/16787
< bitcoin-git> [bitcoin] meshcollider pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/6519be605480...33f9750b1b86
< bitcoin-git> bitcoin/master 7f3bb24 darosior: gettransaction: add an argument to decode the transaction
< bitcoin-git> bitcoin/master b8b3f04 darosior: tests: Add a new functional test for gettransaction
< bitcoin-git> bitcoin/master 9965940 darosior: doc: Add release note for the new gettransaction argument
< bitcoin-git> [bitcoin] meshcollider merged pull request #16185: gettransaction: add an argument to decode the transaction (master...decode_tx_gettransaction) https://github.com/bitcoin/bitcoin/pull/16185
< bitcoin-git> [bitcoin] laanwj opened pull request #16788: gui: Update transifex slug for 0.19 (master...2019_10_tx_slug_0_19) https://github.com/bitcoin/bitcoin/pull/16788
< emilengler> wumpus: You meant the ban for the spammer? if so, thanks
< bitcoin-git> [bitcoin] GChuf opened pull request #16789: Update headers and copyright_header.py script (master...headers) https://github.com/bitcoin/bitcoin/pull/16789
< bitcoin-git> [bitcoin] HashUnlimited opened pull request #16790: break loop early on undefined version bits (master...patch-4) https://github.com/bitcoin/bitcoin/pull/16790
< bitcoin-git> [bitcoin] HashUnlimited closed pull request #16790: break loop early on undefined version bits (master...patch-4) https://github.com/bitcoin/bitcoin/pull/16790
< warren> wumpus: everything good with the transifex account now?
< bitcoin-git> [bitcoin] fanquake closed pull request #16789: Update headers and copyright_header.py script (master...headers) https://github.com/bitcoin/bitcoin/pull/16789
< elichai2> Playing a bit with clangs `-flto=thin` and first the binaries are down from ~220-280mb to 16-30mb. curious to see if there are also any speed imporvements
< sipa> elichai2: compared to what?
< sipa> that kind of difference sounds more like you disabled or removed debug symbols
< sipa> lto can have a bit of an impact on binary size, but nlt
< sipa> lto can have a bit of an impact on binary size, but not that much
< elichai2> sipa: the only difference is gcc vs clang+lto, might be the different compiler, but other than that didn't change anything
< sipa> my non-lto bitcoind is 6 MB btw, after stripping debug symbols
< elichai2> didn't touch the file, i'll try stripping in both cases, and try to stick to clang for with and without
< elichai2> altough i'm explictly doing `--disable-debug` and manually setting CFLAGS and CXXFLAGS so in theory there shouldn't be really any debug symbols (no `-g`)
< elichai2> after stripping them both you're right, there is no meaningful difference, but without striping there's a big difference, not sure why
< sipa> poasibly because the debug symbol generation for lto is broken/incomplete :p
< warren> IMO building with debug symbols and stripping before distribution is superior to building without debug symbols. This is because gdb lets you run the stripped binary while looking at the unstripped put in an optional directory to the side if you need to debug.
< midnightmagic> What warren said. Although at least in the past this could cause performance issues in rare cases.
< midnightmagic> Plus with a stripped binary you can rebuild with the same build env and recreate an image which can be used to debug coredumps from stripped bins. Which is pretty neat.