< 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
< * 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.
< 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
< 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
< 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