1 2016-06-15 04:14:34	0|GitHub114|[13bitcoin] 15petertodd opened pull request #8204: Update petertodd's testnet seed (06master...062016-06-15-update-tbtc-seed) 02https://github.com/bitcoin/bitcoin/pull/8204
  2 2016-06-15 07:09:55	0|jonasschnelli|sipa: hmm.. "dig A testnet-seed.bitcoin.jonasschnelli.ch" reports different result then "dig A x1.testnet-seed.bitcoin.jonasschnelli.ch"?
  3 2016-06-15 07:11:25	0|sipa|jonasschnelli: of course
  4 2016-06-15 07:11:29	0|sipa|separate request
  5 2016-06-15 07:11:38	0|sipa|since it is not cached by dns
  6 2016-06-15 07:12:16	0|jonasschnelli|Right. But x1 gives me back 22 IP where non-filter gives me back 1 IP!
  7 2016-06-15 07:12:38	0|jonasschnelli|non-filtered should also result in a "full–response" not just a single IP
  8 2016-06-15 07:12:46	0|jonasschnelli|I'll attach gdb
  9 2016-06-15 07:13:12	0|sipa|well at least use dig @yourseedersip A testnet-seed.... then
 10 2016-06-15 07:13:35	0|sipa|so you see what your seeder responds, unfiltered by the several dns layers that may be between
 11 2016-06-15 07:13:55	0|jonasschnelli|Yes. I tested also locally against port 5353
 12 2016-06-15 07:15:26	0|sipa|i get a nice long list for both
 13 2016-06-15 07:18:55	0|jonasschnelli|hmm.. now i'm also getting a long list... strange
 14 2016-06-15 07:19:50	0|sipa|maybe you were just seeing a cached result?
 15 2016-06-15 07:20:37	0|jonasschnelli|Could be. But a cache with a single IP would be strange?!
 16 2016-06-15 07:21:49	0|sipa|unless it only found one useful ip to respond with
 17 2016-06-15 07:26:47	0|jonasschnelli|I think a single IP for NODE_NETWORK after running ~24h seems buggy,... but depends on the ISPs DNS cache TTL overrides. I keep an eye on it...
 18 2016-06-15 07:43:09	0|luke-jr|fwiw, I am intentionally delaying my DNS seed upgrade in case of unexpected issues; let me know if this is a problem.
 19 2016-06-15 07:47:23	0|jonasschnelli|luke-jr: there is no hurry with DNS seeder upgrade...
 20 2016-06-15 07:47:41	0|jonasschnelli|I guess 0.13 will support seeds with support and without support for filtering
 21 2016-06-15 07:48:07	0|sipa|jonasschnelli: oh, an x9 result!
 22 2016-06-15 07:48:17	0|jonasschnelli|sipa: Yes. A single one. :)
 23 2016-06-15 07:48:43	0|jonasschnelli|petertodd dns response 23... ^^
 24 2016-06-15 07:48:45	0|jonasschnelli|(a bug)
 25 2016-06-15 08:03:33	0|GitHub116|[13bitcoin] 15jonasschnelli opened pull request #8205: [Wallet] add HD keypath to CKeyMetadata, report over validateaddress (06master...062016/06/hd_metadata) 02https://github.com/bitcoin/bitcoin/pull/8205
 26 2016-06-15 09:02:34	0|jonasschnelli|hmm... importwallet of a new bip32 dumped wallet will just import the keys and not the "hdness"...
 27 2016-06-15 09:02:41	0|jonasschnelli|but I think this is okay.
 28 2016-06-15 09:03:00	0|jonasschnelli|importwallet is not a backup restore option
 29 2016-06-15 09:10:43	0|GitHub29|[13bitcoin] 15jonasschnelli opened pull request #8206: [Wallet] add HD xpriv to dumpwallet, show masterkeyid in getwalletinfo (06master...062016/06/hd_info) 02https://github.com/bitcoin/bitcoin/pull/8206
 30 2016-06-15 09:14:13	0|GitHub170|[13bitcoin] 15MarcoFalke opened pull request #8207: [trivial] Add a link to the Bitcoin-Core repository to the About Dialog (06master...06Mf1606-LicInfo) 02https://github.com/bitcoin/bitcoin/pull/8207
 31 2016-06-15 17:35:18	0|GitHub100|[13bitcoin] 15sipa opened pull request #8208: Do not set extra flags for unfiltered DNS seed results (06master...06simplerservices) 02https://github.com/bitcoin/bitcoin/pull/8208
 32 2016-06-15 19:13:09	0|jouke_|Core wallet also rebroadcasts transactions it received right?
 33 2016-06-15 19:13:15	0|jouke_|Or, hmmm.
 34 2016-06-15 19:13:25	0|jouke_|I don't think it does.
 35 2016-06-15 19:15:26	0|sipa|only its own transactions
 36 2016-06-15 19:17:11	0|jouke_|thanks
 37 2016-06-15 19:18:24	0|gmaxwell|now that we have expiration and limited mempools it might be useful for privacy to 'adopt' random addresses from the network and rebroadcast them like a local wallet.
 38 2016-06-15 19:21:30	0|jouke_|Yeah, and those block explorers probably keep those transactions longer visible as well. A lot of our customers don't keep their wallets online after they made a transaction.
 39 2016-06-15 19:22:41	0|jouke_|And use blockexplorers to keep track of those transactions
 40 2016-06-15 19:25:35	0|gmaxwell|it might make sense to only do this for addresses that send a high fee RBF flagged transaction, rebroadcasting non-rbf/low fee txn can have adverse effects, getting in the way of a higher fee doublespend post expiration.
 41 2016-06-15 19:28:36	0|jouke_|Indeed. Altough most of them don't mind if we rebroadcast them for them (it saves them the hassle).
 42 2016-06-15 19:30:00	0|gmaxwell|a lot of the needs rebroadcast activity I've seen is due to chains of unconfirmed transactions basically not propagating at all in the network.
 43 2016-06-15 19:31:12	0|gmaxwell|0.13 will help that, potentially a lot depending on if my last orphanmap PR goes in.
 44 2016-06-15 19:36:32	0|gmaxwell|Can I get some other review on #8084, by chance only people from blockstream have ACKed it (though I don't believe it's ever been mentioned inside blockstream, beyond me asking patrick to review since he originally wrote that code)
 45 2016-06-15 19:37:00	0|gmaxwell|it's a pretty trivial change.
 46 2016-06-15 19:37:21	0|gmaxwell|and I'd be glad to explain it or the general evicition logic, if anyone has questions.
 47 2016-06-15 19:39:11	0|sdaftuar|gmaxwell: i'll try to take a look today
 48 2016-06-15 19:49:43	0|jouke_|You guys are doing an awesome job :)
 49 2016-06-15 19:54:34	0|sdaftuar|gmaxwell: i just looked at the change to AcceptBlock.  if i send you an old block that is just past the last checkpoint (and not on the main chain), you'll think i'm a better peer?
 50 2016-06-15 19:56:17	0|sipa|jouke_: thank you
 51 2016-06-15 19:58:09	0|gmaxwell|sdaftuar: Yes, though there are only a finite number of those.  Have any suggestion on a better _simple_ test? This is a fairly small behavior and I really didn't want to go restructuring block acceptance to enable it.
 52 2016-06-15 19:58:33	0|gmaxwell|I ~think~ it's okay if it's a little approximate, but ideally it should be the least approximate that can easily be done.
 53 2016-06-15 19:58:47	0|sdaftuar|yeah i'm not sure what you're going for here
 54 2016-06-15 19:59:02	0|sdaftuar|presumably it's not hard to mine new blocks just past the last checkpoint using today's mining hardware
 55 2016-06-15 19:59:17	0|sdaftuar|if that's okay, then so be it
 56 2016-06-15 19:59:45	0|sdaftuar|i think an alternative thing to do would be to see if they're giving you a block that's on a more work chain than your tip
 57 2016-06-15 19:59:50	0|gmaxwell|Basically we reserve a couple of inbound slots to be protected from eviction based on a bunch of different hopefully orthorgonal criteria. So that its difficult for a single attacker to 'win' in all the different ways.
 58 2016-06-15 19:59:55	0|sdaftuar|fHasMoreWork is right there
 59 2016-06-15 20:00:09	0|gmaxwell|I could just move that test down to after the not requested block.
 60 2016-06-15 20:00:20	0|sdaftuar|yeah that should work
 61 2016-06-15 20:00:25	0|gmaxwell|and then it won't get set if it wasn't requested (better header) or at least has work.
 62 2016-06-15 20:00:28	0|gmaxwell|okay will do.
 63 2016-06-15 20:00:30	0|sdaftuar|cool
 64 2016-06-15 20:00:34	0|gmaxwell|I agree that would be better.
 65 2016-06-15 20:08:19	0|gmaxwell|anyone know how to fix a corrupt git repo? :(  my laptop lost power while I was in the process of pushing the update. and I'm now getting:
 66 2016-06-15 20:08:30	0|gmaxwell|error: object file .git/objects/7e/990c38c0751935245fc1b370823623fd791fc8 is empty
 67 2016-06-15 20:08:33	0|gmaxwell|error: object file .git/objects/7e/990c38c0751935245fc1b370823623fd791fc8 is empty
 68 2016-06-15 20:08:36	0|gmaxwell|fatal: loose object 7e990c38c0751935245fc1b370823623fd791fc8 (stored in .git/objects/7e/990c38c0751935245fc1b370823623fd791fc8) is corrupt
 69 2016-06-15 20:08:45	0|sipa|gmaxwell: delete those files until it no longer complains
 70 2016-06-15 20:08:49	0|sipa|run git fsck
 71 2016-06-15 20:09:07	0|sipa|you may to manually change what head points to
 72 2016-06-15 20:09:11	0|gmaxwell|oh awesome I lost net.cpp too.
 73 2016-06-15 20:09:27	0|gmaxwell|weird when I wasn't even editing that file.
 74 2016-06-15 20:10:19	0|sipa|tjis is what happens to me all the time when my laptop goes out of power while compiling
 75 2016-06-15 20:10:37	0|sipa|maybe i should make 'make' an alias for 'sync; make'
 76 2016-06-15 20:13:27	0|gmaxwell|wow it wiped out most of the source files in fact, perhaps because they'd changed briefly before in my checkout.
 77 2016-06-15 20:14:05	0|btcdrak|what about your reflog?
 78 2016-06-15 20:14:15	0|sipa|reflog won't help
 79 2016-06-15 20:14:33	0|sipa|best case, it points to objects that no longer exist
 80 2016-06-15 20:14:40	0|sipa|worst case, the reflog is gone
 81 2016-06-15 20:15:21	0|sipa|gmaxwell: worktrees are nice
 82 2016-06-15 20:15:44	0|gmaxwell|damn that branch is destroyed, and I can't delete it.
 83 2016-06-15 20:16:43	0|gmaxwell|I should alias git to "sync; git"
 84 2016-06-15 20:17:11	0|gmaxwell|why doesn't git sync after making changes? :-/
 85 2016-06-15 20:19:32	0|gmaxwell|sdaftuar: updated, thanks.
 86 2016-06-15 20:40:38	0|gmaxwell|for context, I wouldn't consider "mine a checkpoint-diff-block to get placement here" a bad outcome, less good than the simple change. But we should eventually have a hashcash category too.  (and as many other categories as people can think of that we can easily measure)
 87 2016-06-15 20:41:41	0|sipa|they should also not protect a fixed number of nodes, but rather some percentages
 88 2016-06-15 20:42:45	0|gmaxwell|some might be better as percentages, some better as fixed numbers.
 89 2016-06-15 20:43:01	0|sipa|i think there should also be some generic scoring, that can be used as tie breakers
 90 2016-06-15 20:43:04	0|sipa|than you
 91 2016-06-15 20:43:15	0|sipa|1) remove protected nodes from the list
 92 2016-06-15 20:43:45	0|sipa|2) sort by the tie breaker per netgroup, and remove all but the best from each netgroup
 93 2016-06-15 20:44:12	0|sipa|3) sort the remainders again overall, and pick the worst
 94 2016-06-15 20:44:30	0|sipa|eh, remove the best from each netgroup
 95 2016-06-15 20:44:33	0|gmaxwell|I suggested before some abstract ratio of bandwidth usage to 'good activity', then rank peers by that.
 96 2016-06-15 20:44:49	0|gmaxwell|there are a lot of little improvements too, e.g. those sorts should all be heaps.
 97 2016-06-15 20:44:54	0|sipa|indeed
 98 2016-06-15 20:45:16	0|sipa|after the libevent switch we may be able to deal with many more peers
 99 2016-06-15 20:46:03	0|gmaxwell|I worry that that will undermine the utility of things like eviction, since with many peers you'll be able to be kept busy with 999 junk peers. No one is disconnected but they might be startved.
