12015-10-23T00:05:01 *** dcousens has joined #bitcoin-core-dev
22015-10-23T00:10:27 *** challisto has quit IRC
32015-10-23T00:36:02 *** PRab has quit IRC
42015-10-23T00:54:20 *** Ylbam has quit IRC
52015-10-23T01:18:37 *** jgarzik has quit IRC
62015-10-23T01:18:57 *** jgarzik has joined #bitcoin-core-dev
72015-10-23T01:25:26 *** dcousens has quit IRC
82015-10-23T01:37:50 *** dcousens has joined #bitcoin-core-dev
92015-10-23T01:38:07 <dcousens> petertodd: maybe change the PR title to `Full-RBF with nSequence opt-out`?
102015-10-23T01:38:41 <dcousens> petertodd: it reads as though its an opt-out for the node (until you read the PR itself, obviously)
112015-10-23T01:38:50 <dcousens> (but even still, I had to check the code to be sure)
122015-10-23T01:41:07 <GitHub159> [bitcoin] jgarzik opened pull request #6873: [cleanup] leveldbwrapper becomes more generic 'dbwrapper' module (master...2015_dbwrapper) https://github.com/bitcoin/bitcoin/pull/6873
132015-10-23T01:42:23 <gmaxwell> It would also be less confusing if it were called opt-in. (since transactions are currently opt out under the design)
142015-10-23T01:42:41 <dcousens> gmaxwell: agreed
152015-10-23T01:42:55 <dcousens> though it is called opt-in in the commit
162015-10-23T01:42:59 <dcousens> So, maybe consistency there
172015-10-23T01:48:19 <dcousens> jgarzik: in 6873
182015-10-23T01:48:28 <dcousens> what actually makes CDBWrapper agnostic of leveldb?
192015-10-23T01:48:34 <dcousens> It seems to still use all the statuscode types
202015-10-23T01:48:43 <dcousens> And the wrapper can still be instantiated by itself
212015-10-23T01:49:23 <dcousens> Or is this just a transitionary step?
222015-10-23T01:49:52 <sipa> dcousens: it's API-agnostic... code using it doesn't need to know that it's backed by leveldb
232015-10-23T01:50:01 <sipa> even though you can't compile it any other way
242015-10-23T01:50:13 <jgarzik> nod. The interface is backend agnostic
252015-10-23T01:50:59 <dcousens> jgarzik: then maybe the PR should be about removal of leveldb types in DbWrapper
262015-10-23T01:51:20 <jgarzik> dcousens, did you look at the sqlite commit?
272015-10-23T01:51:34 <dcousens> sqlite commit?
282015-10-23T01:51:47 <dcousens> nvm
292015-10-23T01:51:54 <dcousens> right
302015-10-23T01:52:02 <dcousens> cheers
312015-10-23T01:52:39 <dcousens> jgarzik: my bad for not reading the PR before reading the changes
322015-10-23T01:53:25 <dcousens> this just reads weird: https://github.com/bitcoin/bitcoin/pull/6873/files#diff-ac09ab7f710fc2fb7850f59601545636R137
332015-10-23T01:53:59 <dcousens> Given its called a 'wrapper', but its now generic, seems a bit odd IMHO
342015-10-23T01:54:14 <sipa> call it DbInterface then
352015-10-23T01:54:31 <phantomcircuit> jgarzik, :)
362015-10-23T01:54:55 <dcousens> sipa: but its not just an interface no, it instantiates and manages the entire thing right?
372015-10-23T01:55:04 <dcousens> its more like 'Db', ha
382015-10-23T01:55:54 <jgarzik> it is a class that wraps the backend database in a nice snuggly generic interface
392015-10-23T01:56:39 <gmaxwell> (1) dear god, are people really arguing about this, (2) dbwrapper says what it does!
402015-10-23T01:56:48 <jcorgan> jgarzik: compile ack on the 2015_sqlite branch, but looks like retains all the leveldb naming in the build system, checking now
412015-10-23T01:57:36 <dcousens> gmaxwell: wasn't arguing, just seemed better to ask here than ask about it on GH seeing as its probably me just missing context
422015-10-23T01:57:58 <jgarzik> jcorgan, naming? 2015_sqlite branch should not include any leveldb naming in the bitcoin->sqlite path. it _does_ build leveldb. it _does not_ link leveldb to bitcoind.
432015-10-23T01:58:11 <jcorgan> oh, that's what i'm seeing then
442015-10-23T01:58:51 <sipa> dcousens: then DbWrapper is a better name! it's something that wraps a db, but you don't know or care what kind of database that is
452015-10-23T01:59:02 <dcousens> gmaxwell: in any case, a wrapper typically wraps an existing object no?
462015-10-23T01:59:23 <dcousens> in this case, the object is entirely owned by the wrapper
472015-10-23T01:59:43 <sipa> grrrrr, EncapsulatedDb then?
482015-10-23T01:59:50 *** gmaxwell has left #bitcoin-core-dev
492015-10-23T01:59:57 <dcousens> haha, sipa this isn't important, I'm just curious
502015-10-23T02:01:16 <jcorgan> jgarzik: there are some stray leveldb name issues
512015-10-23T02:01:35 <jgarzik> jcorgan, where?
522015-10-23T02:01:42 <jcorgan> like using 'leveldb_error' in dbwrapper.cpp
532015-10-23T02:01:58 <jgarzik> hrm, I thought I got that one :(
542015-10-23T02:02:22 <jgarzik> jcorgan, no, wait, I did. git pull. :)
552015-10-23T02:02:25 <jcorgan> it's still defined in dbwrapper.h, try commenting that and see where the errors
562015-10-23T02:02:38 <dcousens> sipa: yeah, quick investigation of the wrapper/adapter pattern is that it is typically applied as a glue code, aka, between two things with their own ownership.
572015-10-23T02:02:50 <dcousens> In this case, its not that, so, anyway. Just food for though
582015-10-23T02:02:52 <dcousens> thought*
592015-10-23T02:03:21 <dcousens> tl;dr EncapsulatedDb would probably be better
602015-10-23T02:03:24 <jcorgan> i'm using b778481
612015-10-23T02:03:39 <jgarzik> jcorgan, git pull
622015-10-23T02:03:56 <CodeShark> HighlyVerboseButGenericNameForDbInterface
632015-10-23T02:04:05 <jgarzik> dbwrapper is just fine, let's move on.
642015-10-23T02:04:10 <sipa> yes, please
652015-10-23T02:04:56 <jcorgan> jgarzik: ok, that fixed it
662015-10-23T02:04:59 <dcousens> jgarzik: well, it causes confusion in anyone who hasn't read through that part of the source. So, IMHO it matters enough to be discussed. But not to block your PR. Moving on :)
672015-10-23T02:05:11 <jcorgan> but to be pedantic, there are a bunch of 'leveldb' strings in the comments :-)
682015-10-23T02:06:03 *** arowser has joined #bitcoin-core-dev
692015-10-23T02:06:22 * jgarzik is focusing on operating stuff, like why this unit test doesn't want to compile my sql
702015-10-23T02:06:30 <jgarzik> *operational
712015-10-23T02:06:54 <jcorgan> no worries. i haven't tested anything, but compiles fine on ubuntu trusty
722015-10-23T02:07:08 <jcorgan> and 6873 is fine
732015-10-23T02:07:34 *** belcher has quit IRC
742015-10-23T02:32:06 <GitHub80> [bitcoin] pstratem opened pull request #6874: Net: Cork socket send writes with MSG_MORE (master...msg_more) https://github.com/bitcoin/bitcoin/pull/6874
752015-10-23T02:32:31 <phantomcircuit> jgarzik, it would be nice if there was a virtual base class
762015-10-23T02:32:48 <phantomcircuit> DBWrapperInterface
772015-10-23T02:33:01 * phantomcircuit goes to look for some InterfaceFactories
782015-10-23T02:37:36 <dcousens> phantomcircuit: if the default is being hard-coded in at each entry anyway
792015-10-23T02:37:40 <dcousens> probably not much point
802015-10-23T02:38:29 <dcousens> unless the wrapper is instantiated at a much earlier point in the program, and passed through. At which point then the generic interface could be used
812015-10-23T02:38:47 <dcousens> s/earlier/higher
822015-10-23T02:38:55 * jgarzik reminds channel: we've moved on
832015-10-23T02:41:30 <phantomcircuit> dcousens, well it's only actually named in one place i think so it doesn't much matter
842015-10-23T02:52:35 <GitHub95> [bitcoin] TheBlueMatt opened pull request #6875: Fix pre-push-hook regexes (master...verify-commits-fixes) https://github.com/bitcoin/bitcoin/pull/6875
852015-10-23T02:54:12 <GitHub11> [bitcoin] TheBlueMatt closed pull request #6875: Fix pre-push-hook regexes (master...verify-commits-fixes) https://github.com/bitcoin/bitcoin/pull/6875
862015-10-23T02:58:47 *** PRab has joined #bitcoin-core-dev
872015-10-23T03:37:35 <phantomcircuit> jgarzik, updated 6874
882015-10-23T04:24:18 *** jgarzik has quit IRC
892015-10-23T04:24:46 *** jgarzik has joined #bitcoin-core-dev
902015-10-23T04:26:28 <phantomcircuit> <phantomcircuit> jgarzik, updated 6874
912015-10-23T04:51:39 *** jl2012 has joined #bitcoin-core-dev
922015-10-23T05:13:54 *** AtashiCon has quit IRC
932015-10-23T05:18:41 *** AtashiCon has joined #bitcoin-core-dev
942015-10-23T05:21:04 <phantomcircuit> possibly we should at least try to reconnect to disconnected peers...
952015-10-23T05:26:28 *** maaku has quit IRC
962015-10-23T05:28:07 *** maaku has joined #bitcoin-core-dev
972015-10-23T05:29:38 *** evoskuil has joined #bitcoin-core-dev
982015-10-23T06:23:50 *** MarcoFalke has joined #bitcoin-core-dev
992015-10-23T06:28:31 *** Thireus has quit IRC
1002015-10-23T06:33:16 *** Ylbam has joined #bitcoin-core-dev
1012015-10-23T06:34:29 *** Thireus has joined #bitcoin-core-dev
1022015-10-23T06:35:14 *** Thireus has quit IRC
1032015-10-23T06:37:59 *** MarcoFalke has quit IRC
1042015-10-23T06:54:34 *** MarcoFalke has joined #bitcoin-core-dev
1052015-10-23T07:26:31 <GitHub136> [bitcoin] laanwj opened pull request #6877: rpc: Add maxmempool and effective min fee to getmempoolinfo (master...2015_10_mempool_effective_fee) https://github.com/bitcoin/bitcoin/pull/6877
1062015-10-23T07:36:27 *** dcousens has quit IRC
1072015-10-23T07:40:48 *** ParadoxSpiral has joined #bitcoin-core-dev
1082015-10-23T07:43:51 *** ParadoxSpiral_ has quit IRC
1092015-10-23T07:54:11 *** CodeShark has quit IRC
1102015-10-23T07:57:50 *** Guest17781 has joined #bitcoin-core-dev
1112015-10-23T07:59:02 *** d_t has quit IRC
1122015-10-23T08:04:40 <GitHub27> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/95a50390e1052a0a501eb446f87d63f58d95b7e7
1132015-10-23T08:04:41 <GitHub27> bitcoin/0.11 95a5039 Gregory Maxwell: Set TCP_NODELAY on P2P sockets....
1142015-10-23T08:04:58 *** BashCo has quit IRC
1152015-10-23T08:11:37 *** Guest17781 has quit IRC
1162015-10-23T08:12:33 <GitHub187> [bitcoin] laanwj pushed 1 new commit to 0.10: https://github.com/bitcoin/bitcoin/commit/5297194bbd6e0d6730515567248caf9c135e296c
1172015-10-23T08:12:33 <GitHub187> bitcoin/0.10 5297194 Gregory Maxwell: Set TCP_NODELAY on P2P sockets....
1182015-10-23T08:22:10 *** BashCo has joined #bitcoin-core-dev
1192015-10-23T08:25:06 *** CodeShark has joined #bitcoin-core-dev
1202015-10-23T08:43:37 *** matsjj_ has joined #bitcoin-core-dev
1212015-10-23T08:46:11 <GitHub44> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2b173acabea...fa1d252e82a8
1222015-10-23T08:46:11 <GitHub44> bitcoin/master 338f62f MarcoFalke: [devtools] add clang-format.py
1232015-10-23T08:46:12 <GitHub44> bitcoin/master 8c15f33 MarcoFalke: [trivial] Update contrib/devtools/README.md
1242015-10-23T08:46:13 <GitHub44> bitcoin/master fa1d252 Wladimir J. van der Laan: Merge pull request #6790...
1252015-10-23T08:46:16 <GitHub153> [bitcoin] laanwj closed pull request #6790: [devtools] add clang-format.py (master...MarcoFalke-2015-clangFormatWrapper) https://github.com/bitcoin/bitcoin/pull/6790
1262015-10-23T08:53:13 *** lightningbot` has quit IRC
1272015-10-23T10:49:43 *** lightningbot has joined #bitcoin-core-dev
1282015-10-23T10:59:30 *** dcousens has quit IRC
1292015-10-23T11:03:27 *** wump is now known as wumpus
1302015-10-23T11:33:36 <GitHub151> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/bf7c1958d199...2a1090d4f55c
1312015-10-23T11:33:37 <GitHub151> bitcoin/master 287f54f Peter Todd: Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic...
1322015-10-23T11:33:38 <GitHub151> bitcoin/master cde7ab2 Peter Todd: Add RPC tests for the CHECKLOCKTIMEVERIFY (BIP65) soft-fork...
1332015-10-23T11:33:38 <GitHub151> bitcoin/master 65ef372 Peter Todd: Add BIP65 to getblockchaininfo softforks list
1342015-10-23T11:34:21 <GitHub0> [bitcoin] laanwj closed pull request #6706: CLTV IsSuperMajority() soft-fork, rebased against v0.10.2 (0.10...cltv-soft-fork-v0.10) https://github.com/bitcoin/bitcoin/pull/6706
1352015-10-23T11:34:30 * btcdrak jumps for joy
1362015-10-23T11:57:25 <GitHub121> [bitcoin] laanwj opened pull request #6879: doc: mention BIP65 softfork in bips.md (master...2015_10_bip65) https://github.com/bitcoin/bitcoin/pull/6879
1372015-10-23T12:36:17 *** danielsocials has joined #bitcoin-core-dev
1382015-10-23T12:41:52 <GitHub155> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2a1090d4f55c...c719cefc417c
1392015-10-23T12:41:52 <GitHub155> bitcoin/master d3b09f6 Alex Morcos: Do not allow blockfile pruning during reindex....
1402015-10-23T12:41:53 <GitHub155> bitcoin/master c719cef Wladimir J. van der Laan: Merge pull request #6856...
1412015-10-23T12:41:57 <GitHub81> [bitcoin] laanwj closed pull request #6856: Do not allow block file pruning during reindex. (master...noPruneDuringReindex) https://github.com/bitcoin/bitcoin/pull/6856
1422015-10-23T12:42:35 <GitHub177> [bitcoin] laanwj pushed 1 new commit to 0.11: https://github.com/bitcoin/bitcoin/commit/dfe55bdc32b5333dcce1a7f2c74628f64028d1fe
1432015-10-23T12:42:35 <GitHub177> bitcoin/0.11 dfe55bd Alex Morcos: Do not allow blockfile pruning during reindex....
1442015-10-23T12:51:48 *** treehug8_ has joined #bitcoin-core-dev
1452015-10-23T13:09:10 <GitHub89> [bitcoin] jgarzik pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/c719cefc417c...46f74379b86b
1462015-10-23T13:09:11 <GitHub89> bitcoin/master 6ec4b7e Jeff Garzik: leveldbwrapper: Remove unused .Prev(), .SeekToLast() methods...
1472015-10-23T13:09:11 <GitHub89> bitcoin/master 8587b23 Jeff Garzik: leveldbwrapper symbol rename: Remove "Level" from class, etc. names
1482015-10-23T13:09:12 <GitHub89> bitcoin/master 3795e81 Jeff Garzik: leveldbwrapper file rename to dbwrapper.*
1492015-10-23T13:09:17 <GitHub179> [bitcoin] jgarzik closed pull request #6873: [cleanup] leveldbwrapper becomes more generic 'dbwrapper' module (master...2015_dbwrapper) https://github.com/bitcoin/bitcoin/pull/6873
1502015-10-23T13:20:09 *** harding has joined #bitcoin-core-dev
1512015-10-23T13:31:09 *** treehug8_ has quit IRC
1522015-10-23T13:35:17 *** treehug8_ has joined #bitcoin-core-dev
1532015-10-23T13:49:46 *** rubensayshi has quit IRC
1542015-10-23T15:06:29 *** treehug8_ has quit IRC
1552015-10-23T15:08:00 *** dgenr8 has joined #bitcoin-core-dev
1562015-10-23T15:12:36 *** treehug8_ has joined #bitcoin-core-dev
1572015-10-23T15:23:51 <GitHub199> [bitcoin] gavinandresen opened pull request #6880: New -logtimerelative option to do millisec debug.log timestamps (master...millisec_debuglog) https://github.com/bitcoin/bitcoin/pull/6880
1582015-10-23T15:30:30 *** sdaftuar has quit IRC
1592015-10-23T15:30:42 *** morcos has quit IRC
1602015-10-23T15:31:01 *** zxzzt_ has quit IRC
1612015-10-23T15:32:27 *** morcos has joined #bitcoin-core-dev
1622015-10-23T15:32:33 *** sdaftuar has joined #bitcoin-core-dev
1632015-10-23T15:33:15 *** zxzzt has joined #bitcoin-core-dev
1642015-10-23T15:40:50 *** randy-waterhouse has quit IRC
1652015-10-23T15:41:27 *** d_t has joined #bitcoin-core-dev
1662015-10-23T15:49:08 *** maaku__ is now known as maaku
1672015-10-23T15:58:36 *** danielsocials has quit IRC
1682015-10-23T16:22:38 <GitHub54> [bitcoin] gavinandresen closed pull request #6880: New -logtimerelative option to do millisec debug.log timestamps (master...millisec_debuglog) https://github.com/bitcoin/bitcoin/pull/6880
1692015-10-23T16:54:54 *** BashCo has quit IRC
1702015-10-23T16:55:23 *** matsjj_ has quit IRC
1712015-10-23T16:59:15 *** gmaxwell has joined #bitcoin-core-dev
1722015-10-23T17:17:10 *** BashCo has joined #bitcoin-core-dev
1732015-10-23T18:07:02 *** fkhan has quit IRC
1742015-10-23T18:21:19 *** fkhan has joined #bitcoin-core-dev
1752015-10-23T18:23:47 <GitHub0> [bitcoin] sdaftuar opened pull request #6881: Debug: Add option for microsecond precision in debug.log (master...add-microsecond-timestamps) https://github.com/bitcoin/bitcoin/pull/6881
1762015-10-23T18:25:20 *** Dyanisus has joined #bitcoin-core-dev
1772015-10-23T18:26:06 <maaku> I am leaving bitcoin core development for a while, not sure how long. If someone wants to take over pushing for #6312, #6564, and #6566 please contact me.
1782015-10-23T18:26:52 <Dyanisus> why you leaving?
1792015-10-23T18:27:04 <btcdrak> maaku: why are you leaing?
1802015-10-23T18:27:19 <btcdrak> maaku: we're literally right at the end!
1812015-10-23T18:28:35 *** randy-waterhouse has joined #bitcoin-core-dev
1822015-10-23T18:28:44 <Dyanisus> maaku: did you get some sort of subpoena or something?
1832015-10-23T18:30:23 *** CodeShark_ has joined #bitcoin-core-dev
1842015-10-23T18:35:55 <btcdrak> maaku: I've sent you an email about those PRs.
1852015-10-23T18:52:30 *** molly has quit IRC
1862015-10-23T19:09:07 *** fkhan has quit IRC
1872015-10-23T19:13:23 *** CodeShark_ has quit IRC
1882015-10-23T19:26:18 *** fkhan has joined #bitcoin-core-dev
1892015-10-23T19:47:22 *** Guest89666 is now known as pigeons
1902015-10-23T19:49:36 *** CodeShark has quit IRC
1912015-10-23T20:02:56 *** randy-waterhouse has quit IRC
1922015-10-23T20:16:35 *** treehug8_ has quit IRC
1932015-10-23T20:17:12 <GitHub65> [bitcoin] petertodd opened pull request #6883: Add BIP65 CHECKLOCKTIMEVERIFY to release notes (master...cltv-release-notes-v0.12.0) https://github.com/bitcoin/bitcoin/pull/6883
1942015-10-23T20:21:09 <GitHub95> [bitcoin] btcdrak opened pull request #6884: Backport #6566, median-past locktime, rebased against 0.11 (0.11...mpl-0.11) https://github.com/bitcoin/bitcoin/pull/6884
1952015-10-23T20:28:44 *** dhill has joined #bitcoin-core-dev
1962015-10-23T20:28:47 <dhill> maaku: hi
1972015-10-23T20:29:56 <dhill> maaku: regarding checksequenceverify, i ran your tests against btcd, and they all pass
1982015-10-23T20:29:57 <dhill> but
1992015-10-23T20:30:03 <dhill> + if (txToSequence & CTxIn::SEQUENCE_LOCKTIME_DISABLED_FLAG)
2002015-10-23T20:30:03 <dhill> + return false;
2012015-10-23T20:30:09 <dhill> was not hit
2022015-10-23T20:30:19 <dhill> i think there is a dup test in tx_invalid.json
2032015-10-23T21:21:03 *** belcher has joined #bitcoin-core-dev
2042015-10-23T21:43:25 *** davec has joined #bitcoin-core-dev
2052015-10-23T21:50:36 *** molly has joined #bitcoin-core-dev
2062015-10-23T21:59:55 <maaku> I added btcdrak as a collaborator for my personal repo, so he should be able to update the 'sequencenumbers' 'checksequenceverify' and 'medianpastlocktime' branches
2072015-10-23T22:32:22 <btcdrak> maaku: thanks!
2082015-10-23T23:11:07 *** belcher has quit IRC
2092015-10-23T23:14:21 *** belcher has joined #bitcoin-core-dev
2102015-10-23T23:30:18 <cfields> sipa: ping. I'm trying to understand the current dnsseed thread behavior. It looks like in the non-proxied case, we resolve all seed nodes and add them to addrman without testing them. In the proxied case, we connect to each resolved entry as a oneshot...
2112015-10-23T23:30:51 <cfields> i assume the goal is to query them all once if possible in order to never have to touch 'em again?
2122015-10-23T23:32:23 <cfields> just seems a bit unbalanced between the proxy/non-proxy cases, want to be sure i'm not missing anything in the big picture
2132015-10-23T23:39:41 * jgarzik wonders about the proxy case behavior
2142015-10-23T23:40:34 <jgarzik> cfields, The add-untested logic follows the getaddr logic, where it is unknown possibly garbage data coming in from unknown sources
2152015-10-23T23:40:56 <jgarzik> cfields, overall I do think addrman must do a much better job of testing and expiring bad addresses
2162015-10-23T23:41:49 <jgarzik> cfields, notably we engage in the poor network behaviors of (1) propagating known bad addresses and (2) repeatedly trying the same dead nodes, in some near-empty-bucket edge cases
2172015-10-23T23:44:34 <gmaxwell> The proxy behavior is simply because we cannot do the dns lookup via the proxy. So connecting to the addresses returned (by proxy connecting to the names) was the best thing we could do.
2182015-10-23T23:44:40 <cfields> jgarzik: ok, that lines up with how i read it. Looks like in the proxied case where we can't run a query, we just connect to all reachable nodes (query done through the proxy), getaddr on them, and disconnect. seems to me like that'd yield less garbage, but i suppose you're right about letting addrman do it.
2192015-10-23T23:44:45 <gmaxwell> It does a less good job of initilizing the state for sure.
2202015-10-23T23:45:25 <gmaxwell> not to all reachable nodes, we connect 'to' each dnsseed by name (meaning connect to one of the results of it).
2212015-10-23T23:45:41 <cfields> gmaxwell: less good because the dns seeds tend to be much fresher, i assume?
2222015-10-23T23:46:05 <jgarzik> dns seeds are fresh and quick and easy and wonderfully centralizing ;p
2232015-10-23T23:46:11 <gmaxwell> cfields: no, just less good because it any one of the dnsseed results could be broken or malicious.
2242015-10-23T23:46:39 <cfields> gmaxwell: ah right, only one-per-seed that way.
2252015-10-23T23:46:45 <jgarzik> notably there is now code that "waits a bit, before checking seeds" to attempt to P2P without DNS seeds
2262015-10-23T23:46:47 <gmaxwell> e.g. dns seed returns nodes a,b,c,d,e,f,g ... and we only end up connecting to g (out of that dns seed's results) and perhaps g gives us useless answers.
2272015-10-23T23:46:59 <jgarzik> so DNS seeding is intentionally not immediate
2282015-10-23T23:47:13 <cfields> ok, all clear now. thanks.
2292015-10-23T23:49:36 <cfields> ok, along those lines, are there concerns (fingerprinting) about hitting the seeds too quickly or uniformly? I don't see any active approach in the current code to avoid that
2302015-10-23T23:50:40 <jgarzik> cfields, sure those concerns exist
2312015-10-23T23:50:55 <jgarzik> cfields, that's part of the reason why the current code tries to avoid DNS lookups
2322015-10-23T23:51:10 <jgarzik> cfields, a DNS seed can build a picture of bitcoin users etc.
2332015-10-23T23:52:02 *** Luke-Jr has quit IRC
2342015-10-23T23:52:31 <jgarzik> cfields, Current logic is: (1) if addrman.size() > 0, Attempt to connect to network given current peer database (2) If "too few" P2P connections after 11 seconds, perform DNS lookup.
2352015-10-23T23:52:34 <cfields> obviously not worried about the seeds themselves, since they're already trusted. more about someone trying to get 2+ entries in a seed's current entries in order to distinguish individuals
2362015-10-23T23:52:43 <gmaxwell> cfields: DNS seeds are prohibited by policy from having a TTL less than 60 seconds, so recursive resolution provides some increase in privacy.
2372015-10-23T23:53:12 <jgarzik> I think it's quite likely that a single DNS seed might spit out two addresses which are in fact controlled by one person/org
2382015-10-23T23:53:32 <gmaxwell> it's almost certan. well plus a substantial number of nodes on the network are sybil attackers in any case.
2392015-10-23T23:53:35 <gmaxwell> :P
2402015-10-23T23:53:52 <cfields> jgarzik: sure, i'm speaking of the procedure when we do fall into the dns lookup logic.
2412015-10-23T23:54:34 <jgarzik> sure. the logic is dumb: query all DNS seeds, let addrman sort it out
2422015-10-23T23:55:03 <gmaxwell> cfields: addrman knows where addresses came from to e.g. prevent any one source from dominating the table. There is only so much it can do.
2432015-10-23T23:55:10 <cfields> ok. no problem with that, just want to be sure i'm understanding the logic that's there
2442015-10-23T23:55:22 <gmaxwell> Lack of actual users running nodes provides a very limiting upper bound on how much protection is possible.
2452015-10-23T23:57:30 <cfields> got it. thanks jgarzik/gmaxwell.
2462015-10-23T23:58:40 *** Luke-Jr has joined #bitcoin-core-dev