< gribble>
https://github.com/bitcoin/bitcoin/issues/15622 | Remove globals: Avoid using the global namespace if possible by practicalswift · Pull Request #15622 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] crackercracked opened pull request #15812: not generate coverage report on test failures (master...fix-issue-15648-test-coverage-report) https://github.com/bitcoin/bitcoin/pull/15812
< meshcollider>
provoostenator is having IRC issues and can't send messages here atm but would like to point out he also has a slightly different (and perhaps less complete) PR open: https://github.com/bitcoin/bitcoin/pull/15487
< harding>
Wallet files are generally small. If you think a backup is important, it's probably better to just make one automatically and stuff it somewhere in ~/.bitcoin/
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15806: contrib: Remove SUSPICIOUS_HOSTS from makeseeds.py (master...remove-SUSPICIOUS_HOSTS) https://github.com/bitcoin/bitcoin/pull/15806
< bitcoin-git>
[bitcoin] practicalswift opened pull request #15805: log: Increase signal-to-noise in bitcoind standard output. Don't print debug output "Pre-allocating to position ..." and "Leaving block file ..." when running with -nodebug (default). (master...stdout-signal-to-noise) https://github.com/bitcoin/bitcoin/pull/15805
< bitcoin-git>
[bitcoin] meshcollider opened pull request #15803: [0.18] Backport 15749: importmulti only imports origin info for PKH outputs (0.18...201904_backport_15749) https://github.com/bitcoin/bitcoin/pull/15803
< bitcoin-git>
[bitcoin] JimmyMow opened pull request #15802: doc: create application support bitcoin folder (master...fix/macos-docs) https://github.com/bitcoin/bitcoin/pull/15802
2019-04-11
< bitcoin-git>
[bitcoin] luke-jr opened pull request #15801: Bugfix: GUI: Options: Initialise prune setting range before loading current value, and remove upper bound limit (master...bugfix_gui_prune_range) https://github.com/bitcoin/bitcoin/pull/15801
< wumpus>
the kind of CPUs that only run 32-bit don't really run bitcoin, you'd be better off with a rpi at that point
< bitcoin-git>
[bitcoin] jnewbery opened pull request #15800: [rpc] Remove the addresses field from the getaddressinfo return object (0.18...2019_04_remove_address_from_getaddressinfo_0.18) https://github.com/bitcoin/bitcoin/pull/15800
< gribble>
https://github.com/bitcoin/bitcoin/issues/12490 | [Wallet] [RPC] Remove deprecated wallet rpc features from bitcoin_server by jnewbery · Pull Request #12490 · bitcoin/bitcoin · GitHub
< gribble>
https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
< jnewbery>
I don't think it counts as controversial if some random drops in and says "NEVER CHANGE RPCS". If we let that stop useful changes to Bitcoin Core we'd never do anything.
< gribble>
https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
< luke-jr>
gmaxwell: UPnP might be generic enough that non-Bitcoin devs are interested too
< wumpus>
I really don't know, like if you and sipa are 100% against including rust in bitcoin core, it's a done deal I guess
< wumpus>
a lot of the boilerplate we're introducing in bitcoin for queues, asyn handling,et c is simply part of rust already
< gmaxwell>
I am skeptical also about this motivation about structurally elimiating bugs, when development in bitcoin core continues to _introduce_ bug in the form of things like memory-unbounded asynchronous layers.
< sipa>
wumpus: i realize that; but bitcoin core is a c++ project with c++ reviewers
< wumpus>
sipa: yes, maybe it means I need to move to rust-bitcoin :-)
< sipa>
but i have no interest in seeing bitcoin core becoming developed in a mix of languages
< instagibbs>
you'd want to ping #rust-bitcoin folks
< luke-jr>
anyway, CRust.. I don't think including Rust inside Bitcoin Core is a good idea, even optionally, so long as Rust requires trusting third party binaries
< cfields_>
See #15798, lots of useful info there. tl;dr: This is a cool project from Jeremy Rubin that allows us to use rust code from inside of Bitcoin Core. No plan yet, I mostly just wanted to spread the word that people should try it out and report back. It pretty much just works. It is surprisingly complete, but has only been tested in a few environments so far.
< gribble>
https://github.com/bitcoin/bitcoin/issues/15750 | [rpc] Remove the addresses field from the getaddressinfo return object by jnewbery · Pull Request #15750 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] instagibbs opened pull request #15796: CReserveKey should not allow passive key re-use, KeepKey in destructor (master...burn_reserve) https://github.com/bitcoin/bitcoin/pull/15796
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15795: scripted-diff: Avoid name collisions in CChainState (master...1904-m_chain) https://github.com/bitcoin/bitcoin/pull/15795
< bitcoin-git>
bitcoin/master fbc6bb8 Russell Yanofsky: bitcoin-wallet tool: Drop MakeChain calls
< bitcoin-git>
bitcoin/master b874747 Russell Yanofsky: Remove access to node globals from wallet-linked code
< bitcoin-git>
bitcoin/master 78a2fb5 Russell Yanofsky: bitcoin-wallet tool: Drop libbitcoin_server.a dependency
< emilr>
most connections timeout at version handshake, takes about 10s for verack plus network latency, if bitcoin tor nodes run with the default timeout then you're out of luck
< jonasschnelli>
Using obfuscation key for /btc/data/bitcoin/blocks/index: 0000000000000000
< wumpus>
it does not relate to bip38 in any way; if anything, most people involved with bitcoin dev really dislike bip38 and it's per-key encryption
< kallewoof>
Does the encryptwallet feature in bitcoin core relate to bip 38 in any way, or do they just look similar? It looks like it is basically doing the same thing but with scrypt replaced.
< emilr>
I'll increase -timeout and wipe peers.dat to see if it makes much of a difference, I guess bitcoin needs to be more agressive when it has a limited number of peers
< emilr>
gmaxwell: I was under the impression it would fetch all peers regardless of net but it did indeed discover some peers, I see 190 different .onions in two weeks, I think what happened is that bitcoin gave up on a lot of those peers after few failures but failure to connect is a normality in the tor land
< emilr>
onlynet=onion and bitcoin user is blocked from making connections to the clearnet
< emilr>
wumpus: sed -e 's|./bitcoin-cli|ANYTHING -you -want|g' banlist.cli.txt
< emilr>
speaking of seeds/peers I have bitcoin running in an isolated environment: it can't connect to anything except .onions and it has some peers added with addnode, the behaviour that I'm seeing is that bitcoind does not learn about other peers from its existing ones, possibly because dns seeds fail, the expected behaviour is that bitcoin learns about other peers from it's existing ones (the ones
< wumpus>
(it could still default to ./bitcoin-cli ofc)
< wumpus>
gmaxwell: for me it would be convenient if banlist.cli.txt had ${BITCOIN_CLI} or something on every line instead of ./bitcoin-cli, and allowed it to be overridden, for example to point to a custom bitcoin-cli path or providing a -datadir/-conf argument
< dongcarl>
gmaxwell: oh like connects to a bitcoin node and briefly get some other peers we can connect to from it then say bye?
< dongcarl>
Oh I'm guessing the last time you tried to remove this, bitcoin only had support for SOCK4 and couldn't resolve thru the normal proxy?
2019-04-10
< jnewbery>
Error! Initial build successful, but not enough time remains to run later build stages and tests. Please manually re-run this job by using the travis restart button or asking a bitcoin maintainer to restart. The next run should not time out because the build cache has been saved.
< bitcoin-git>
[bitcoin] jnewbery reopened pull request #15778: [wallet] Move maxtxfee from node to wallet (master...remove_maxtxfeerate_from_node) https://github.com/bitcoin/bitcoin/pull/15778
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15788: test: Unify testing setups for fuzz, bench, and unit tests (master...1904-testUnify) https://github.com/bitcoin/bitcoin/pull/15788
< bitcoin-git>
[bitcoin] jnewbery closed pull request #15778: [wallet] Move maxtxfee from node to wallet (master...remove_maxtxfeerate_from_node) https://github.com/bitcoin/bitcoin/pull/15778
< bitcoin-git>
bitcoin/master fa07898 MarcoFalke: test: Properly log named args in authproxy
< bitcoin-git>
bitcoin/master f3ecf30 MarcoFalke: Merge #15772: test: Properly log named args in authproxy
< tryphe>
luke-jr, i see, that makes sense. but i got the knack that bitcoin devs earned come income from donations somehow or some sort of community funding. not so?
< luke-jr>
tryphe: Bitcoin Core is an open source project many different people contribute to; there's no centralised entity accepting/distributing donations on everyone's behalf
< tryphe>
luke-jr, so where are the real bitcoin core donation addresses?
< luke-jr>
tryphe: either way, it's bitcoin.org you want to report any issues to
< luke-jr>
tryphe: that one is to support bitcoin.org, again not related to Bitcoin Core
< luke-jr>
tryphe: eh, the link doesn't say it's to donate to Bitcoin or Bitcoin Core
< bitcoin-git>
[bitcoin] MeshCollider merged pull request #15749: Fix: importmulti only imports origin info for PKH outputs (master...201904_importallorigins) https://github.com/bitcoin/bitcoin/pull/15749