< bitcoin-git> [bitcoin] qshuai closed pull request #13042: Calculated nBits will be replaced by the following GetNextWorkRequire… (master...master) https://github.com/bitcoin/bitcoin/pull/13042
< kallewoof> sipa: gmaxwell: I am on macOS running natively
< kallewoof> (sorry for late response)
< kallewoof> wumpus fanquake: You can drop #12634 from high priority list. Jimpo brought up some points that I hadn't considered, so I think I need to rework this before bringing it up for review. :/
< gribble> https://github.com/bitcoin/bitcoin/issues/12634 | [refactor] Make TransactionWithinChainLimit more flexible by kallewoof · Pull Request #12634 · bitcoin/bitcoin · GitHub
< gmaxwell> kallewoof: it was a longshot... windows has some really obnoxious behavior around exclusive access to files... so much for that guess
< kallewoof> gmaxwell: I haven't closed the lldb session. Not sure what I can glean from lldb/gdb commands though. Looking at threads it doesn't seem like two threads are doing things with leveldb.
< bitcoin-git> [bitcoin] brandonrninefive opened pull request #13284: Fix for Issue #13231 - [gui] visual "overflow" of amount input. (master...ui_amount_overflow_fix) https://github.com/bitcoin/bitcoin/pull/13284
< fanquake> kallewoof done
< kallewoof> fanquake: Thanks!
< belcher> im writing for a bitcoin core PR, this is rpc_net.py https://pastebin.com/SJKwnfKQ my part starts at line 102, i open a p2pconnection to a node and send it some addresses, but then the node doesnt have those addresses in its getaddr as it should, can anyone see anything wrong?
< bitcoin-git> [bitcoin] Empact opened pull request #13288: Remove the need to include "rpc/blockchain.cpp' in order to put `GetDifficulty` under test (master...get-difficulty) https://github.com/bitcoin/bitcoin/pull/13288
< achow101> belcher: all of those addresses are probably considered "terrible"
< belcher> achow101 i tried changing it to addr.time = 1526774400 + i*60 #20th may 2018 but still gives an empty string
< gribble> https://github.com/bitcoin/bitcoin/issues/20 | JSON-RPC callback · Issue #20 · bitcoin/bitcoin · GitHub
< achow101> belcher: actually you need to set services to match those for a full node
< achow101> otherwise they won't get stored
< belcher> sec, trying that
< belcher> so thats node_network | node_witness or node_network_limited | node_witness.. that didnt help either, still returns an empty list
< achow101> belcher: check if they are being added to addrman. There should be lines in the debug.log about it
< belcher> where does debug.log end up when running tests? like ./test/functional/rpc_net.py
< achow101> something should be printed that says the datadir
< achow101> the debug.log will be in there in the regtest folder
< belcher> ah that must be Initializing test directory /tmp/testqo7f6r9j
< achow101> yeah, that's it
< achow101> within that is a datadir for each node started for the test
< belcher> ok so, the datadir gets cleaned up after the test
< belcher> it gets deleted
< achow101> run with --nocleanup
< achow101> or something like that (check -h)
< belcher> also i ran it a few times and once it worked, giving the list of addresses, but i ran it again and it gave an empty list again... so maybe its something to do with the time?
< belcher> the debug.log has this line 2018-05-20T22:55:12.580402Z Added 1000 addresses from 127.0.0.1: 0 tried, 64 new
< achow101> the time does matter, but I think the first step to debugging this is to figure out whether the addresses make it into addrman in the first place
< belcher> a little later: 2018-05-20T22:55:12.921387Z Flushed 64 addresses to peers.dat 141ms
< achow101> aren't you adding 1000 addresses though?
< belcher> yes.. i dont know where 64 comes from
< achow101> hold on, I'll try running it too
< belcher> iv run it again, now its "received: addr (30003 bytes) peer=4" and later "Flushed 0 addresses to peers.dat 291ms"
< belcher> so zero addresses this time
< belcher> here's the exact file im running, sec
< achow101> one thing I'm noticing is that the rpc call is happening before the addr is received, if the ordering in the debug.log is correct
< belcher> i just added time.sleep(3) in case that helps, didnt seem to
< achow101> I'm not seeing anything in the debug.log that indicates that addrman is adding anything
< achow101> belcher: One problem is that the addresses are 192.168.x.x which addrman won't add. I changed those to something else and addrman is adding the addresses
< belcher> oh yes good point
< belcher> i just did that and it seems to be working
< belcher> weirdly the output says 'services': 1 even though i assigned it as node_network | node_witness
< achow101> although it still seems to only be adding 64 addresses
< belcher> ah, i still had the time.sleep
< belcher> when i remove time.sleep it returns an empty list again
< achow101> and you need the time.sleep
< belcher> that will slow down the test runtime :\ i wonder if theres a better way, but i dont think the p2p protocol gives a response to 'addr'
< achow101> I don't think it does
< achow101> you could send a ping and then wait for pong right after sending addr
< belcher> good idea
< belcher> an interesting thing, i tried to make it send 2000 and 2500 addresses instead of 1000, but it returned an empty list then
< achow101> addr can't be greater than 1000
< belcher> ah ok
< belcher> the 64 addresses thing is weird but those 64 can be obtained with getnodeaddresses so its enough to write a test
< belcher> achow101 mininode.py already has a function sync_with_ping() where it sends a ping and waits for the pong :)
< belcher> because that sleep() problem has obviously happened a lot before :p