100 2016-06-15 20:48:51	0|sipa|or maybe there can be multiple local node services, with connections sharded over them
101 2016-06-15 20:49:01	0|sipa|that each run on one or a few threads
102 2016-06-15 20:49:16	0|sipa|and communicate with eachother as peers
103 2016-06-15 20:52:56	0|instagibbs|is there a fast way in github to check how PRs changed
104 2016-06-15 20:53:24	0|btcdrak|what do you mean?
105 2016-06-15 20:54:11	0|instagibbs|someone squashes, changes a PR, whatever. Aside from locally fetching, diffing, is there an in-github way to do this if I have the two commit hashes
106 2016-06-15 20:54:43	0|btcdrak|Github has started to send email notification for each push
107 2016-06-15 20:55:56	0|btcdrak|instagibbs: I dont think so, except for the /compare/ url scheme
108 2016-06-15 20:56:27	0|btcdrak|assuming you know prev hash from the notification history, or lookjing at the submitter's RSS feed
109 2016-06-15 20:56:47	0|instagibbs|example?
110 2016-06-15 20:57:19	0|btcdrak|https://github.com/instagibbs?tab=activity
111 2016-06-15 21:00:41	0|btcdrak|compare format is something like https://github.com/<baseforkusername>/<repo>/compare/<branch>...<repo>:<commit/branch>
112 2016-06-15 21:48:15	0|sipa|
113 2016-06-15 21:50:51	0|gmaxwell|yes, I think to increase the peer count, we should have some kind of mechenism that isolates or at least prioritizes handling peers.