< bitcoin-git> [bitcoin] Empact closed pull request #13223: refactor: Extract BnB-specific data from CInputCoin (master...duplicate-fee-calc) https://github.com/bitcoin/bitcoin/pull/13223
< bitcoin-git> [bitcoin] kallewoof opened pull request #13242: uint256: Remove unnecessary crypto/common.h use (master...uint256-no-crypto) https://github.com/bitcoin/bitcoin/pull/13242
< bitcoin-git> [bitcoin] jimpo opened pull request #13243: Make reusable base class for auxiliary indices (master...index-abstraction) https://github.com/bitcoin/bitcoin/pull/13243
< fanquake> If we want to tag 0.16.1, can I get some ACKS on #12967
< gribble> https://github.com/bitcoin/bitcoin/issues/12967 | [0.16] Backports by fanquake · Pull Request #12967 · bitcoin/bitcoin · GitHub
< * kallewoof> rubs head at addrman_new_collisions test.
< kallewoof> It.. assumes that the first 17 IP addresses will not cause a collision. They don't. On little endian machines.
< kallewoof> It then assumes taht the 18th IP address will collide. And then it assumes that the 19th won't (where Xth = 250.1.1.<X>).
< kallewoof> No wonder big endian systems would fail the uint256 quick hash stuff. It depended on hashes being a certain way for the tests to succeed. That's not exactly how you test collisions normally. I would totally understand if these hashes were consensus critical somehow.
< kallewoof> I honestly can't see the purpose of this test at all.
< sipa> delete it :)
< kallewoof> sipa: I might! If I can't convince myself they fulfill a purpose.
< kallewoof> I literally tried changing the IP to 250.1.2.<X> and the tests now fail horribly..
< kallewoof> These seem to be from an attempt to increase test coverage from a couple of yrs ago or so, according to git blame.
< kallewoof> Maybe rewrite them to assume that X % of inserted addresses should not cause a collision. That should work on all architectures.
< mryandao> hmm, i noticed that the -alertnotify flag is still in the manpages for `bitcoind` -- shouldn't that be removed already since 0.14?
< mryandao> and what does 'a really long fork' even mean?
< mryandao> oh nvm, just looked into the src and its basically doing an alert if there's a fork thats >= 6 blocks
< kallewoof> sipa: I ended up keeping the tests for now. I just checked where big endian would see collisions and changed tests to work on both. These tests are pretty bad, though, but I guess for the sake of coverage, or something.
< jonasschnelli> MarcoFalke: merge with a single ack? https://github.com/bitcoin/bitcoin/pull/13158
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/13da2899ae42...40c34a0a29f6
< bitcoin-git> bitcoin/master 73cd5b2 Cristian Mircea Messel: [gui] Add proxy icon in statusbar
< bitcoin-git> bitcoin/master 40c34a0 Jonas Schnelli: Merge #11491: [gui] Add proxy icon in statusbar...
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #11491: [gui] Add proxy icon in statusbar (master...add_proxy_icon) https://github.com/bitcoin/bitcoin/pull/11491
< bhbbh> join
< bitcoin-git> [bitcoin] laanwj pushed 10 new commits to 0.16: https://github.com/bitcoin/bitcoin/compare/9ea62a3dc4bd...feba12fe85e8
< bitcoin-git> bitcoin/0.16 f60e84d e0: Limit the number of IPs we use from each DNS seeder...
< bitcoin-git> bitcoin/0.16 f118a7a 251: Fix illegal default `addProxy` and `addrSeparateProxyTor` settings....
< bitcoin-git> bitcoin/0.16 e802c22 John Newbery: [config] Remove blockmaxsize option...
< promag> wumpus: which PR are you looking at?
< jonasschnelli> Q for anyone with leveldb experience (maybe sipa, wumpus): Is there a performance downside of seeking the cursor to a specific key and read the current cursors value rather then just "read" a keys value "directly"?
< wumpus> I wouldn't expect there to be a significant difference, as long as you're looking for an existing key - both have to locate the key in the same way
< jonasschnelli> wumpus: thanks
< jonasschnelli> I was thinking of storing 1-to-n relations (addressindex; address maps to many txns). Instead of constantly update a single object (read->(update)->write) I though of just reducing to a write operation
< jonasschnelli> Though it will lead to more disk-space being consumed due to the repetitive key-parts
< gmaxwell> I would expect pretty poor performance if you look up a non-existing entry, however. (also implied by wumpus' statement; but thought it was worth making a point of)-- otherwise leveldb is pretty fast for misses.
< bitcoin-git> [bitcoin] ken2812221 opened pull request #13246: doc: Bump to Ubuntu Bionic 18.04 in build-windows.md (master...patch-2) https://github.com/bitcoin/bitcoin/pull/13246
< wumpus> right, the per-ldb bloom filter would be expected to make direct misses fast, but if it still has to look at the next record after the cursor, that will be a slower operation
< jonasschnelli> gmaxwell, wumpus: so for a 1-to-n relation, a exist-check is probably the biggest slowdown (especially for the first entry where the key does not exists). So a single write with hash160-blockkey-txpos is probably faster during indexing...
< jonasschnelli> for a lookup, just set the cursor to the key (hash160) and itterate as long as the key matches the hash160
< jonasschnelli> lookup may be slower compared to storing the entire serialized object
< jonasschnelli> (though I expect cursor->next() must be pretty fast)
< jonasschnelli> hmm.. my IDE debugger refuses to debug wallet.cpp since we also have interface/wallet.cpp... meh!
< jonasschnelli> Is that common c++ practice to have same filenames in different subfolders?
< ryanofsky> of course it is, i don't think you would use folders at all if filenames were supposed to be globally unique
< promag> jonasschnelli: should not be a problem
< jonasschnelli> Yes. Your both righ,.. Qt Create dbg/lldb integration is just buggy.
< jonasschnelli> *Qt Creator
< wumpus> right, C/C++ has no requirement for filenames to be unique in a project
< wumpus> this would be really difficult to enforce for large projects with a lot of people working on them. Even more, linkers have no concept of 'project-local' so it'd also collide between libraries then.
< wumpus> (at one employer we did have a requirement that every include file and compilation unit had a unique name; don't know why; but it resulted in everything being prefixed to the point of absurdity; every module had a two/four letter name, and every file had to be prefixed with the concatenated submodule identifiers)
< wumpus> inbefore someone proposes it for the bitcoin repository someone to have a reason to add another linter
< sipa> like src/a/b/c/a_b_c_file.h?
< ryanofsky> i don't think that's repetitive enough, maybe src/a/a_b/a_b_c/src_a_b_c_file.h
< sipa> haha
< bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/40c34a0a29f6...11e7bdfd903e
< bitcoin-git> bitcoin/master ecc3c4a Matt Corallo: Do not unlock cs_main in ABC unless we've actually made progress....
< bitcoin-git> bitcoin/master a3ae8e6 Jesse Cohen: Fix concurrency-related bugs in ActivateBestChain...
< bitcoin-git> bitcoin/master dd435ad Jesse Cohen: Add unit tests for signals generated by ProcessNewBlock()...
< bitcoin-git> [bitcoin] laanwj closed pull request #13023: Fix some concurrency issues in ActivateBestChain() (master...event-tests) https://github.com/bitcoin/bitcoin/pull/13023
< wumpus> yes, that idea, EADGxBLxAP_foowidget.[ch]
< BlueMatt> https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.16.1 <-- I think we should untag the remaining things and move forward with backports
< BlueMatt> wumpus: ?
< bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/11e7bdfd903e...4cfe17c3382b
< bitcoin-git> bitcoin/master 59b87a2 John Newbery: [wallet] Fix potential memory leak in CreateWalletFromFile...
< bitcoin-git> bitcoin/master 470316c John Newbery: [wallet] setup wallet background flushing in WalletInit directly...
< bitcoin-git> bitcoin/master e0e90db John Newbery: [wallet] Add CWallet::Verify function...
< bitcoin-git> [bitcoin] laanwj closed pull request #10740: [wallet] `loadwallet` RPC - load wallet at runtime (master...load_unload_wallet) https://github.com/bitcoin/bitcoin/pull/10740
< BlueMatt> nice!
< BlueMatt> another easy high-priority-merge-win: #13011 :p
< gribble> https://github.com/bitcoin/bitcoin/issues/13011 | Cache witness hash in CTransaction by MarcoFalke · Pull Request #13011 · bitcoin/bitcoin · GitHub
< promag> yap ^
< bitcoin-git> [bitcoin] skeees opened pull request #13247: Add tests to SingleThreadedSchedulerClient() and document the memory model (master...scheduler-tests) https://github.com/bitcoin/bitcoin/pull/13247
< promag> would be nice to have some reviews in #13097
< gribble> https://github.com/bitcoin/bitcoin/issues/13097 | ui: Support wallets loaded dynamically by promag · Pull Request #13097 · bitcoin/bitcoin · GitHub
< promag> jonasschnelli luke-jr ^
< phantomcircuit> sipa, flags ^= 1; is sort of confusing in the transaction deserialization function btw
< phantomcircuit> AllocateFileRange seems to fallback to writting 1 byte at a time?
< bitcoin-git> [bitcoin] mess110 opened pull request #13248: [gui] Make proxy icon from statusbar clickable (master...make_proxy_icon_clickable) https://github.com/bitcoin/bitcoin/pull/13248
< bitcoin-git> [bitcoin] practicalswift opened pull request #13249: Make objects in range declarations immutable by default (master...for-const) https://github.com/bitcoin/bitcoin/pull/13249
< bitcoin-git> [bitcoin] pstratem opened pull request #13250: Simplify ProcessGetBlockData execution (master...2018-05-16-processgetblockdata) https://github.com/bitcoin/bitcoin/pull/13250
< phantomcircuit> ^ but why BlueMatt
< BlueMatt> cause old code got moved, dont blame me
< phantomcircuit> sipa, it's making BlueMatt simpler
< sipa> well please elaborate in the PR description!
< sipa> does it decrease the size of his color pallette?
< phantomcircuit> im not sure how that is possible
< phantomcircuit> blue -> blue
< sipa> seriously, please give a better description on your PR