< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18730: wallet: Remove -upgradewallet from dummywallet (master...2004-walletNoUpgrade) https://github.com/bitcoin/bitcoin/pull/18730
< bitcoin-git>
[bitcoin] luke-jr opened pull request #18729: GUI/Intro: Never change the prune checkbox after the user has touched it (master...intro_dont_change_user_prune) https://github.com/bitcoin/bitcoin/pull/18729
< bitcoin-git>
[bitcoin] luke-jr opened pull request #18728: GUI: Enable changing the autoprune block space size in intro dialog (master...intro_prune_size) https://github.com/bitcoin/bitcoin/pull/18728
< bitcoin-git>
[bitcoin] fanquake closed pull request #18716: Hard forking Bitcoin Core for New Bitcoin UNV Crypto asset (master...0.20) https://github.com/bitcoin/bitcoin/pull/18716
< bitcoin-git>
[bitcoin] CyberDevAi opened pull request #18716: Hard forking Bitcoin Core for New Bitcoin UNV Crypto asset (master...0.20) https://github.com/bitcoin/bitcoin/pull/18716
< bitcoin-git>
[bitcoin] fanquake opened pull request #18709: doc: note why we can't use thread_local with glibc back compat (master...document_thread_local_glibc) https://github.com/bitcoin/bitcoin/pull/18709
< bitcoin-git>
[bitcoin] meshcollider opened pull request #18700: Fix locking on WSL using flock instead of fcntl (master...202004_file_lock_windows) https://github.com/bitcoin/bitcoin/pull/18700
< yevaud>
simply, no version of Bitcoin before 0.8 was able to maintain consensus even between nodes of the same version. realistically there's no amount of increase in berkeleydb which can allow nodes to operate properly, and the number in that document is well, well below the value required even for the time.
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18692: test: Bump timeout in wallet_import_rescan (master...2004-qaBumpTimeout) https://github.com/bitcoin/bitcoin/pull/18692
< captjakk>
Currently the behavior of Bitcoin Core in a pruned state is to return an RPC error when a block is requested that has been pruned. I was thinking about working on a change that would allow Core to dynamically fetch a block it didn't have, and verify it against the retained headers. This ultimately implies a slight implementation change to the peer protocol, but at first glance this seems harmless and potentially very helpful
< bitcoin-git>
[bitcoin] jonatack opened pull request #18691: test: fix intermittent error in interface_bitcoin_cli (master...fix-intermittent-credentials-issue) https://github.com/bitcoin/bitcoin/pull/18691
< bitcoin-git>
[bitcoin] robot-visions opened pull request #18690: test: Check object hashes in wait_for_getdata (master...wait-for-getdata) https://github.com/bitcoin/bitcoin/pull/18690
< bitcoin-git>
[bitcoin] pierreN opened pull request #18689: rpc: allow dumptxoutset to dump human-readable data (master...feature-utxo-ascii) https://github.com/bitcoin/bitcoin/pull/18689
< wumpus>
agree, though 'as part of the bitcoin core project' is in one place, more or less, it doesn't necessarily mean one repository
< phantomcircuit>
sipa, ip<->asn lookup is definitely something that would be useful outside of bitcoin, i've tried myself to do it in the past but without an active bgp session it's basically impossible to get the map at all
< sipa>
so the process is (bgp dumps) -> mapping (currently, using gleb's rust tool); mapping -> asmap file (currently using some python scripts, or the bitcoin-asmap tool i'm adding in 18573)
< jb55>
if it was signed with the same key we're using for verifying bitcoin releases for instance
< sipa>
it's a binary blob you can load into bitcoin core that affects how it selects outgoing peers and prioritizes incoming connections
< jb55>
sipa: is there a writeup about the asmap stuff somewhere? what's problems its trying to solve, how and why I need to generate those files, etc. as one of the people who maintains the bitcoin package on nixos, would I need to generate that and package it for users, etc?
< sipa>
my fuzz test right now generates random inputs to the encoder function used by bitcoin-asmap directly
< luke-jr>
if bitcoin-asmap is available, we can use it for tests too, but still separate from the main repo
< sipa>
luke-jr: i think the primary advantage is that it allows testing/fuzzing the encoder together with the exact code bitcoin core is using for lookups
< wumpus>
sipa: we've intentionally kept all kinds of developer tools in bitcoin-maintainer-tools repo instead, but if you think this is something a lot of users are going to need we could ship it with bitcoin core itself sure
< sipa>
i have #18573 that adds a binary for constructing/decoding these map files, which is an approach i like, but perhaps it's better to keep this out of bitcoin core's scope for now, unsure
< sipa>
for the wallet<->node communication my big hope was that the protocol would be Bitcoin P2P, so that it can be substituted with whatever on either side... but it doesn't seem anyone's working on that
< wumpus>
tryphe: if that's your concern, encrypt the entire wallet file or store it on an encrypted file system, it's not something bitcoin core's wallet encyrption solves
< wumpus>
tryphe: I think that's unrelated; wallet encryption in bitcoin core only protects private keys, nothing more. Labels and such are not part of that either and should definitely be kept.
< bitcoin-git>
[bitcoin] jnewbery opened pull request #18675: tests: Don't initialize PrecomputedTransactionData in txvalidationcache tests (master...2020-04-precomputedtransactiondata-txvalidationcache) https://github.com/bitcoin/bitcoin/pull/18675
< gribble>
https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] theStack opened pull request #18672: test: add further BIP37 size limit checks to p2p_filter.py (master...20200416-test-add-further-bloom-filter-size-limit-checks) https://github.com/bitcoin/bitcoin/pull/18672
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17669: tests: have coins simulation test also use CCoinsViewDB (master...2019-12-coins-tests) https://github.com/bitcoin/bitcoin/pull/17669
< bitcoin-git>
bitcoin/master bee88b8 James O'Beirne: tests: have coins simulation test also use CCoinsViewDB
< bitcoin-git>
bitcoin/master d8dfcea MarcoFalke: Merge #17669: tests: have coins simulation test also use CCoinsViewDB
< bitcoin-git>
[bitcoin] hebasto opened pull request #18665: Do not expose -logthreadnames when it does not work (master...200416-logthreads) https://github.com/bitcoin/bitcoin/pull/18665
< bitcoin-git>
[bitcoin] meshcollider closed pull request #18572: Wallet: Accept "changedata" db key as an alias to "destdata" (master...changedata_forwardcompat) https://github.com/bitcoin/bitcoin/pull/18572
< bitcoin-git>
[bitcoin] meshcollider closed pull request #18550: Store destdata for change in separate key for backward compatibility (master...changedata) https://github.com/bitcoin/bitcoin/pull/18550
< gribble>
https://github.com/bitcoin/bitcoin/issues/18550 | Store destdata for change in separate key for backward compatibility by luke-jr · Pull Request #18550 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] saahilshangle opened pull request #18663: doc: Adding hyperlink to INSTALL.md in README.md (master...readme-build-instructions) https://github.com/bitcoin/bitcoin/pull/18663
2020-04-15
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18662: refactor: Replace gArgs with local argsman in all utility tools (master...2004-toolsArgsman) https://github.com/bitcoin/bitcoin/pull/18662
< elichai2>
and if I understand correctly Google will actually pay you if you integrate into oss-fuzz https://github.com/bitcoin-core/secp256k1/issues/739 "We want to stress that anyone who meets the eligibility criteria and integrates a project with OSS-Fuzz is eligible for a reward."
< BlueMatt>
well by the time you've done that much work you might as well run it on our own hardware (without the aggressive public-disclosure timelines that may put bitcoin users at risk...)
< elichai2>
I have my own PC dedicated for profiling benchmarking, trying different system wide changes to Bitcoin Core
< BlueMatt>
a few bitcoin groups gave them some funds afaiu
< BlueMatt>
(as a reminder: lots of cpu cores are available in a few locations for those doing bitcoin open source work)
< BlueMatt>
elichai2: also note that oss-fuzz primarily just provides cpu hours, it doesn't do any actual implementation work for you, and getting access to a few hundred cores for bitcoin core fuzzing is rather easy :p
< bitcoin-git>
[bitcoin] practicalswift closed pull request #18657: chain: Do not fill out parameters in findCommonAncestor(...) if ancestor is not found (master...out-parameters-in-findCommonAncestor) https://github.com/bitcoin/bitcoin/pull/18657
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18645: [doc] Update thread information in developer docs (master...2020-04-doc-threads) https://github.com/bitcoin/bitcoin/pull/18645