1 2015-10-26 00:22:54 <btcdrak> BlueMatt: it was a mistake, the list was not set to moderate new subscribers. Fixed now.
 2 2015-10-26 12:20:16 <btcdrak> Luke-Jr: what is the URL for your node statistics page?
 3 2015-10-26 15:12:51 <bsm1175321> Now that upnp has been disabled by default, what is the longer term development plan for NAT traversal?
 4 2015-10-26 15:15:30 <wumpus> https://bitcoin.org/en/full-node#network-configuration
 5 2015-10-26 15:16:43 <bsm1175321> I was hoping for a better answer than "let node operators figure it out..."
 6 2015-10-26 15:18:00 <wumpus> note that enabling upnp is still a possibility, it's just not enabled by default, so that it is not an automatic risk
 7 2015-10-26 15:19:08 <bsm1175321> Given that the relevant library is fixed, why was the decision made to make upnp disabled by default in addition?
 8 2015-10-26 15:19:22 <wumpus> another viable option for NAT traversal is running a Tor hidden service
 9 2015-10-26 15:19:26 <wumpus> less structural risk
10 2015-10-26 15:21:30 <wumpus> they solved one security issue, there's probably a few left. Better to not couple bitcoin's security tightly to a library with questionable security practices
11 2015-10-26 15:22:48 <wumpus> also it's not really much of a problem for the users themselves to not have an incoming port. Arguably it should be a decision to allow incoming connections
12 2015-10-26 15:23:28 <bsm1175321> FYI, I'm thinking about this because one of my co-workers made the statement that bitcoin's up/down bandwidth usage is 5:1 -- and I'm wondering why this is the case, whether it's a problem, and I will make some measurements. If true, it could be a bunch of NAT'ed nodes.  Anyone else seen this?
13 2015-10-26 15:24:38 <wumpus> bitcoind using too much upload bandwidth is a well-known problem
14 2015-10-26 15:24:49 <wumpus> see e.g. https://github.com/bitcoin/bitcoin/pull/6622 for a mitigation
15 2015-10-26 15:25:54 <bsm1175321> Hmmm.  Just blocking the uploads isn't really a solution.  Why is it happening in the first place?
16 2015-10-26 15:25:57 <wumpus> the reason is serving historical blocks. This shouldn't be an issue if you're behind NAT and not using some kind of NAT traversal though
17 2015-10-26 15:26:29 <wumpus> it's a solution for the users whose connection is overloaded. Otherwise they'll likely stop running a node completely.
18 2015-10-26 15:27:46 <wumpus> e.g. you should be able to run a node for yourself without offering up your entire internet connection for other people's benefit
19 2015-10-26 15:33:10 <gmaxwell> bsm1175321: it was disabled by default for bitcoind for years without issue.  One does not need nat traversial to use bitcoin.
20 2015-10-26 15:34:44 <bsm1175321> Agreed.  My concern is there is another problem causing re-download of blocks.  e.g. people are trying to start bitcoin nodes and failing to get to the latest chain tip. Personally I had to do a -reindex this weekend because I was forked off the chain, and this has happened to me repeatedly.
21 2015-10-26 15:35:31 <bsm1175321> So if this is a common occurrence, we might be able to detect it and do partial reindexing to get back on the main chain.
22 2015-10-26 15:35:35 <jouke> .
23 2015-10-26 15:35:58 <jouke> whoops, don't mind my dot.
24 2015-10-26 15:36:44 <bsm1175321> Last time it happened to me, I identified some bad RAM.  There are probably lots of ways commodity hardware screws up one sha256 or ECC validation.
25 2015-10-26 15:37:33 <bsm1175321> But as long as it's rare and not systematic, we could fix it in core.
26 2015-10-26 15:37:56 <bsm1175321> Has anyone done measurements of *which* blocks are being downloaded?
27 2015-10-26 15:39:25 <gmaxwell> bsm1175321: a considerable amount of bandwidth is used by lite clients scanning blocks rather than actual downloads.
28 2015-10-26 17:40:45 <gmaxwell> "The moral to the story: we need better benchmarking, especially of the networking code, to make sure that changes meant to improve performance (like headers-first) don't accidentally make something slower."  headers first was benchmarked in terms of not making things slower, and _didn't_, and still doesn't: it's not used for blocks on the tip.
29 2015-10-26 17:40:52 <gmaxwell> gavinandresen: ^
30 2015-10-26 18:10:03 <wumpus> huh, who is claiming that headers-first made things slower?!
31 2015-10-26 18:10:47 <wumpus> the gains were impressive, it's not like no one measured
32 2015-10-26 18:13:04 <sipa> wumpus: talking about relay speed here, not ibd
33 2015-10-26 18:13:34 <sipa> where in theory it should not have made any difference
34 2015-10-26 18:13:58 <wumpus> ok
35 2015-10-26 18:17:08 <gmaxwell> wumpus: context is https://www.reddit.com/r/bitcoinxt/comments/3q9bof/now_there_is_one_one_less_reason_to_limit/cwdat6x
36 2015-10-26 18:17:24 <wumpus> I don't visit reddit
37 2015-10-26 18:17:48 <wumpus> iptables -A OUTPUT -d www.reddit.com -j DROP   # sanity filter
38 2015-10-26 19:32:34 <Luke-Jr> btcdrak: http://luke.dashjr.org/programs/bitcoin/files/charts/
39 2015-10-26 19:34:39 <phantomcircuit> gmaxwell, i like how it's got your picture
40 2015-10-26 19:34:47 <btcdrak> Luke-Jr: thx
41 2015-10-26 19:35:57 <btcdrak> Luke-Jr: there's no more visualisation of node user-agents in a pie chart?
42 2015-10-26 19:36:33 <Luke-Jr> ?
43 2015-10-26 19:36:40 <Luke-Jr> I've not removed anything
44 2015-10-26 19:44:29 <btcdrak> maybe I am misremembering what was there
45 2015-10-26 19:44:54 <btcdrak> bitnodes is down more than it's up since 21Inc took it over..
46 2015-10-26 19:45:47 <CodeShark> lol
47 2015-10-26 19:46:32 <CodeShark> the irony is awe-inspiring
48 2015-10-26 20:04:30 <btcdrak> 21 could be the next BC.i at this rate
49 2015-10-26 20:42:30 <phantomcircuit> btcdrak, im guessing they moved a bunch of infrastructure