< bitcoin-git>
bitcoin/master b855592 Antoine Riard: [wallet] Move getHeight from Chain::Lock interface to simple Chain
< bitcoin-git>
bitcoin/master de13363 Antoine Riard: [wallet] Move getBlockHeight from Chain::Lock interface to simple Chain
< bitcoin-git>
bitcoin/master 0a76287 Antoine Riard: [wallet] Move getBlockHash from Chain::Lock interface to simple Chain
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #16426: Reverse cs_main, cs_wallet lock order and reduce cs_main locking (master...2019-07-remove-more-locking-chain) https://github.com/bitcoin/bitcoin/pull/16426
< luke-jr>
elichai2: sorry, I run in LE mode
< thomasb06>
Hello. I would have a question about the difficulty and the target.
< thomasb06>
What if the minimum possible target, which is 0x1, is reached? It would also mean that the maximum difficulty has been reached too.
< wumpus>
the maximum possible difficulty would be reached when miners start continuously cranking out blocks with the minimum possible target for the whole period, but this is impossible unless SHA256 is completely compromised
< thomasb06>
As soon as the computer power is strong enough, the difficulty will remain stuck at its maximum, no?
< wumpus>
(even then it's a stretch)
< thomasb06>
A stretch? What do you mean?
< wumpus>
do the math :) there's no way computer power will ever be strong enough to iterate that many hashes per second
< thomasb06>
Let me try...
< wumpus>
depending on the properties of SHA256 it might well be impossible to get an output that is exactly 00..01, I don't think this has been proven
< thomasb06>
wumpus: SHA is not completely known neither, indeed. Thanks anyway
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18840: wallet: Fully process previous wallet calls before accepting new ones (master...2004-walletFullyProcessRPCs) https://github.com/bitcoin/bitcoin/pull/18840
< achow101>
wumpus: I was digging into the BDB data format and at some point did `file wallet.dat` which reported that it was in native byte order. I also can't find anyhwere where we set the BDB byte order.
< achow101>
so I assume that we aren't setting the endianness and thus aren't arch independent. I'm trying to figure out how to test that hypothesis
< luke-jr>
achow101: it's possible BDB can load foreign-endian files?
< achow101>
luke-jr: yes, there's an endianness flag and it will do byteswapping internally
< luke-jr>
then what's the problem? :x
< achow101>
you need to tell it to use a particular endianness or it will default to the platform's
< luke-jr>
achow101: if it doesn't cause compatibility problems, using the native endianness is probably best?
< achow101>
luke-jr: I think if you take a wallet.dat from a BE machine to a LE machine, there will be problems. trying to test that out
< wumpus>
yes, I think that's ok
< wumpus>
that at least *used* to not be the case
< wumpus>
but the last time I tried was when I was working on big-endian support which is years ago
< wumpus>
FWIW back then I used qemu-user from MIPS big-endian for testing
< vasild>
if you are talking about bdb 4.8, it has been EOL-ed about a decade ago, so I don't think any changes to it were made "recently"
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #18840: wallet: Fully process previous RPCs before accepting new ones (master...2004-walletFullyProcessRPCs) https://github.com/bitcoin/bitcoin/pull/18840
< wumpus>
achow101: if bdb allows overriding the endianness when creating a database then it should be pretty straightforward to test if it automatically picks it up
< wumpus>
(e.g. wouldn't require actually emulating a different-endian machine)
< achow101>
wumpus: it's not clear to me whether it chooses a byte order based on the platform or whether it sets no byte order and just uses whatever endianness the platform is even if it doesn't match the db
< luke-jr>
ah
< ryanofsky>
iirc it does byte swapping if needed internally, and just chooses matching endiannness as an optimization
< achow101>
hmm, looks like it checks endianness by testing if the magic number needs to be byteswapped, so the endianness isn't a concern
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #18842: wallet: Mark replaced tx to not be in the mempool anymore (master...2004-walletBumpFeeReplacedTxNoMempool) https://github.com/bitcoin/bitcoin/pull/18842
< wumpus>
achow101: good to know, thanks for checking
< achow101>
has anyone looked into using BDB's sub-databases for better encapsulation of our storage things? it seems like that might have actually been useful for wallet boxes by having each box control it's own storage with a sub-db
< bitcoin-git>
[bitcoin] vasild opened pull request #18843: build: warn on potentially uninitialized reads (master...enable_Wconditional-uninitialized) https://github.com/bitcoin/bitcoin/pull/18843
< thomasb06>
wumpus: (maybe I'll be back tomorrow for the Cpu computation...)
< jb55>
looks like all the vChecks in a the loop that allocates script checks for the CCheckQueueControl? going to run with par=1 to see if alloc thrashing goes away.
< sipa>
that should be at most one allocation per transaction
< jb55>
haven't tested par=1 yet for connectblock but noticing lots of allocations in threadrename during ibd? looks like a recent commit added this? https://jb55.com/s/5b0a3868890c561d.png I'm using heaptrack.
< jb55>
going to try to remove the strprintf in there and see how it goes