< bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/12a1c3ad1a43...0b2abaa666d6
< bitcoin-git> bitcoin/master 1d3ec2a Pieter Wuille: Support bypassing range check in ReadCompactSize
< bitcoin-git> bitcoin/master 201a459 Vasil Dimov: net: CAddress & CAddrMan: (un)serialize as ADDRv2
< bitcoin-git> bitcoin/master 353a3fd Vasil Dimov: net: advertise support for ADDRv2 via new message
< bitcoin-git> [bitcoin] fanquake merged pull request #19954: Complete the BIP155 implementation and upgrade to TORv3 (master...torv3) https://github.com/bitcoin/bitcoin/pull/19954
< luke-jr> sigh, spent a few hours debugging #20118 only to find it's because the fix in #5872 I did years ago never got merged -.-
< gribble> https://github.com/bitcoin/bitcoin/issues/20118 | BITCOIN_SUBDIR_TO_INCLUDE no longer works · Issue #20118 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/5872 | configure: BITCOIN_SUBDIR_TO_INCLUDE: Improve compatibility with paths including space and multiline cpp output by luke-jr · Pull Request #5872 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] sipa opened pull request #20119: BIP155 follow-ups (master...202010_bip155_followup) https://github.com/bitcoin/bitcoin/pull/20119
< bitcoin-git> [bitcoin] jonatack opened pull request #20120: rpc, bugfix: filter networks with empty names from getnetworkinfo (master...fix-getnetworkinfo-empty-networks) https://github.com/bitcoin/bitcoin/pull/20120
< michaelfolkson> Any way of resurrecting the part of #5872 you need luke-jr? Looks like #9946 (merged) attempted to address same issue
< gribble> https://github.com/bitcoin/bitcoin/issues/5872 | configure: BITCOIN_SUBDIR_TO_INCLUDE: Improve compatibility with paths including space and multiline cpp output by luke-jr · Pull Request #5872 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/9946 | Fix build errors if spaces in path or parent directory by pinheadmz · Pull Request #9946 · bitcoin/bitcoin · GitHub
< dburkett> https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_Overview is such an excellent overview of the node design. Is anyone aware of a similar such overview for the wallet code?
< michaelfolkson> John Newbery did a presentation at Chaincode Labs https://www.youtube.com/watch?v=j0V8elTzYAA
< michaelfolkson> Alternatively there are Bitcoin Core PR review club sessions on the wallet (scroll down to wallet) https://bitcoincore.reviews/meetings-components/
< luke-jr> michaelfolkson: 9946 looks completely unrelated; 5872 is still a clean merge
< michaelfolkson> Hmm appears so. 9946 referred to your 5872 to address Issue 9933
< * michaelfolkson> shrugs
< bitcoin-git> [bitcoin] luke-jr opened pull request #20121: configure: Allow users to explicitly enable libsecp256k1's GMP bignum support (master...secp256k1_allow_bignum) https://github.com/bitcoin/bitcoin/pull/20121
< luke-jr> michaelfolkson: afaict, it's simply because 5872 fixed a (completely different) issue with spaces in paths
< pinheadmz> aw. 9946... one of my first contirbutions ever :-)
< michaelfolkson> Still causing problems in 2020 ;)
< luke-jr> eh?
< michaelfolkson> Sorry, just a joke (ignore me)
< sipa> luke-jr: fwiw, after secp256k1 PR 767 we'll probably remove bignum support entirely
< luke-jr> sipa: why does that PR talk about ARM specifically? it looks generic?
< sipa> it is
< sipa> luke-jr: i think ARM benchmarking may appear disproportionally due to the fact that the author doesn'thave any nativd 32-bit hardware and had to ask others for numbers
< luke-jr> I see
< dburkett> michaelfolkson: That presentation is exactly what I was looking for. Thanks!
< michaelfolkson> No problem
< vasild> ariard: I think it is ok to just relay even if the receiver may end up ditching the address (not further gossip it)
< wumpus> vasild: congrats on getting #19954 merged! 🎉
< gribble> https://github.com/bitcoin/bitcoin/issues/19954 | Complete the BIP155 implementation and upgrade to TORv3 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
< hebasto> wumpus: some tor-related stuff is waiting :) -- #19998 and #20002
< gribble> https://github.com/bitcoin/bitcoin/issues/19998 | net: Add CNode::ConnectedThroughNetwork member function by hebasto · Pull Request #19998 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20002 | net, rpc, cli: expose peer network in getpeerinfo; simplify/improve -netinfo by jonatack · Pull Request #20002 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] practicalswift opened pull request #20122: Make Assert(…) usable in all contexts. Make implicit assumptions explicit. (master...Assert) https://github.com/bitcoin/bitcoin/pull/20122
< vasild> wumpus: thanks, that was a true team effort!
< ja> fanquake: why is 13478 linked from https://github.com/bitcoin/bitcoin/issues/20104 ? it doesn't have recent discussion like claimed
< vasild> https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki "Status: Draft" -- should the status be changed?
< vasild> given that it is now implemented (and merged in `master`)?
< ja> vasild: indeed, it could be Proposed now. But Wladimir has to ack that change. So it is harder than getting things Rejected per timeout
< vasild> :)
< * luke-jr> prods wumpus
< sipa> luke-jr:
< sipa> Peer services BIPs should be observed to be adopted by at least 1% of public listening nodes for one month.
< sipa> ah, that's for Final, not Proposed
< jonatack> vasild: yes, congrats on 19954--i'm very glad to see it in 🚀
< sipa> indeed!
< luke-jr> sipa: indeed
< ja> wooow, i got an ack from Gavin! https://github.com/bitcoin/bips/pull/1010
< luke-jr> in a context where it means nothing
< ja> luke-jr: when would an ack be necessary for marking 'obsolete'? i thought it would be analogous to 'final' which you seem to wait for an explicit ack for here: https://github.com/bitcoin/bips/pull/926
< luke-jr> Final doesn't need an ACK, but Draft->Proposed does
< ja> luke-jr: is there something i can do to advance PR 926?
< luke-jr> I can't think of any scenario where ACK has meaning for Obsolete
< luke-jr> ja: ask morcos to ACK it?
< luke-jr> [again]
< sipa> this is an unusual way of messaging a channel, but i guess it works
< fanquake> ja: you should ask hebasto
< bitcoin-git> [bitcoin] decryp2kanon opened pull request #20124: Add blockhash prefix (0x) for Testnet and Regtest (master...master) https://github.com/bitcoin/bitcoin/pull/20124
< bitcoin-git> [bitcoin] promag opened pull request #20125: rpc, wallet: Expose database format in getwalletinfo (master...2020-10-walletinfoformat) https://github.com/bitcoin/bitcoin/pull/20125
< luke-jr> fanquake: hebasto isn't listed as an author..
< fanquake> luke-jr? he opened the issue
< * luke-jr> sometimes wishes we could relax BIP stuff, sigh
< luke-jr> fanquake: only the author can approve Draft->Proposed status change
< fanquake> luke-jr: no idea what you're talking about. I was replying to "fanquake: why is 13478 linked from https://github.com/bitcoin/bitcoin/issues/20104 ? it doesn't have recent discussion like claimed"
< luke-jr> oh lol
< bitcoin-git> [bitcoin] theStack opened pull request #20126: test: p2p_leak_tx.py improvements (use MiniWallet, add p2p_locks acquires) (master...20201011-test-use-miniwallet-for-p2p_leak_tx) https://github.com/bitcoin/bitcoin/pull/20126
< achow101> if I compile against the oldest version of sqlite I can find, and all of the tests pass, is it reasonable to assume that every version between that one and the latest are also compatible?
< achow101> aka I don't want to test every version of sqlite
< sipa> what is the oldest version you tried?
< achow101> 3.8.0
< achow101> only because that was the oldest major release I could download
< sipa> given how little functionality i assume you're using, i think that's very reasonable
< achow101> turns out the actual oldest I could download (3.7.16) doesn't work anyways