< GitHub32>
bitcoin/master d2cd9c0 nomnombtc: add script to generate manpages with help2man
< GitHub32>
bitcoin/master 6edf2fd nomnombtc: add gen-manpages.sh description to README.md
< GitHub32>
bitcoin/master eb5643b nomnombtc: add autogenerated manpages by help2man
< GitHub42>
[bitcoin] laanwj closed pull request #8608: Install manpages via make install, also add some autogenerated manpages (master...man_automake2) https://github.com/bitcoin/bitcoin/pull/8608
< Eliel>
wumpus: I have this theory that there's not an actual shortage of people who have an actual clue about windows security but the motivations for actually learning about it are because they think the skill will make them money, so unless you're willing to pay a lot, it's not generally available.
< wumpus>
Eliel: yes, that's how my reasoning goes, too. One popular way to make a lot of money from knowing windows internals is exploiting them or working for companies that sell add-on security products, but helping secure open source software is not one of them at least
< wumpus>
it's a different kind of culture, in Linux people show that they know about e.g. kernel internals by working on them in public, in windows it's all much more hush hush
< midnightmagic>
the Sysinternals guys (used to?) do *incredible* workshops
< wumpus>
I'm sure an issue "ASLR doesn't seem to work properly on " Linux/*BSD or even MacOSX would be solved in a day
< wumpus>
for windows you get one reply from a clueless user 'look at the DLL flags' .. .yea, we hadn't thought of that yet
< wumpus>
yes the sysinternals guys are extrememly clueful, too clueful to be allowed to exist outside Microsoft so they were bought up :)
< luke-jr>
jonasschnelli: being able to build from source is important; it's not enough to just have hacks that work for gitian
< wumpus>
which 'hacks that work for gitian'?
< jonasschnelli>
Yes. Please elaborate... :)
< jonasschnelli>
As far as i know we are using the default unpatched mingw compiler in out ubuntu vm
< midnightmagic>
<3 the sysinternals guys. very cool what they do. srsly, if they have workshops, attend them, just being around them makes you smarter. :)
< dcousens>
wumpus: it doesn't seem that GetNextWorkRequired was called with a NULL argument since 2010 when pIndexBest =NULL was the default in main.cpp
< dcousens>
but, I haven't checked *every* commit since then :S
< dcousens>
I'd hazard it stopped having that oppurtunity when pindexBest was refactored out
< wumpus>
dcousens: then an assert makes some sense; although in a more general sense we do use assert too much for invalid input handling
< dcousens>
wumpus: its probably just an indication we should use more references rather than pointers? (unless the aim is to be C compatible)
< wumpus>
though an assertion crash is absolutely preferable to a SIGSEGV due to a null pointer
< dcousens>
to me, the assertion just indicates, we're 99% this doesn't happen, but not 100% sure enough to dereference at the call site
< wumpus>
yes
< wumpus>
I didn't mean that as an argument againt your specific change
< dcousens>
wumpus: oh I know, I agree with you
< wumpus>
using references would indeed avoid the issue in this case
< wumpus>
jonasschnelli: as far as I know we're using an unpatched compiler for gitian win32/64 building too; I dont think we do any specific hacks to get it to build/run
< wumpus>
well there is one hack to zero the heap during compilation to work around an issue in 14.04's mingw gcc compiler where four random heap bytes leak into the executable, but that's only required for determinism
< wumpus>
so yes there are some hacks for determinism, someone building from source for themselves can safely skip them, that's why they're not described in doc/build-*.md
< wumpus>
disabling hardening is advice you should never give anyone in good conscience though
< GitHub171>
bitcoin/master 152f45b Peter Todd: Add option to opt into full-RBF when sending funds
< GitHub171>
bitcoin/master 05fa823 Wladimir J. van der Laan: wallet: Add BIP125 comment for MAXINT-1/-2 behavior
< GitHub171>
bitcoin/master 86726d8 Wladimir J. van der Laan: Rename `-optintofullrbf` option to `-walletrbf`...
< GitHub29>
[bitcoin] laanwj closed pull request #8601: Add option to opt into full-RBF when sending funds (rebase, original by petertodd) (master...2016_08_full_rbf_option) https://github.com/bitcoin/bitcoin/pull/8601
< jl2012>
wumpus: I think nothing in the RPC test is using createwitnessaddress, and that could be done with 2 lines of python code
< wumpus>
right, nothing is using it
< jonasschnelli>
hmm... NotifyHeaderTip is firing during IBD for every block connected to the main chain... I though it should only fire when a new header gets append to the headers-chain.
< jonasschnelli>
For the overlay I'm working on, a notification of the header-chain tip update would be convinient..
< sipa>
i'm not sure why you think that's not what happens
< jonasschnelli>
sipa: right now, I get NotifyHeaderTip() during IBDs header-sync of the blocks that gets connected (example: NotifyHeaderTip fires when header-chain is at 300'000 with a block-connect at height 100).
< jonasschnelli>
Listening to the signal I cannot distinct between the actual header-sync-tip-update and the block-connect
< jonasschnelli>
Or it looks like the listener cannot distinct.
< jonasschnelli>
Well, now I can just load pindexBestHeader->nHeight when the signal fires..
< sipa>
i'm really confused
< jonasschnelli>
Maybe I'm interpreting the signal wrong..
< sipa>
it should fire whenever we learn about a new best header
< jonasschnelli>
What i'm looking for is a way to get a tip-update of the headers-chain (in order to calculate the remaining blocks to verify)
< sipa>
ok
< sipa>
that's what it doez
< sipa>
does
< jonasschnelli>
But it does fire _again_ when a block connects
< jonasschnelli>
(with the header=true)
< sipa>
it should not
< sipa>
can you explain the call graph that results in that spurious call?
< jonasschnelli>
sipa: I'll try to give you clear steps to reproduce... give me a minute
< jonasschnelli>
sipa: I think I'm misunderstanding something. Isn't pindexBestHeader the chaintip of the headers-only chain?
< jonasschnelli>
During the NotifyHeaderTip signal, I get something like: initialSync: 1, height: 359 but bestheaderheight->nHeight == 48000
< jonasschnelli>
I expected the signal to fire (with headers=true) when pindexBestHeader get updated with the next chunk of headers.
< sipa>
oh, i see
< sipa>
i does not actually notify for the best header
< sipa>
it notifies for updates to the best header chain which could be verified
< sipa>
so only when all blocks towards it have been downloaded
< sipa>
which is sufficient for reindexing
< jonasschnelli>
sipa: Do you think it would make sense to extend the signal to also fire when the best header chain updates its tip?
< jonasschnelli>
Or would that break the reindexing?
< wumpus>
well in any case it's a historical curiosity now, probably should mention it is removed in the release notes, at least if adding it was
< sipa>
it was only ever usable on testnet
< wumpus>
I hope it will be gone before anyone loses their coins due to it
< sipa>
with 0.13.0 it can never be used on mainnet, even after segwit activates
< wumpus>
yes but my question was whether it should be removed on master
< wumpus>
it is a pull to master
< wumpus>
the description was indeed formulated as 'this is never useful on 0.13' ,so I asked whether it was on purpose that it removes it from master too, but appearantly it is
< MarcoFalke>
We should still do a backport. Just for consistency.
< wumpus>
yes
< wumpus>
it's marked as needs backport
< sipa>
i'd rather only add something like this back of there is a demand for it
< wumpus>
agreed
< sipa>
and then we can assess what protections are useful
< wumpus>
it's just an utility call anyhow, it doesn't need to be on RPC
< cfields>
basically if a user doesn't have the expected services, we start to disconnect, but we send them an initial getheaders anyway. Not sure how long it takes to recover from that, maybe a non-issue.
< cfields>
s/user/peer/
< wumpus>
let's backport is just in case
< wumpus>
btw: which maxupload test failure? does it fail intermittently?
< cfields>
wumpus: the rpc test, in -extended
< wumpus>
ok
< cfields>
it fails 100% without #8707. With that, I think it's intermittent (depends on how much goes through the optimistic send) without #8708, which fixes it completely.
< wumpus>
thanks for the explanation
< cfields>
np, sorry for the breakage.
< cfields>
thanks for shoving the CConnman PR in, btw. I had lots of stuff blocked on that :)
< GitHub110>
[bitcoin] laanwj closed pull request #8457: Add block height support in rpc call getblock (master...feature/add-get-block-by-number) https://github.com/bitcoin/bitcoin/pull/8457
< wumpus>
well this is a pretty light breakage as these things go, it had to happen at some time
< wumpus>
now it's in it can be improved
< wumpus>
right :)
< wumpus>
I'm happy travis is so stable again
< cfields>
yea, that was getting really annoying. And as gmaxwell said, it has a quick psychological effect. Doesn't take long before you start ignoring the failures completely.
< wumpus>
yes, I was already starting to rely on local testing only again
< wumpus>
(which means only one platform/compiler)
< MarcoFalke>
cfields: Do you think it is hard to get osx builds woring?
< cfields>
MarcoFalke: we already do a cross osx build. You mean a native one?
< Lightsword>
what’s wrong with osx builds?
< MarcoFalke>
If there is no plan to add native ones, we don't need the os:linux
< MarcoFalke>
strictly speaking
< cfields>
MarcoFalke: sure, it's just explicit there in case it's ever required
< morcos>
cfields: additional slight bug in shutdown related to ConnMan
< morcos>
you call g_connman->Stop() when it might be a null pointer
< morcos>
there is even a comment above warning you not to do that. :)
< cfields>
heh, looking
< morcos>
can be demonstrated by just running 2 bitcoind's the second one tries to exit due to data directory locked and then segfaults
< cfields>
morcos: indeed. Thanks, fixing.
< GitHub32>
[bitcoin] theuni opened pull request #8715: net: only delete CConnman if it's been created (master...fix-connman-shutdown) https://github.com/bitcoin/bitcoin/pull/8715
< cfields>
morcos: ^^. Thanks.
< GitHub83>
[bitcoin] MarcoFalke opened pull request #8716: [qa] wallet: Check legacy wallet as well (master...Mf1609-qaWalletLegacy) https://github.com/bitcoin/bitcoin/pull/8716
< GitHub132>
[bitcoin] spencerlievens opened pull request #8717: [WALLET] Addition of ImmatureCreditCached to MarkDirty() (master...patch-2) https://github.com/bitcoin/bitcoin/pull/8717