< bitcoin-git> [bitcoin] jonathancross opened pull request #15712: Update Copyright -> 2019 (master...copyright-2019) https://github.com/bitcoin/bitcoin/pull/15712
< bitcoin-git> [bitcoin] ariard opened pull request #15713: refactor: Replace chain relayTransactions/submitMemoryPool by higher method (master...2019-03-refactor-relay-tx-submit-pool) https://github.com/bitcoin/bitcoin/pull/15713
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #15714: tests: Volkswagen (master...1904-testsVolkswagen) https://github.com/bitcoin/bitcoin/pull/15714
< rafalcpp_> `` How dare you not (use your free time to) fix this ultra high priority bug that is affect '' ---> reply with an LN invoice, if they demand support :)
< Sentineo> :) hope you guys know you are doing a wonderful job and do not let yourself distracted by hate mails :)
< wumpus> rafalcpp_: hehe, I did try things like that at times, though not with LN invoices yet
< wumpus> somehow they always lose interest then though
< e4xit> /join #plex
< wumpus> Sentineo: thank you
< bitcoin-git> [bitcoin] scravy opened pull request #15715: Better support for mainframes and EBCDIC users in general (master...cater-mainframes-and-ebcdic-users) https://github.com/bitcoin/bitcoin/pull/15715
< MarcoFalke> wumpus: I think #15596 is ready, unless you have objections. It seemed a bit weired to me, but I think it made sense back when accounts were a thing. I am going to wait for your feedback, since you might remember more abou it than I do
< gribble> https://github.com/bitcoin/bitcoin/issues/15596 | rpc: Ignore sendmany::minconf as dummy value by MarcoFalke · Pull Request #15596 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/79c345a0114c...35477e9e4e3f
< bitcoin-git> bitcoin/master 9453018 Pieter Wuille: Simplify orphan processing in preparation for interruptibility
< bitcoin-git> bitcoin/master 6e051f3 Pieter Wuille: [MOVEONLY] Move processing of orphan queue to ProcessOrphanTx
< bitcoin-git> bitcoin/master 866c805 Pieter Wuille: Interrupt orphan processing after every transaction
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15644: Make orphan processing interruptible (master...201903_interruptibleorphans) https://github.com/bitcoin/bitcoin/pull/15644
< bitcoin-git> [bitcoin] MishraShivendra opened pull request #15717: Changes to support NAT-PMP (master...master) https://github.com/bitcoin/bitcoin/pull/15717
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/35477e9e4e3f...5a2a9b5b0603
< bitcoin-git> bitcoin/master 0440481 João Barbosa: wallet: Move CWallet::ReacceptWalletTransactions locks to callers
< bitcoin-git> bitcoin/master 57908a7 João Barbosa: interfaces: Add Chain::requestMempoolTransactions
< bitcoin-git> bitcoin/master 2ebf650 João Barbosa: wallet: Update transactions with current mempool after load
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #15652: wallet: Update transactions with current mempool after load (master...2019-03-fix-15591) https://github.com/bitcoin/bitcoin/pull/15652
< bitcoin-git> [bitcoin] dongcarl opened pull request #15718: [WIP] docs: Improve netaddress comments (master...2019-04-netaddr-comments) https://github.com/bitcoin/bitcoin/pull/15718
< dongcarl> Can someone explain to me the context behind `GetGroup`? My git digging lead me to a +1041 −546 commit here: https://github.com/bitcoin/bitcoin/pull/735/commits/67a42f929b1434f647c63922fd02dc2b93b28060
< * dongcarl> sees that it's somewhat related to addrman buckets
< gmaxwell> dongcarl: huh? it's primarily related to the fact that the random-peer outbound connection logic will not connect to two hosts in the same "netgroup".
< gmaxwell> This would be something like "same ASN" if that data were available to us, instead its just the same /16. It makes would be sybil attacker's lives potentially somewhat uh different.
< gmaxwell> Addrman uses it for similar reasons.
< dongcarl> gmaxwell: I see. So on an abstract level each "group
< dongcarl> " represents IPs that might be somewhat related
< dongcarl> e.g. same ASN, datacenter for cloud provider, etc.
< dongcarl> (as an approximation of course)
< gmaxwell> Right.
< gmaxwell> It's perhaps arguable how helpful it is, but it does at least avoid "all my peers are on amazon"
< dongcarl> Would it be fair to say that: A network group represents a collection of addresses which might share similar network routing characteristics.
< * dongcarl> trying to document this
< phantomcircuit> dongcarl, it's not about the routing, it's about getting peers that are less likely to be related
< sipa> dongcarl: yeah, it's (an approximation of) cost to obtain a routable address; we assume it's harder to get addresses in distinct groups than in the same group
< dongcarl> phantomcircuit: Yeah I get that... Just trying to find the right wording for documentation...
< dongcarl> sipa: Ah that's a good way to put it...
< sipa> routing is not the point; all onion addresses (afaik all are in the same group, or just a few groups) have very distinct routing
< sipa> but getting random looking onion addresses is cheap
< dongcarl> That makes sense
< dongcarl> sipa: How about this: "Networks groups aim to group addresses by the (approximate) cost to obtain addresses within the same group such that it's harder to get addresses in distinct groups than in the same group."
< bitcoin-git> [bitcoin] ryanofsky opened pull request #15719: Drop Chain::requestMempoolTransactions method (master...pr/pool) https://github.com/bitcoin/bitcoin/pull/15719
< bitcoin-git> [bitcoin] ssk22014 opened pull request #15720: Ssk22014 (master...ssk22014-patch-1) https://github.com/bitcoin/bitcoin/pull/15720
< bitcoin-git> [bitcoin] fanquake closed pull request #15720: Ssk22014 (master...ssk22014-patch-1) https://github.com/bitcoin/bitcoin/pull/15720