< ossifrage>
I did a checkout today, a clean and a reconfigure but I'm failing to build with: make[2]: *** No rule to make target 'checkpoints.cpp', needed by 'libbitcoin_server_a-checkpoints.o'. Stop.
< ossifrage>
Looks like I have something left behind from the old build, not caught by the clean
< gmaxwell>
achow101: I think junk is permitted by the network so long as you don't use it.
< fanquake>
dongcarl Looks like we dont export GZIP_ENV anywhere (as far as I can see), however it seems like everywhere we are using gzip we are passing -9n explicitly.
< fanquake>
I also see what you mean about the overriding in the makefile. Where the options would essentially become --best, which seems to be equivalent to -9.
< dongcarl>
Right. It's the `-n` that gives us the determinism
< fanquake>
Yea
< dongcarl>
Confused about how this hasn't caused differences in gitian sigs...
< fanquake>
"When compressing, do not save the original file name and timestamp by default."
< fanquake>
What would be causing the difference?
< dongcarl>
the timestamp
< fanquake>
dongcarl but we are still passing -n for gitian sigs?
< fanquake>
In the descriptors when we call gzip, we pass -9n
< fanquake>
I agree that it's confusion given that the GZIP export is seemingly redundant?
< fanquake>
*confusing
< dongcarl>
Working on something where I remove all the re-gzipping, cuz `tar` got a `--sort=name` flag now
< fanquake>
The GZIP env var is also deprecated, so if we'll seemingly have to lose it at some point anyways.
< fanquake>
Is that guix related?
< dongcarl>
> GZIP export is seemingly redundant
< dongcarl>
We might need to change to a wrapper cuz perhaps some determinism in the depends tree might depend on this deprecated env var
< dongcarl>
fanquake: Sort of Guix related, could be merged in by itself. Doing a cleanup of the descriptors and build system as I go along.
< fanquake>
dongcarl cool. Happy to help out / test if required!
< dongcarl>
:-)
< jb55>
any ideas on best practice for multiimporting HW wallet keys into core's keypool when you don't know which keys have been used already? perhaps there could be a way to have an semi-intelligent multiimport that will only add the key into the keypool if it hasn't received anything yet?
< jb55>
if that makes sense
< achow101>
jb55: maybe something that does scantxout with the descriptor to mark which keys are unused, and import the unused ones?
< jb55>
achow101: yeah something like that, I'm not too familiar with the codebase but I imagine you would have to hold onto everything until the very end before you add it to the pool or not...
< jb55>
achow101: will core re-use keypool-imported addresses if they've been used already? if not then there's no issue.
< achow101>
jb55: only if you rescan after importing
< achow101>
rescanning will remove used things from the keypool
< sdaftuar>
gmaxwell: regarding the orphan transaction issue and the getdata randomization behavior-- it looks to me like we (a) do not put any delay on getdata requests for outbound peers announcing a tx for the first time and (b) have a fixed delay for inbound peers announcing a tx for the first time
< sdaftuar>
gmaxwell: so i think in the case of a peer announcing a set of transactions that are new to us, we'll request those transactions in dependency order from that peer, except if an inbound peer's announcement is partially supserseded by a later announcement from an outbound peer for a subset of the transactions
< sdaftuar>
gmaxwell: so that seems like it should be a relatively small effect (and is an effect we have to some degree already)
< bitcoin-git>
[bitcoin] ccapo opened pull request #16024: [rpc] deriveaddresses: Correction of descriptor checksum in RPC example (master...2019-05-14-deriveaddresses-example-checksum) https://github.com/bitcoin/bitcoin/pull/16024