< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18509: fuzz: Avoid running over all inputs after merging them (master...2004-fuzzMergeOnce) https://github.com/bitcoin/bitcoin/pull/18509
< achow101>
is it intentional that a new default wallet cannot be created when running with -nowallet?
< luke-jr>
achow101: afaik -nowallet currently emulates a build w/o wallet support
< achow101>
you can make and add new wallets even when -nowallet
< achow101>
I think this is just a bug because who would want to make a wallet with no name
< jonatack>
fanquake: see the edit message, "Removed "macOS does not yet support dark mode". I believe it does since at least 10.14.6 and Apple is aggressive in pushing updates. Feel free to revert/update if I'm wrong."
< jonatack>
fanquake: also added release notes for the removal of the deprecated totalFee arg from rpc bumpfee, for rpc getpeerinfo now including "mapped_as" (mapped Asynchronous System) used for diversifying peer networking, and GUI Peers window now showing "Mapped AS" for the same.
< fanquake>
jonatack: it doesn’t support dark mode, and we explicitly opt out. Don’t think qt 5.9 supports dark mode in any case.
< jonatack>
fanquake: thanks. i found the release notes surprising this time aroun, as i have an old 2012 macbook pro running a node on mojave 10.14.6 and qt 5.14.1 and dark mode looks good (not like in 14593). perhaps we should mention what versions of qt or macOS do/don't work
< fanquake>
jonatack: that's expected. If you're self compiling, and just running src/qt/bitcoin-qt, it will work. If you run deploy and use the app bundle (as releases are built) it wont.
< fanquake>
I don't think we need to mention anything more in the readme, as releases are not affected.
< jonatack>
fanquake: it says: "Additionally, Bitcoin Core does not yet change appearance when macOS "dark mode" is activated." -> what say you to appending ", except if compiling from source." or similar, for dummies like me :)
< jonatack>
(done, reverted the removal)
< bitcoin-git>
[bitcoin] fanquake opened pull request #18514: test: remove rapidcheck integration and tests (master...remove_rapidcheck) https://github.com/bitcoin/bitcoin/pull/18514
< bitcoin-git>
[bitcoin] Christewart closed pull request #14430: Add more property based tests for basic bitcoin data structures (master...add_tests_from_8469) https://github.com/bitcoin/bitcoin/pull/14430
< bitcoin-git>
[bitcoin] fanquake closed pull request #14694: tests: Separately check for rapidcheck/boost_test.h in configure (master...rapidcheck-boost-test) https://github.com/bitcoin/bitcoin/pull/14694
< instagibbs>
provoostenator, change detection is not a "can I sign this" question, that's a "can I understand what's mine" question
< instagibbs>
if the signer sees additional outputs going to stuff the wallet doesn't recognise/user has to look up, what's the damage
< instagibbs>
As long as the user is prompted with useful information, I don't see what issue "eager" signing causes.
< bitcoin-git>
[bitcoin] theStack opened pull request #18515: test: add BIP37 remote crash bug [CVE-2013-5700] test to p2p_filter.py (master...20200403-test-check-for-CVE20135700-vuln-in-bip37-tests) https://github.com/bitcoin/bitcoin/pull/18515
< gleb>
I just hanged the process (it's stuck for minutes) by sending SIGINT multiple times during "FlushStateToDisk: write coins cache". Is this expected? :)
< vasild>
What is it doing?
< gleb>
It's just stuck with that line being last in the logs forever. I then used "kill -9" to kill the process.
< vasild>
SIGINT would cause StartShutdown() to be called which only sets a boolean fRequestShutdown to true. Shouldn't cause issues if executed multiple times.
< vasild>
If its possible to reproduce then maybe try to attach gdb and see what it is doing.
< gleb>
I was more generally curious, if I see something like this, is it a worthy bug looking at? I don't have an intuition about the expectations in a case like this. If it is, I'll try to reproduce and take a closer look.
< vasild>
maybe some of the writes or flushes being executed gets interrupted due to the (second) signal arrival and the code mishandles that?
< vasild>
Any hang looks like a (serious) bug to me. In a sense maybe even worse than a crash because in a crash the user or some automated system can detect it and start it again.
< wumpus>
it's worth reporting though if it's not easy to reproduce, *please* add information, such as where in the code it hangs (e.g. gdb output)
< wumpus>
always get a backtrace when there's a hang
< bitcoin-git>
[bitcoin] jonatack opened pull request #18516: test: relax bumpfee dust_to_fee txsize an extra vbyte (master...relax-dust_to_fee-test) https://github.com/bitcoin/bitcoin/pull/18516
< bitcoin-git>
bitcoin/master fab3255 MarcoFalke: rpc: Make rpc documentation not depend on rpc args
< bitcoin-git>
bitcoin/master c897154 MarcoFalke: Merge #18499: rpc: Make rpc documentation not depend on call-time rpc args...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18499: rpc: Make rpc documentation not depend on call-time rpc args (master...2004-rpcStaticDoc) https://github.com/bitcoin/bitcoin/pull/18499
< bitcoin-git>
[bitcoin] theStack opened pull request #18520: test: remaining replacements of (send_message+sync_with_ping) with send_and_ping (master...20200403-test-remaining-send_and_ping-substitutes) https://github.com/bitcoin/bitcoin/pull/18520
< fjahr>
Just repeating it here in case someone is missing it on Twitter: there are fishing emails going around seemingly targeting email addresses from Github commits, made to look like official emails from Github. At least some of them seem to get around spam filters. Some topics I got: "Activate your account", "Accept Terms of Service change", "Complete your profile" etc.
< sipa>
fjahr: i just got a "File has been modified from your private repository"
< jonatack>
same. strange sender address was the tip-off: "Support Github app71076620@skydropx.com via sendgrid.me". stay alert.
< gwillen>
jonatack: if you have one of those in your inbox, and it appears to be genuinely coming via sendgrid, you should forward it to their abuse address
< gwillen>
so they can take out the sender's account
< gwillen>
I'm not consistent about reporting stuff like this because there's just too much of it, but if it's worth a warning it's probably worth a report