< warren>
I don't recall, did we disable getwork yet?
< gmaxwell>
years ago
< gmaxwell>
also, is typing "bitcoin-cli getwork" all that hard? :)
< luke-jr>
:p
< NicolasDorier>
paveljanik: gmaxwell: I noticed my earlier problem about the 0.0.0.0 ip source came only when my client was using "localhost" instead of "127.0.0.1". When using "localhost" if it is resolved by [::1] instead of 127.0.0.1, then my client will send ip source as 0.0.0.0
< NicolasDorier>
no problem if I force ipv4
< NicolasDorier>
so either a ipv6 gotcha I don't get. Or a plain bug in MS implementation of WebRequest.
< paveljanik>
looks like arowser needs to be blocked on github 8)
< jonasschnelli>
yes. Looks like.
< jonasschnelli>
Or he's working on a script or something which apparently did go wrong
< paveljanik>
depends on what what his original goal 8)
< GitHub22>
bitcoin/master 1ad9339 Suhas Daftuar: Test framework: only cleanup on successful test runs
< GitHub22>
bitcoin/master 6700cc9 MarcoFalke: Merge #8095: Test framework: only cleanup on successful test runs...
< GitHub149>
[bitcoin] MarcoFalke closed pull request #8095: Test framework: only cleanup on successful test runs (master...nocleanup-on-failure) https://github.com/bitcoin/bitcoin/pull/8095
< gmaxwell>
freeking arowser.
< gmaxwell>
NicolasDorier: can you try forcing ipv6 in your client (connect to ::1?) and see if it always fails in that case?
< NicolasDorier>
gmaxwell: oddly, using http://[::1]/ to connect just fail to connect, no 403 forbidden. My DNS resolve localhost to 127.0.0.1. I confirm that if I switch from http://localhost/ to http://127.0.0.1/ it solves the problem. I'm looking in the code of the WebRequest class to see what the hell happens.
< NicolasDorier>
I'm almost sure that it connects to [::1] and not 127.0.0.1 when I use localhost, so there is something fishy oO
< NicolasDorier>
disregard my comment which say my machine resolve localhost only to 127.0.0.1, I typed the wrong line
< NicolasDorier>
but I confirm that http://[::1]:port/ give me a "unable to connect" while "http://localhost:port/ which happens to resolve to ::1 give me "403 forbidden" trying to find out....
< NicolasDorier>
gmaxwell: disregard my other comment as well, it seems that now using http://[::1]:port/ resolve to the 403 error _every time_. I will try on another windows machine tomorrow and let you know
< NicolasDorier>
paveljanik: you mentioned people having reported such issue, I don't find in github issues, can be interesting to suggest them to switch to 127.0.0.1
< jonasschnelli>
sipa: How will you pass in the required flags to addrman? Where is the relation between dnsseeder and AddrMan?
< sipa>
jonasschnelli: addrman stores the service bits
< sipa>
jonasschnelli: inside CAddress objects
< sipa>
that's where they need to end up :)
< sipa>
jonasschnelli: CAddress's constructor is invoked right below the code you're touching
< sipa>
jonasschnelli: you need to pass in the service bits there
< GitHub111>
bitcoin/master f20d42e Wladimir J. van der Laan: UpdateTip: log only one line at most per block...
< GitHub111>
bitcoin/master 47a7cfb Pieter Wuille: Merge #7795: UpdateTip: log only one line at most per block...
< GitHub84>
[bitcoin] sipa closed pull request #7795: UpdateTip: log only one line at most per block (master...2016_04_block_warning_logging_inline) https://github.com/bitcoin/bitcoin/pull/7795
< gmaxwell>
\O/ sipa merged wumpus' asm in libsecp256k1
< sipa>
it needs --enable-experimental --with-asm=arm to the configure flags to enable, for now
< sipa>
i do plan to learn some ARM asm and review the actual code at some point, though
< instagibbs>
sdaftuar, what mechanism should I use to have a node check that they did *not* receive a particular message in p2p-segwit
< instagibbs>
like, "make sure the node doesn't send a getdata"
< instagibbs>
any tricks other than just waiting
< wumpus>
:o nice
< sdaftuar>
instagibbs: it's a bit tricky. you can test to see if a block is direct-fetched by doing a sync-with-ping, and checking to see if you received a getdata
< sdaftuar>
instagibbs: but that's not sufficient, as you also would want to check to see if a block might be fetched by the parallel download logic
< sdaftuar>
ah, here's a trick i've never used before, but should work:
< sdaftuar>
you can announce a brand new transaction to the node as well, and wait for the getdata for that tx
< instagibbs>
so, announce block, announce tx, then when I receive getdata for tx, check for block getdata?
< sdaftuar>
yeah
< instagibbs>
ok I'll try that
< sdaftuar>
if you look in SendMessages, we getdata for tx's right after we would getdata for blocks
< sdaftuar>
note by the way that your announcement for the tx can be completely fictitious, ie you can just make up a txid and announce it
< Gatornade>
Hello, is this a good channel to ask one simple question about bitcoin core application?
< Gatornade>
nevermind, read the header. i'll go to #bitcoin