1 2014-12-28 00:13:16 <sibiria> hi. what is the rationale behind connecting only to one peer per /16 network group?
  2 2014-12-28 00:13:57 <sibiria> one peer per /8 is a no-brainer, but i can't wrap my head around /16
  3 2014-12-28 00:14:11 <michagogo> sibiria: per /8?
  4 2014-12-28 00:14:49 <michagogo> Too restrictive, probably
  5 2014-12-28 00:15:23 <phantomcircuit> sibiria, /16 is wide enough to catch most allocations and narrow enough not to cause issues
  6 2014-12-28 00:20:04 <sibiria> phantomcircuit: one per /16 seems like a way too large gauge. are there any graphs done one discarded vs connectable nodes from /16? what are the supposed issues with goign with a /8 target?
  7 2014-12-28 00:21:07 <gmaxwell> sibiria: If the restriction is to ogreat it makes life easier for an attacker. E.g. with a little bit of effort you can be much more /8 diverse than the honest network is on average.
  8 2014-12-28 00:21:22 <gmaxwell> This is less true for the /16 bottleneck.
  9 2014-12-28 00:21:25 <sipa> we only make 8 outgoing connections anyway
 10 2014-12-28 00:21:45 <sipa> and the requirement is basically being connected to at least one honest network node
 11 2014-12-28 00:21:47 <gmaxwell> s/ogreat/great/
 12 2014-12-28 00:22:01 <sipa> there are plenty of /16's with bitcoin nodes to pick from still
 13 2014-12-28 00:22:39 <sipa> controlling different /8's is easy for an attacker
 14 2014-12-28 00:23:11 <sibiria> as said, why not /8 is a no-brainer
 15 2014-12-28 00:23:11 <sipa> controlling 8 different /16's is much harder
 16 2014-12-28 00:23:29 <sipa> wait, i'm confusing /8 with /24
 17 2014-12-28 00:25:14 <sibiria> any plans on introducing a tunable value for the amount of outgoing connections?
 18 2014-12-28 00:26:56 <sipa> No.
 19 2014-12-28 00:28:10 <sibiria> given the network's growth, it happens often that you connect to 8 burdened nodes delivering untimely block updates
 20 2014-12-28 00:28:49 <sibiria> i noticed this a while ago on a very large altcoin, so i decided to try the same on the bitcoin network, and the occurance was more prevalent there
 21 2014-12-28 00:29:13 <sibiria> i thought it wouldn't be a big problem given the long 10 min. block target, but i was wrong
 22 2014-12-28 00:34:10 <gmaxwell> sibiria: I don't believe thats correct. It certantly doesn't match my observations.
 23 2014-12-28 00:35:25 <sibiria> it stands true primarily due to the fact the vast majority of connections in the network are wallets, not nodes. upnp doesn't seem to counter this too much
 24 2014-12-28 00:35:33 <gmaxwell> Or cdecker's, which observes 500th percentile propagation in about 5 seconds.
 25 2014-12-28 00:36:16 <gmaxwell> sibiria: It's unclear what you're talking about with "wallets, not nodes"; you won't ever be connecting inbound with something that isn't a node.
 26 2014-12-28 00:39:10 <sibiria> a node that listens to incoming connections, contra, say, a service setting listen to 0 to avoid being encumbered
 27 2014-12-28 00:40:37 <gmaxwell> You're certantly not ever connecting inbound to something that doesn't accept inbound connections.
 28 2014-12-28 00:41:02 <sibiria> of course
 29 2014-12-28 00:41:10 <sibiria> that should obvious from the term "node"
 30 2014-12-28 00:41:33 <sibiria> if it doesn't service incoming requests it isn't helping the network as much as it could
 31 2014-12-28 00:41:42 <sipa> i'm not sure what you're talking about
 32 2014-12-28 00:41:59 <sipa> you're not ever connecting to a wallet which does not function as a full node
 33 2014-12-28 00:42:11 <sipa> (you may accept connections from them, of course)
 34 2014-12-28 00:42:24 <sipa> but the outgoing connections are always to full nodes, which should help relaying
 35 2014-12-28 00:42:25 <sibiria> no one ever said so, so i'm not sure why you are stating this
 36 2014-12-28 00:42:28 <gmaxwell> In any case, as mentioned observed propagation times in bitcoin at about 5 seconds to all reachable nodes in the 50-th percentile, about 20 seconds in the 90-th percentile.   The probablity that you pick 8 nodes who are all in the last 10percent is very low. so low that there is only a 1:10000 chance than even a single node out of 10000 is in that state.
 37 2014-12-28 00:42:31 <sibiria> yes - but just 8 of them
 38 2014-12-28 00:42:55 <sibiria> with no way of estimating whether they are permanently overburdened, or able to relay transactions and blocks timely
 39 2014-12-28 00:43:40 <gmaxwell> sibiria: if they're overloaded and not timely they'll simply tell us about new blocks later than our other peers and we will not use them.
 40 2014-12-28 00:43:41 <sipa> strongly selecting for connections with fast relay times means you end up with a more easily partitioned network
 41 2014-12-28 00:43:48 <sibiria> gmaxwell: was cdecker's result posted anywhere for studying?
 42 2014-12-28 00:44:39 <sibiria> sipa: i don't get why point that out when you cannot estimate a node's responsiveness at any given point in time
 43 2014-12-28 00:45:19 <gmaxwell> sibiria: you keep repeating that but it doesn't make any sense. The peers actual behavior is an instantanious measurement of it's responsiveness.
 44 2014-12-28 00:45:49 <sipa> sibiria: the peer that gives you a new valid block first is likely the most responsive/nearby one
 45 2014-12-28 00:45:53 <gmaxwell> When a new block shows up its existance is flooded through the network. We fetch the block from the first peer to tell us about it.
 46 2014-12-28 00:46:30 <sipa> sibiria: that's enough as a measurement; if at every block you would disconnect the last peer to tell you about it, and randomly pick a new one to connect to instead, we'd end up with a *very* clustered network
 47 2014-12-28 00:46:32 <gmaxwell> 7 of our peers might have mysteriously become slow just nanoseconds before; and yet we'll still manage to get performance only bounded by the fastest peer.
 48 2014-12-28 00:47:02 <sibiria> are you implying that the btc core does filter out slower nodes?
 49 2014-12-28 00:47:04 <sipa> sibiria: anyway, i'm not sure what you're saying; just that we should connect to more peers? i don't believe that's valuable at all
 50 2014-12-28 00:47:21 <gmaxwell> sibiria: no, we are saying that it doesn't have to.
 51 2014-12-28 00:47:22 <sipa> sibiria: no, we don't do that; i'm just saying that we easily could - but that it could also easily be a very bad thing to do
 52 2014-12-28 00:47:34 <sibiria> sipa: yes i agree
 53 2014-12-28 00:47:47 <sibiria> gmaxwell: is his test results available anywhere for reading?
 54 2014-12-28 00:47:49 <sibiria> cdecker's
 55 2014-12-28 00:47:56 <gmaxwell> and right, Pieter is saying that doing so would be very harmful to the topology because it would make the network easily partitioned (or even self partitioning)
 56 2014-12-28 00:48:05 <gmaxwell> sibiria: probably.
 57 2014-12-28 00:48:17 <gmaxwell> sibiria: I am confused as to why you're claiming otherwise?
 58 2014-12-28 00:48:19 <sipa> that does not mean that measuring responsiveness of peers is a bad idea (we actually already measure ing times)
 59 2014-12-28 00:48:58 <sipa> but it's hard to find a balance between optimizing for relay speed and preventing (accidental or intentional) partitioning of the network
 60 2014-12-28 00:49:04 <sibiria> i have no opinion regarding the responsiveness of peers. it's a natural coincidence that some may be heavily burdened
 61 2014-12-28 00:49:11 <gmaxwell> The fetching process is itself self-calibrating. It uses the announcement time to control where it fetches from.  This just doesn't change the topography.
 62 2014-12-28 00:49:34 <sipa> yup, some may be burdened, some of the time
 63 2014-12-28 00:49:40 <sipa> some may even be burdened all of the time
 64 2014-12-28 00:49:45 <sipa> unlikely that all are :)
 65 2014-12-28 00:50:16 <sibiria> and with only 8 outgoing connections, the chances of hitting just burdened peers is larger than letting the user tune to f.e. 12 or 16 outgoing connections
 66 2014-12-28 00:50:27 <gmaxwell> sibiria: it doesn't matter if some are heavily burdened. We are only slowed if all our peerrs are heavily burened. E.g. so if there is a 10% chance a random peer is burdened, the probablity that all our peers are burdened is very low.
 67 2014-12-28 00:50:37 <sibiria> and the risk grows larger in sync with the network, unless dedicated nodes magically appear at the same rate users do
 68 2014-12-28 00:51:06 <sipa> do you have some numbers that show this?
 69 2014-12-28 00:52:06 <gmaxwell> sibiria: static overhead increases dramatically with higher fanout levels. (because you have more data crossing in flight)
 70 2014-12-28 00:53:53 <sibiria> the chance is obvious on its own, but no numbers right now, no. when i went to test this on the bitcoin network with its longer block target i manually checked transactions and block updates against the largest btc hub i know (blockchain.info). the most i noticed on a fresh restart (no cached peers) of bitcoind was close to 40 seconds delay
 71 2014-12-28 00:54:15 <sibiria> usually pretty much instantaneous
 72 2014-12-28 00:54:15 <sipa> heh
 73 2014-12-28 00:54:23 <sipa> please, don't base any research on blockchain.info
 74 2014-12-28 00:54:55 <sibiria> despite how burdened it is, it's a decent metric for block propagation considering the amount of nodes it is hooked up to
 75 2014-12-28 00:54:57 <sipa> they don't run standard software, they have returned totally bogus data in the past, and generally provide misinformed data
 76 2014-12-28 00:55:30 <sibiria> the point remains: i measured a 40 second delay in getting a block compared to even the wonky, dodgy blockchain.info
 77 2014-12-28 00:55:47 <sibiria> if i had thrown out 12 or 16 outgoing connections, the risk of hitting burdened nodes would have decreased
 78 2014-12-28 00:55:59 <phantomcircuit> sibiria, they've actually partitioned themselves from the rest of the network a number of times in the past
 79 2014-12-28 00:56:24 <sipa> you say 'decreased' and i don't disagree
 80 2014-12-28 00:57:09 <sipa> but without numbers there is no way to tell whether this is a reasonable thing to do, compared the pretty huge extra cost (in terms of bandwidth and cpu, and even slower relay because of more messages being processed all the time)
 81 2014-12-28 00:57:10 <sibiria> anyway, it is no criticism, just wondering if this had been brought up
 82 2014-12-28 00:57:23 <sibiria> sipa: yes but this is up to the user
 83 2014-12-28 00:57:29 <sibiria> the default of 8 outgoing connections is perfectly fine
 84 2014-12-28 00:57:35 <sibiria> but the user could be allowed to tune this
 85 2014-12-28 00:57:41 <sipa> understand that several people here have seen bitcoin go through the time when bitcoin ran out of connectable peers
 86 2014-12-28 00:57:46 <sibiria> there is after all a max connections setting already, at 125 or 150 or however much
 87 2014-12-28 00:57:54 <sipa> if you allow the user to tune this, they'll all set it to the maximum
 88 2014-12-28 00:58:02 <sibiria> why would they?
 89 2014-12-28 00:58:09 <sipa> because more connections is better right?
 90 2014-12-28 00:58:17 <gmaxwell> sibiria: it's important that they do not, in fact, because the setting is subtle and easily misunderstood, and many users setting it high would be _greatly_ damanging to the network.
 91 2014-12-28 00:58:21 <sipa> (i'm being sarcastic, it's generally worse - even for just them)
 92 2014-12-28 00:58:23 <sibiria> with that narrow logic, all users will be setting maxconnections to way beyond the default as well
 93 2014-12-28 00:58:26 <sibiria> yet, they aren't
 94 2014-12-28 00:59:00 <sibiria> there is something to be considered from the choice of having a maxconnections value defaulting to 125
 95 2014-12-28 00:59:04 <dgenr8> sibiria: http://bitcoinstats.com/network/propagation/ (cdecker)
 96 2014-12-28 00:59:16 <sibiria> either you assume the network will never face this, or you assume no one knows what the setting is or how to increase it
 97 2014-12-28 00:59:32 <sibiria> dgenr8: ah, thanks man
 98 2014-12-28 00:59:44 <sipa> well it results from local resources... extra connections take extra CPU and RAM
 99 2014-12-28 01:00:01 <gmaxwell> an example of that misunderstanding "How does one attain 1,000+ connections" ... "Why?! Why not should be the real question! If you must know, I want to have the most verified blockchain in the world." http://bitcoin.stackexchange.com/questions/8109/how-does-one-attain-1-000-connections-like-blockchain-info
100 2014-12-28 01:00:20 <sipa> gmaxwell: heh, was searching for that exact same question :)
101 2014-12-28 01:00:33 <sibiria> if we allow a node to accept 125 connections in total (by default; still possible to increase), then we have already graced them with this potential burden
102 2014-12-28 01:00:49 <sibiria> each node is by its own already protected by this number, decided by developers
103 2014-12-28 01:00:55 <sipa> fair enough, i agree
104 2014-12-28 01:01:02 <gmaxwell> I don't agree.
105 2014-12-28 01:01:06 <dgenr8> there may be "slow nodes" and "fast nodes" but likely at least as much variability comes from where the inventory is introduced, and random effects
106 2014-12-28 01:01:13 <sipa> though most end users don't end up with many connections, due to being badly reachable
107 2014-12-28 01:01:15 <gmaxwell> It's not simply about protecting the node of that burden, it's about protecting the network.
108 2014-12-28 01:01:28 <sibiria> sipa: that is one of my points
109 2014-12-28 01:01:53 <sibiria> gmaxwell: if you want to protect the network with this logic, you need to also lower the default of maxconnections, as well as prevent the user from increasing it
110 2014-12-28 01:02:07 <gmaxwell> Unbounded fanout degree increases overhead. If the degree was unbounded the cost of a new message in the network is quadratic in the number of participants instead of linear (with a bounded degree).
111 2014-12-28 01:02:11 <sipa> sibiria: maxconnections only protects the local user's node
112 2014-12-28 01:02:26 <sibiria> sipa: of course
113 2014-12-28 01:02:32 <gmaxwell> sibiria: That isn't the case.
114 2014-12-28 01:02:34 <sipa> sibiria: more total connections on the network takes up available connection slots, which is for network protection
115 2014-12-28 01:03:39 <sibiria> it's not about the maxconnections default, or the fact that the user may tune it indefinitely
116 2014-12-28 01:03:51 <gmaxwell> in any case, it seems you have done little research and no measurement; and you're taking your narroly formed opinions as axioms. This isn't helpful.
117 2014-12-28 01:04:13 <sibiria> the "research" is from practical testing
118 2014-12-28 01:04:14 <gmaxwell> The maximum inbound socket does not have anything to do with the _outbound_ degree of nodes in the network.
119 2014-12-28 01:04:23 <sibiria> i know that
120 2014-12-28 01:04:28 <sipa> sibiria: if you've only tested again blockchain.info, sorry, repeatr
121 2014-12-28 01:04:35 <sipa> that's not representative of the network
122 2014-12-28 01:05:04 <gmaxwell> It wasn't clear precisely what your test was, other than it involved blockchain.info.
123 2014-12-28 01:05:20 <sibiria> i think i explained it pretty well above
124 2014-12-28 01:05:33 <dgenr8> for that matter cdecker's methodology is not that transparent either
125 2014-12-28 01:05:48 <sibiria> delete peer cache, start bitcoind with -blocknotify up to check block arrival
126 2014-12-28 01:05:55 <gmaxwell> dgenr8: it's pretty transpartent, I mean he wrote a fucking academic paper on it.
127 2014-12-28 01:06:15 <gmaxwell> sibiria: "delete peer cache"?
128 2014-12-28 01:06:15 <sibiria> see how much longer it may take for me to get a block with only 8 outgoing connections compared to another known large hub (blockchain.info was my choice)
129 2014-12-28 01:06:31 <sibiria> at most, i measured 40 seconds later for a block to show at my end than blockchain.info
130 2014-12-28 01:07:16 <sibiria> i am but a poor plebeian, so i had no BTC to test for tx relaying as well - thankfully block relays are free ;P
131 2014-12-28 01:07:17 <dgenr8> well that sure demands I take another look
132 2014-12-28 01:07:19 <gmaxwell> sibiria: How did you measure this difference?
133 2014-12-28 01:07:44 <gmaxwell> e.g. how did you determine when the two times occured? (what was the clock)
134 2014-12-28 01:08:10 <sibiria> gmaxwell: on my end timestamping from the script i call with -blocknotify, on blockchain.info's end just visually by keeping an eye
135 2014-12-28 01:08:19 <gmaxwell> Also, why do you consider 40 seconds concerning? (though indeed it's high... part of it would be that you would have a cold cache, block notify fires only after you've verified the block which is going to take several seconds because of your cold cache)
136 2014-12-28 01:08:32 <sibiria> it's high but no, not concering
137 2014-12-28 01:08:39 <sibiria> especially not with 10 minutes being the block timer
138 2014-12-28 01:08:44 <gmaxwell> sibiria: oh come on "by vistually keeping an eye" you made a statistically relevant measurment of 40 seconds?
139 2014-12-28 01:09:12 <sibiria> gmaxwell: are you doubting an actual block popping up on blockchain.info as an erroneous block?
140 2014-12-28 01:09:44 <gmaxwell> sibiria: Can't parse that statement.
141 2014-12-28 01:09:58 <sibiria> if i see 336xxx popping up there we can safely assume block 336xxx was indeed added to the chain
142 2014-12-28 01:10:09 <sibiria> sure, some fluke may occur, but one did not
143 2014-12-28 01:10:50 <sibiria> my point is... as the btc network explodes in size, these 40 seconds may one day be 1 minute, or one and a half minute
144 2014-12-28 01:11:03 <sibiria> this could be a problem for services that do not listen for incoming connections
145 2014-12-28 01:11:15 <sibiria> making just outgoing connections for getting tx and block relays
146 2014-12-28 01:11:31 <gmaxwell> May be a different block; but thats besides the point. I'm doubting the number of significant figures of an measurement by eyeball for an event that happens once every 10 minutes on average.
147 2014-12-28 01:11:33 <sibiria> i get that 10 minutes is a pretty good grace period against a measure mere 40 seconds, but...
148 2014-12-28 01:12:07 <gmaxwell> sibiria: we haven't seen any scale dependance on that number over time.
149 2014-12-28 01:12:26 <sibiria> gmaxwell: why doubt it? a legit block is added to the chain, it appears on bc.info and i don't get the block for another 40 seconds on my end. i know the block was added, but did not propagate to me until 40s later
150 2014-12-28 01:12:28 <gmaxwell> And we wouldn't expect it to have one, so long as the outdegree is bounded.
151 2014-12-28 01:13:05 <sibiria> the chance of blockchain.info fetching blocks from the future seem slim to me
152 2014-12-28 01:13:21 <gmaxwell> sibiria: because you're telling me that you say around for an expected 10 minutes (and potentially an hour), waiting for a webpage to twitch and then {somehow} accurately measured the difference to a blocknotify running.
153 2014-12-28 01:13:55 <gmaxwell> what did your blocknotify do?
154 2014-12-28 01:14:22 <sibiria> unix timestamp together with block height, so i know exactly when it arrives at my end
155 2014-12-28 01:14:29 <sibiria> the important bit here is that it was AT LEAST 40 seconds between
156 2014-12-28 01:14:39 <sibiria> for all we know, bc.info may infact have received that block much earlier
157 2014-12-28 01:15:03 <gmaxwell> for all we know, even if your measurement was right it only happened once.
158 2014-12-28 01:15:18 <sibiria> i simply did a date +%s on the terminal when i saw blocks popping up on bc.info
159 2014-12-28 01:15:31 <sibiria> yeah that 40s was the worst case
160 2014-12-28 01:15:36 <sibiria> as said, usually within seconds
161 2014-12-28 01:15:43 <gmaxwell> okay, can you please pastebin your recorded timestamps for the blocks?
162 2014-12-28 01:15:54 <sibiria> but point remains: these 40s may one day be 1 minute, 1.5 minutes...
163 2014-12-28 01:16:19 <sibiria> by letting the user increase max outgoing conns a little bit, the chance of hitting unburdened nodes decreases
164 2014-12-28 01:16:26 <sibiria> 8 is a sane default
165 2014-12-28 01:16:29 <sibiria> wouldn't dream of altering that
166 2014-12-28 01:16:39 <gmaxwell> sibiria: Please post your timestamps.
167 2014-12-28 01:17:01 <sibiria> gmaxwell: you would have to wait until i am back home again
168 2014-12-28 01:17:09 <gmaxwell> right.
169 2014-12-28 01:17:28 <dgenr8> gmaxwell: raw data is one of the things cdecker hasn't shared.  the other thing was that is sounds like he only measured from one position in the network
170 2014-12-28 01:17:45 <sibiria> that was a follow-up question i had earlier
171 2014-12-28 01:17:51 <sibiria> regarding how many points he measured from
172 2014-12-28 01:17:59 <gmaxwell> sibiria: in any case, we've observed no increase in the propagation time related to node counts going up and down; we wouldn't expect there to be generally. And increasing the outdegree increases burden on the network (more overhead), so we'd actually expect it to go up.
173 2014-12-28 01:18:02 <sibiria> it stands out clearly that these 40s is a freak case of some sort
174 2014-12-28 01:18:09 <sibiria> but it's real, and it can happen
175 2014-12-28 01:18:40 <sibiria> gmaxwell: but you have already reserved and gifted this burden and overhead, by setting a maxconnections value that is quite high
176 2014-12-28 01:18:42 <gmaxwell> dgenr8: It's measured by observing invs from all reachable nodes, his position is only relevant at the scale of variance in internet latencies.
177 2014-12-28 01:18:47 <sibiria> this should be in your calculations already
178 2014-12-28 01:18:59 <gmaxwell> sibiria: I'd like to see your data.
179 2014-12-28 01:19:02 <sibiria> maxconnections is your blessed grace value
180 2014-12-28 01:19:13 <sibiria> gmaxwell: yeah you can have it later
181 2014-12-28 01:19:18 <dgenr8> yeah i think it would be better if he measured from a few different locations at least
182 2014-12-28 01:19:26 <sibiria> yes, obviously
183 2014-12-28 01:19:28 <sibiria> in my case as well
184 2014-12-28 01:19:39 <sibiria> a sample of one isn't exactly a clever metric
185 2014-12-28 01:19:39 <sibiria> :D
186 2014-12-28 01:19:44 <sibiria> yet... it's there, it happened
187 2014-12-28 01:20:05 <gmaxwell> dgenr8: I don't see why thats terribly interesting.
188 2014-12-28 01:20:24 <sibiria> if he measures at one point it only speaks about that one point's connectivity
189 2014-12-28 01:20:39 <sibiria> 500th percentile in 5 sec - great for that point
190 2014-12-28 01:20:53 <dgenr8> i would like to quantify my confidence in a model build from the raw data
191 2014-12-28 01:20:56 <sibiria> if that one point is to be put on a pillar, so could my nutty case of 40s delay for a block
192 2014-12-28 01:20:57 <dgenr8> built
193 2014-12-28 01:21:38 <gmaxwell> sibiria: but it isn't one point. He's measuring every reachable node. ("all" points) plus some additional noise that should have variance under 100ms normally.
194 2014-12-28 01:22:05 <sibiria> my question isn't a case for improving the network as a whole. it's about services that do not accept incoming nodes, having to rely on the 8 nodes they connect to being timely
195 2014-12-28 01:22:32 <gmaxwell> welp my three nodes all beat bc.i to 336226
196 2014-12-28 01:22:44 <gmaxwell> actually bc.i is still showing 336225 now.
197 2014-12-28 01:23:00 <gmaxwell> there it goes.
198 2014-12-28 01:23:06 <sibiria> that's not so interesting as the fact that bc.info beat another point by 40 seconds...
199 2014-12-28 01:23:24 <gmaxwell> sibiria: I suspect your measurement was flawed. Bc.i is normally very slow.
200 2014-12-28 01:23:53 <sibiria> yeah that adds to how bad this case was, considering how burdened they are
201 2014-12-28 01:23:57 <dgenr8> cdecker "normalizes" the times by subtracting the shortest time from all the others.  there are a couple gotchas there.  the whole set depends on where his closest node is, in addition to the aforementioned dependence on his ISP
202 2014-12-28 01:24:32 <dgenr8> and it's not an unbiased estimate of the actual time, I couldn't tell if he makes a further adjustment
203 2014-12-28 01:24:34 <sibiria> i have no reason to suspect that date(1) flukes on my system, nor that bitcoind and the -blocknotify function does
204 2014-12-28 01:25:05 <sibiria> anyway, thanks for the discussion
205 2014-12-28 01:25:12 <sibiria> gmaxwell: i'll get back to you with the timestamps
206 2014-12-28 01:25:15 <gmaxwell> sibiria: I suggest you put a wget of https://blockchain.info/q/latesthash >> $1  in your notify and measure some more.
207 2014-12-28 01:25:30 <sibiria> yeah i just might measure more
208 2014-12-28 01:25:39 <sibiria> btc isn't my main block chain, but it's an interesting study nevertheless :)
209 2014-12-28 01:25:47 <sibiria> see you around
210 2014-12-28 01:26:05 <gmaxwell> dgenr8: yes, sure, I have no doubt that the results are biased at a level of a 100ms or so. but the measurements are of several seconds to tens of seconds.
211 2014-12-28 01:26:41 <dgenr8> i'm weird and focus more on the tx data
212 2014-12-28 01:33:28 <gmaxwell> ah, well indeed that going to be corrupted by observational delays.
213 2014-12-28 01:44:51 <gmaxwell> and, again, my nodes beat bc.i's webui on 336228.
214 2014-12-28 02:23:12 <Luke-Jr> wumpus: IMO #5542 should be considered for 0.10
215 2014-12-28 02:24:04 <Luke-Jr> #5499 as well
216 2014-12-28 02:50:52 <proserpine-> siberia: setting maxconnections above 100 or increasing outbound connections to match severely degrades tx/block propagation as you have to broadcast all incoming tx/blocks to all connected peers, resulting in tons of invs and lots of wasted b/w
217 2014-12-28 02:51:32 <proserpine-> besides, over 870 connections is unattainable on bitcoin core in its current state due to select() limitation
218 2014-12-28 02:52:42 <proserpine-> but again, there is absolutely no reason to go past 100 - just for testing/fun ive managed 6000+ connections on bitcoin core (w/ epoll) for a short while
219 2014-12-28 08:14:21 <michagogo> 3:25:39 <gmaxwell> sibiria: I suggest you put a wget of https://blockchain.info/q/latesthash >> $1  in your notify and measure some more.
220 2014-12-28 08:14:35 <michagogo> I think curl might be the better tool in this case?
221 2014-12-28 08:18:25 <gmaxwell> michagogo: both can do the same.
222 2014-12-28 08:19:00 <michagogo> gmaxwell: yeah, but wget requires a switch and argument
223 2014-12-28 08:19:11 <michagogo> Curl has that as the default behavior
224 2014-12-28 08:23:11 <michagogo> And after all, The Unix Way is to use as few keystrokes as possible :P
225 2014-12-28 08:54:07 <wumpus> I've never understood curl vs wget either, they seem to do the same but are used slightly differently
226 2014-12-28 08:55:01 <wumpus> Luke-Jr: ok, no problem with that, although cfields will have to look at #5542
227 2014-12-28 08:55:24 <Luke-Jr> curl comes in a library form :p
228 2014-12-28 08:59:13 <midnightmagic> curl is better except it doesn't (didn't?) know how to change the written-to-filename to the correct value after a redirect.
229 2014-12-28 08:59:28 <midnightmagic> plus I know the curl primary author. :) he's awesome.
230 2014-12-28 09:02:37 <michagogo> wumpus: I think wget is really geared towards getting stuff
231 2014-12-28 09:02:52 <michagogo> Http, FTP, with a lot of options
232 2014-12-28 09:03:12 <michagogo> It can also do crawling, recursion, etc
233 2014-12-28 09:03:40 <michagogo> You can also give it multiple URLs
234 2014-12-28 09:04:09 <michagogo> Curl, I think, is more geared towards letting you make all kinds of queries, etc
235 2014-12-28 09:04:57 <michagogo> So the default is to output to stdout, and it has all kinds of options for headers, POST data, all kinds of stuff geared towards that
236 2014-12-28 09:06:33 <wumpus> michagogo: thanks for the explanation
237 2014-12-28 09:07:21 <michagogo> wumpus: take it with a grain of salt, though -- that's just my impression from the very limited use (relatively speaking) that I've made of them
238 2014-12-28 09:07:38 <michagogo> I don't know if that's really the developers' intentions
239 2014-12-28 09:08:00 <michagogo> And they can probably both do a lot more than I don't know about
240 2014-12-28 09:08:57 <wumpus> michagogo: looks like two swiss army knifes that accrued every bit of functionality over time, but there are still some differences on the lower level, one has the bottle opener where the other has the toothpick :)
241 2014-12-28 09:33:23 <CodeShark> yes, michagogo - I use wget to download files and curl to make data queries (generally speaking)
242 2014-12-28 09:34:27 <michagogo> ;;Google curl vs wget
243 2014-12-28 09:34:28 <gribble> curl vs Wget: <http://daniel.haxx.se/docs/curl-vs-wget.html>; cURL - Comparison Table: <http://curl.haxx.se/docs/comparison-table.html>; linux - What is better, curl or wget? - Stack Overflow: <http://stackoverflow.com/questions/636339/what-is-better-curl-or-wget>
244 2014-12-28 09:35:46 <CodeShark> I use both - the nice thing is you don't have to pick one over the other :)
245 2014-12-28 09:38:06 <CodeShark> wumpus: the http protocol itself is like a swiss army knife originally designed to serve HTML documents from servers that accrued a bunch of additional uses over time...to the point where it became used for things where it wasn't particularly a good solution at all
246 2014-12-28 09:38:31 <michagogo> CodeShark: like our RPC? :P
247 2014-12-28 09:38:41 <CodeShark> ;)
248 2014-12-28 09:40:33 <wumpus> CodeShark: indeed, nuff said
249 2014-12-28 09:48:49 <gmaxwell> so from that earlier diversion any my curl collection, my ordinary, non-sepcial 8 connection node has a block before bc.i's https interface (with several second connection overhead) 76.4% of the time over the last 68 blocks.
250 2014-12-28 09:49:57 <gmaxwell> 
ACTION stops the data collection

251 2014-12-28 09:52:32 <CodeShark> several second connection overhead?
252 2014-12-28 09:52:39 <CodeShark> as in every single HTTP request takes seconds?
253 2014-12-28 09:52:58 <CodeShark> or over the 68 blocks total?
254 2014-12-28 09:55:53 <gmaxwell> CodeShark: each connection seems to take well lemme time it. 1.530 seconds.
255 2014-12-28 09:56:04 <gmaxwell> 1.579.. yea, so about a second and a half.
256 2014-12-28 09:59:21 <CodeShark> how much of that is due to SSL?
257 2014-12-28 10:00:02 <CodeShark> a bunch is just the handshake
258 2014-12-28 10:00:59 <CodeShark> but the majority is the web server itself
259 2014-12-28 10:01:08 <CodeShark> just tried doing a few requests
260 2014-12-28 10:02:00 <CodeShark> looks like it goes through a cloudflare layer
261 2014-12-28 10:08:56 <ThomasZ> hey all, I just spend an hour in QtLinguist fixing bugs in the NL translations, I can make a merge request; which branch should this be for?
262 2014-12-28 10:09:59 <wumpus> ThomasZ: you're supposed to make translation changes in transifex :/ we can't directly accept pulls for that as they'd conflict with the exports from transifex
263 2014-12-28 10:10:32 <ThomasZ> transifex?  Interesting; Qt has a fully functional translation application.
264 2014-12-28 10:10:36 <ThomasZ> what is transifex?
265 2014-12-28 10:10:49 <wumpus> see e.g. 'Translations' in the README.md
266 2014-12-28 10:10:59 <gmaxwell> ThomasZ: crap. Super thanks for working on translations! I hope you're not put off by having to route them another way.
267 2014-12-28 10:11:16 <wumpus> it's an online collaborative translations editing environment
268 2014-12-28 10:11:43 <ThomasZ> I'm just confused why you would not use the solution that Qt provides, which is industry strength...
269 2014-12-28 10:12:03 <wumpus> it *is* possible to upload a manually edited dump back to them, but it messes up metadata and such (who edited what message, whether the message has been checked, etc)
270 2014-12-28 10:12:48 <wumpus> because filling in online forms is easier for most people, and this provides a level of cross-checking if a language community is somewhat organized
271 2014-12-28 10:12:49 <ThomasZ> you translate in a browser?
272 2014-12-28 10:13:35 <ThomasZ> im sorry, but that explains the crappyness of the translations. Not being able to try out your translations with a simple recompile is very limiting.
273 2014-12-28 10:13:49 <wumpus> sure you can try it out that way
274 2014-12-28 10:13:55 <wumpus> you just can't submit it that way
275 2014-12-28 10:14:25 <wumpus> most language editors can't do a recompile, never mind a simple one
276 2014-12-28 10:14:29 <ThomasZ> I've seen completely out of scope translations. Like "send addresses" -> "sending to addresses" kind of mixup.
277 2014-12-28 10:14:52 <ThomasZ> never mind that the 'file menu has 3 duplicate shortcuts (&)
278 2014-12-28 10:15:39 <wumpus> anyhow I don't feel like arguing this, there's some stupid issue every day that people want to argue, if you want to contribute to our project you'll have to do at least some things in our way
279 2014-12-28 10:16:46 <ThomasZ> I'm not really into arguing either. Just pointing out that the quality of translatons is low and for a very identifyable reason.  Your choice if you want to ignore it.
280 2014-12-28 10:18:06 <wumpus> transifex is used by a *lot* of projects, both commercial and open source, so I doubht the issue is with the site
281 2014-12-28 10:19:03 <sipa> when we started using transifex there were translation for bitcoind too (or are there still?), so using Qt's tools would have constrained the scope
282 2014-12-28 10:19:19 <wumpus> transifex still uses qt's tools in their backend
283 2014-12-28 10:19:30 <wumpus> there's no difference in result, just a difference in tool used for editing
284 2014-12-28 10:20:10 <sipa> ThomasZ: anyway, i hope you feel like continuing to contribute
285 2014-12-28 10:20:18 <sipa> it's very welcome
286 2014-12-28 10:20:31 <gmaxwell> ThomasZ: I think we just want to accomidate as many translators as possible. (hopefully good ones, but for many languages good is too much to ask for)
287 2014-12-28 10:21:36 <sipa> to be honest... i'm not sure i've ever in the last 10 years set my system language to anything but english
288 2014-12-28 10:21:40 <ThomasZ> I'm trying to find out if transifex shows contexts like linguist does.
289 2014-12-28 10:22:24 <ThomasZ> sipa: sure, I don't run it in anything other than eng either ;)
290 2014-12-28 10:22:57 <sipa> a lot of dutch speakers (i'm flemish) are pretty good at english, so it's perhaps not a very interesting thing to work on
291 2014-12-28 10:23:08 <sipa> that could explain the low quality too
292 2014-12-28 10:23:46 <ThomasZ> thats debatable, depends highly on age etc.
293 2014-12-28 10:23:51 <sipa> agree
294 2014-12-28 10:24:02 <ThomasZ> my parents would no be able to handle an english app
295 2014-12-28 10:24:18 <sipa> but would they run bitcoin core? :)
296 2014-12-28 10:24:55 <ThomasZ> I forbid them to run anything java or ruby based ;)
297 2014-12-28 10:28:25 <ThomasZ> anyway; if someone is interested; here is the commit. https://github.com/zander/bitcoin/commit/d341e8c692ee6c8fa30f34e8e4a6cee49082c906
298 2014-12-28 10:29:26 <michagogo> ThomasZ: what's wrong with Java and Ruby?
299 2014-12-28 10:29:37 <ThomasZ> michagogo: trojans
300 2014-12-28 10:30:02 <michagogo> Ruby specifically?
301 2014-12-28 10:30:15 <michagogo> 
ACTION is not familiar with such a phenomenon

302 2014-12-28 10:30:35 <ThomasZ> not sure if there is a bitcoin client in ruby, so not realy relevant here
303 2014-12-28 10:35:00 <ThomasZ> gmaxwell: maybe its an idea to create a zip file with the windows exe of Linquist (plus dlls), the Qt translation tool. Then all you need is a way to download and upload the relevant .ts files.
304 2014-12-28 10:39:23 <gmaxwell> ThomasZ: part of it is attracting the existing community of people who like to translate and whom aren't interested in bitcoin that much specifically (of course, those are probably lower quality translators: but perhaps they could be improved by giving them specific guidance)
305 2014-12-28 10:42:21 <ThomasZ> gmaxwell: right, that explains why "fee" was translated as it was.  If translated back into english it would be "cost". Which is confusing at best.
306 2014-12-28 10:43:08 <gmaxwell> hahah
307 2014-12-28 10:43:10 <ThomasZ> gmaxwell: is there a mailinglist they subscribe to?
308 2014-12-28 10:43:41 <gmaxwell> I'm translation ignorant. Perhaps wumpus knows.
309 2014-12-28 10:45:40 <sipa> i do remember at some point that from the top or ps manpage in manpages-nl, there was a sentence "Count dead children in sum with parents" and something about a "decaying average"
310 2014-12-28 10:45:44 <sipa> which were... well, translated very literally
311 2014-12-28 10:46:55 <Diablo-D3> wow
312 2014-12-28 10:46:56 <Diablo-D3> thats dark
313 2014-12-28 10:47:09 <wumpus> ThomasZ: yes, there is a translations mailing list
314 2014-12-28 10:47:16 <sipa> orly?
315 2014-12-28 10:47:27 <wumpus> ThomasZ: it's also mentioned in the README.md
316 2014-12-28 10:47:40 <ThomasZ> wumpus: there was no mailinglist there, just a google group.
317 2014-12-28 10:47:51 <ThomasZ> mostly empty
318 2014-12-28 10:47:54 <wumpus> under, surprisingly, "Translations". incidentally there's also translation-process.md
319 2014-12-28 10:48:08 <sipa> "Tel dode kinderen bij ouders" en "wegrottend gemiddelde"
320 2014-12-28 10:48:24 <wumpus> ThomasZ: a google group is effectively a mailing list
321 2014-12-28 10:49:08 <ThomasZ> wumpus: how do I use it from my email application?
322 2014-12-28 10:49:12 <wumpus> and yes, it's pretty empty, we've tried to get translators more involved and for some languages that has been a success (ie German w/ Diapolo) but it remains a scarce area
323 2014-12-28 10:49:18 <wumpus> ThomasZ: I have no clue, I'm also not your helpdesk.
324 2014-12-28 10:49:58 <sipa> you subscribe to it; i'm sure you can subscribe to a google group even without a gmail address
325 2014-12-28 10:50:29 <ThomasZ> wumpus: in that case; scroll back for the commit link I posted and feel free to somehow get them into the translation stuff you guys use
326 2014-12-28 10:50:35 <wumpus> ThomasZ: anyhow if it makes you less pissed off I can try to import your .nl translation file into transifex
327 2014-12-28 10:51:02 <ThomasZ> I am not pissed off.
328 2014-12-28 10:52:46 <wumpus> sipa: yes, that's one reason I'm trying to keep very technical/specific stuff out of the translation messages, most people don't know what it means or how to translate it
329 2014-12-28 10:53:55 <wumpus> they could of course just leave it as-is in that case, but that's not what happens in practice
330 2014-12-28 10:55:21 <wumpus> but there's still some madness in there, ie at some point we translated specific block validation error messages
331 2014-12-28 10:55:48 <gmaxwell> I really think we shouldn't translate errors. Errors are for searching.
332 2014-12-28 10:55:50 <wumpus> also we translate --help option descriptions, I'm not sure they'll do a good job on that
333 2014-12-28 10:56:17 <gmaxwell> Unless they're telling people to do something particular, an error message isn't really for user reading much of the time.
334 2014-12-28 10:56:17 <wumpus> gmaxwell: apart from some generic errors in the UI that's the case now AFAIK
335 2014-12-28 10:56:22 <gmaxwell> okay cool.
336 2014-12-28 10:58:53 <sipa> if i look at my parents, and they complain about something not working, they say "A window appeared and i had to click it away" - "What did it say?" - "Eh no idea, something about an error"
337 2014-12-28 10:59:34 <gmaxwell> dunno about you, but I've done that myself, usually followed by "Crap! what did that say?!"
338 2014-12-28 10:59:34 <sipa> i'm pretty convinced that except the small group of people who actually knows how things work under the hood, the actual error message is meaningless
339 2014-12-28 10:59:57 <sipa> sure, but at least i blame myself for not looking
340 2014-12-28 11:00:12 <sipa> for them, the idea of actually looking at the text and searching for it seems alien
341 2014-12-28 11:01:09 <sipa> (part of this imho is due to the practice of modal windows interrupting an application directly, as they stop your normal workflow, it really feels like something you "have to click away" rather than something trying to tell you something)
342 2014-12-28 11:01:19 <gmaxwell> we're far too chatty with errors, which makes our own logs much less useful too, no point in googling most of what it calls errors.
343 2014-12-28 11:01:22 <ThomasZ> I've seen a usability talk which was awesom on this topic;  it turned the application into a buddy. So if something went wrong (like your interent connectivity) it would be like "Oh, dear, the internets failed on us, I can try again later :("
344 2014-12-28 11:01:46 <sipa> "The tubes are clogged"
345 2014-12-28 11:02:11 <ThomasZ> the point is that it is your buddy, and you both are stuck with the error, it tries to help you. Its your friend.
346 2014-12-28 11:02:57 <ThomasZ> whereas most apps are like "you did something unforgivable, haha! I'm telling everyone!"
347 2014-12-28 11:03:03 <gmaxwell> ThomasZ: I imagine its a bit annoying when it's wrong.  like you intentionally disconnect the internet to save bandwidth and it says "Oh, dear, the internets failed on us, I can try again later :(" and you're thinking "no you idiot, I turned it off!" but it has no ears. :)
348 2014-12-28 11:03:30 <ThomasZ> most mobiles can make that distinction, though ;)
349 2014-12-28 11:07:04 <gwillen> they make it incredibly badly and should usually be shot for trying
350 2014-12-28 11:07:17 <gwillen> I thank god that google finally got rid of that feature in some recent version of android
351 2014-12-28 11:07:33 <gwillen> there was a version window during which, if the system didn't think it could get internet, ain't nobody could get internet, even if the actual connection was fine
352 2014-12-28 11:07:54 <wumpus> application trying to be a buddy makes me think of MS's clippy :) 'hey, I see you're trying to... ' WRAAA
353 2014-12-28 11:08:11 <gwillen> (it still shows the connection icon as grey instead of blue, if it thinks there's no connectivity; but it no longer actively interferes with apps using the connection anyway)
354 2014-12-28 11:08:42 <gmaxwell> I think the important lesson is that users sometimes find overly "factual" errors as accusatory.
355 2014-12-28 11:09:05 <gwillen> well, that's fair, and I'm fine with weasel-wording errors to make the user feel better
356 2014-12-28 11:09:26 <gwillen> as long as details are available on request, and the app doesn't try to _do_ anything clever
357 2014-12-28 11:09:32 <sipa> "Cannot find printer" - "But I'm holding the printer right in front of the computer screen! How can it not find it? Silly computer"
358 2014-12-28 11:09:45 <wumpus> hahaha
359 2014-12-28 11:10:10 <gmaxwell> "it's dangling right here! I'm holding the connectors up to the red eye thing! why can't you see it?"
360 2014-12-28 11:10:11 <sipa> (this was a joke from a popular but way-too-long-running flemish tv show)
361 2014-12-28 11:10:52 <gwillen> I think the opposite extreme is well represented in http://xkcd.com/416/ ;-)
362 2014-12-28 11:11:09 <sipa> let me guess
363 2014-12-28 11:11:23 <ThomasZ> gwillen: :D
364 2014-12-28 11:11:28 <sipa> yup, i guessed right
365 2014-12-28 11:12:26 <gmaxwell> WPA took off before WEP cracking (even with the awesome broadcast replay attacks) got fast enough to realistically make it a part of network autoconfig.
366 2014-12-28 11:12:29 <gmaxwell> Alas.
367 2014-12-28 11:13:30 <sipa> it could be made part of a reusable proof-of-work system otherwise to pay for wifi access
368 2014-12-28 11:14:07 <ThomasZ> haha, proof of work is to bruteforce the WPA password?
369 2014-12-28 11:14:25 <sipa> no, crack the WEP access
370 2014-12-28 11:14:51 <gmaxwell> unfortauntely the replay attacks are pretty intrusive to users of the network.
371 2014-12-28 11:15:35 <gwillen> gmaxwell: it angers me that deauthentication packets are spoofable on an encrypted network by a non-associated user
372 2014-12-28 11:15:38 <gwillen> there was no need for that to be true
373 2014-12-28 11:16:10 <gwillen> (it angers me because of the marriott thing that's currently before the FCC, which I assume you've seen)
374 2014-12-28 11:19:30 <gmaxwell> gwillen: perhaps you might like the debate in the IETF tcp increased security working group TCPCRYPT where some people don't want RST to be authenticated.
375 2014-12-28 11:20:17 <robbak> I saw some chatter about this, but not what is causing it: configure: WARNING: no configuration information is in src/secp256k1
376 2014-12-28 11:20:22 <gwillen> gmaxwell: perhaps I might think those people are morons who are doomed to repeat history either because they don't understand it, or (more sinisterly) because they approve of it
377 2014-12-28 11:20:31 <Diablo-D3> gwillen: :D
378 2014-12-28 11:20:52 <gmaxwell> gwillen: well it's never simple.
379 2014-12-28 11:20:53 <Diablo-D3> <gwbush> that hitler guy, yeah, he was pretty cool *thumbs up*
380 2014-12-28 11:21:08 <Diablo-D3> (and now that we have the hitler thing out of the way...)
381 2014-12-28 11:22:00 <gmaxwell> robbak: do you have any reason to believe it isn't a harmless side effect of nested autoconf?
382 2014-12-28 11:22:25 <Diablo-D3> >nested autoconf
383 2014-12-28 11:22:27 <Diablo-D3> >harmless
384 2014-12-28 11:22:37 <robbak> gmaxwell: It isn't harmless, because it leads to  "*** No rule to make target 'libsecp256k1.la'.  Stop."
385 2014-12-28 11:22:39 <Diablo-D3> you're really going with that?
386 2014-12-28 11:22:42 <wumpus> ok, pushed ThomasZ's translation to transifex, then did a pull of translations to the 0.10 branch
387 2014-12-28 11:22:49 <wumpus> robbak: ./autogen.sh ?
388 2014-12-28 11:24:23 <wumpus> either that or clean out your tree e.g. clean -f -x -d and start over
389 2014-12-28 11:25:16 <wumpus> s/clean/git clean/
390 2014-12-28 11:25:37 <wumpus> but just rerunning autogen and configure should work
391 2014-12-28 11:25:56 <robbak> wumpus: I'm building from a tarball. So, it's because I am missing some part of autotools.
392 2014-12-28 11:26:35 <wumpus> robbak: possible, though in principle gitian releases are build from tarballs ("make dist") too so there should be a sanity check on that
393 2014-12-28 11:26:42 <wumpus> robbak: weird
394 2014-12-28 11:27:01 <robbak> I'm setting up the freebsd port to get ready for the 10.0 release
395 2014-12-28 11:28:24 <gmaxwell> robbak: please report any issues so we can fix them in RC instead of carrying patches, if at all possible. (well, sounds like you're doing that, so this request is perhaps redundant; but some packagers seem not to know that we want fixes)
396 2014-12-28 11:30:05 <robbak> gmaxwell - Yes, If there are any patches I'll create pull requests for them.
397 2014-12-28 11:32:22 <wumpus> it sounds like the inner configure (for secp256k1) is somehow not called, or not present
398 2014-12-28 11:33:07 <wumpus> usually that happens when someone builds 0.10 in, say, a 0.9 tree, without calling autogen.sh, hence my above suggestion but that'd indeed not help here if the dependent files are not packaged...
399 2014-12-28 11:33:11 <robbak> wumpus: Yes, I'm not getting a Makefile.in file
400 2014-12-28 11:42:21 <robbak> ...And autogen.sh does create it. Looks like I've got it now. I needed to add autoreconf.
401 2014-12-28 11:56:17 <michagogo> 13:01:48 <ThomasZ> I've seen a usability talk which was awesom on this topic;  it turned the application into a buddy. So if something went wrong (like your interent connectivity) it would be like "Oh, dear, the internets failed on us, I can try again later :("
402 2014-12-28 11:56:24 <michagogo> Sounds like Windows 8
403 2014-12-28 11:56:44 <michagogo> IIRC it replaced the BSOD with "Your computer needs to restart. :-("
404 2014-12-28 11:56:53 <michagogo> 13:26:22 <robbak> wumpus: I'm building from a tarball. So, it's because I am missing some part of autotools.
405 2014-12-28 11:57:17 <michagogo> Um, I thought once you have ./configure you don't need autotools?
406 2014-12-28 11:58:02 <michagogo> (And don't dist tarballs come with configure?)
407 2014-12-28 12:22:16 <ThomasZ> michagogo: if you ever used win8 you would not make that connection ;)  Its anything but humane.
408 2014-12-28 12:23:32 <robbak> michagogo: I don't know - autoconf is all opaque black boxes to me, and it all smacks of inner platform effect. I *think* that ./configure is written by autotools, and if you aren't building on the same setup, you need to re-run autotools to recreate ./configure. I think.
409 2014-12-28 12:23:33 <ThomasZ> michagogo: autogen requires the autoconf,  running configure still requires auto* because it takes the .am files and turns them into makefiles.
410 2014-12-28 12:24:27 <ThomasZ> thats why autoconf and automake are packaged separately
411 2014-12-28 12:27:21 <hegemoOn> http://paste.netmonk.org/zorimujasi
412 2014-12-28 12:27:42 <hegemoOn> i got this error for compiling just after a git pull few seconds ago
413 2014-12-28 12:28:29 <robbak> Anyoong got any ideas why the bundled leveldb hasn't got SIZE_MAX declared for helpers/memenv/memenv.cc?
414 2014-12-28 12:29:12 <sipa> robbak: it probably ecpects system headers to define it, but yours don't
415 2014-12-28 12:31:29 <michagogo> ThomasZ: wait, really?
416 2014-12-28 12:32:13 <michagogo> It's all a black box to me, but from conversations I had in here before I gave up trying to understand I was lead to believe that the idea was for ./configure to require almost nothing
417 2014-12-28 12:32:42 <ThomasZ> michagogo: it requires quite a lot, actually. Most of it decades old.
418 2014-12-28 12:32:50 <ThomasZ> libtool is my favorite
419 2014-12-28 12:32:57 <ThomasZ> well, configure itself doesn't require it.
420 2014-12-28 12:34:24 <hegemoOn> anyone has this error also ?
421 2014-12-28 12:34:39 <ThomasZ> hegemoOn: not sure why your system has HAVE_DECL_STRNLEN defined somewhere. Sounds wrong. Easiest fix is to remove those 5 lines from your source file
422 2014-12-28 12:35:20 <hegemoOn> ok
423 2014-12-28 12:35:20 <ThomasZ> I'm curious why that code is in bitcoin in the first place.
424 2014-12-28 12:36:08 <ThomasZ> Pavel Janík wrote that code; he may know
425 2014-12-28 12:38:40 <sipa> hegemoOn: delete the bitcoin-config.h file and configure again
426 2014-12-28 12:39:13 <sipa> hegemoOn: ir just git clean -dfx (which resets your working dir to just what is in the repo)
427 2014-12-28 12:44:59 <gmaxwell> I wish we could get graphs like these http://statoshi.info/#/dashboard/file/default.json (well minus the non-zero orgin graph fraud) in bitcoin-qt.
428 2014-12-28 12:48:18 <ThomasZ> gmaxwell: i'm a long time Qt hacker, if you provide the data, I can make those graphs pretty easy
429 2014-12-28 12:49:12 <gmaxwell> ThomasZ: the data is all in bitcoin core already I believe... though no rrd like collection of it, just current values.
430 2014-12-28 12:51:23 <ThomasZ> is there any chatter about going to Qt5 and QML for the client?
431 2014-12-28 12:53:41 <sipa> aren't we using qt5 yet?
432 2014-12-28 12:54:18 <sipa> gmaxwell: you mean as htnl through rest, or in the gui?
433 2014-12-28 12:54:19 <gmaxwell> I don't know what the plan is there. We support both and I think use QT5 on OSX because it fixed some issues with high dpi hosts (?). As far as using QT5 only, I think we'd be willing to if we had a reason to.
434 2014-12-28 12:54:42 <gmaxwell> sipa: "I dunno"  being integrated well would be nice.
435 2014-12-28 12:54:49 <sipa> i somehow think that many bitcoind running people would be interested in such graphs too
436 2014-12-28 12:55:24 <sipa> and if it can be implemented as serving some static html which fetches stats through rest, the code in core itself would be very minimal
437 2014-12-28 12:56:00 <ThomasZ> sipa: I think the hard part is figuring out where to store the data
438 2014-12-28 12:56:12 <sipa> store?
439 2014-12-28 12:56:46 <gmaxwell> In memory is probably okay, in that gaps during downtime would make it much less interesting.
440 2014-12-28 12:56:57 <ThomasZ> I assume bitcoind doesnt link to Qt? And so if you want to display the data in bitcoind you need to do something interesting to display it
441 2014-12-28 12:57:24 <gmaxwell> ThomasZ: sipa was just suggesting using a webbrowser to display it.
442 2014-12-28 12:57:54 <gmaxwell> This sort of data is not actually all that useful, but I think it makes running the software more interesting. High tech lava lamp.
443 2014-12-28 12:58:27 <ThomasZ> static html is, well static.
444 2014-12-28 12:59:12 <gmaxwell> ThomasZ: what I think he's thinking is a 'stack' page that includes javascript that fetches the data from the rest interface.
445 2014-12-28 12:59:36 <ThomasZ> ok, thats kinda what I meant with the question of where to store the data :)
446 2014-12-28 13:00:02 <ThomasZ> bitcoind, fetchable via rest. Sounds good
447 2014-12-28 13:00:41 <ThomasZ> then the Qt client can provide interactive graphics using native rendering code
448 2014-12-28 13:16:45 <wumpus> requiring qt5 is not acceptable at this point, still way too many 'stable' linux distros that ship with qt4 only
449 2014-12-28 13:16:53 <wumpus> though having qt5-only features is perfectly fine
450 2014-12-28 13:17:49 <wumpus> more graphs in the debug window would be nice
451 2014-12-28 13:20:57 <wumpus> a html UI for node management would be very nice too (I could use that, I run bitcoind on embedded devices, having something like openwrt's luci to manage and show statistics would be great). But  don't make it part of bitcoin core.
452 2014-12-28 13:21:23 <gmaxwell> wumpus: I like that ncurses tool.
453 2014-12-28 13:21:54 <wumpus> of course storage e.g. historical data could happen there, but don't make the ui part of bitcoind
454 2014-12-28 13:22:12 <wumpus> gmaxwell: yes that one's very nice too
455 2014-12-28 13:25:46 <wumpus> e.g. https://github.com/azeteki/bitcoind-ncurses ,so another advantage of not having the ui in bitcoind is that various frontends can be used to display the collected statistics data
456 2014-12-28 13:27:10 <wumpus> there was also a 'statoshi' project at some point that collected various metrics about the node and graphed them, it generates  events  from bitcoind and collects them in a standard graphing/statistics package, forgot the name
457 2014-12-28 13:29:38 <wumpus> the only issue was that it wasn't quite lightweight, ie some heavy LAMP-like environment needed to run it
458 2014-12-28 13:34:41 <gmaxwell> thats the thing I linked to above.
459 2014-12-28 14:08:55 <b_lumenkraft> wondering how app.net could be useful for bitcoin… >> https://developers.app.net >> https://opensource.app.net
460 2014-12-28 14:09:57 <hearn> wonder how much they paid for that domain name
461 2014-12-28 14:12:50 <b_lumenkraft> hearn: idk. you have to ask @dalton for that ;) >> http://en.wikipedia.org/wiki/Dalton_Caldwell >> https://www.linkedin.com/in/daltoncaldwell
462 2014-12-28 14:13:04 <b_lumenkraft> he is working at YC these days
463 2014-12-28 14:58:18 <hegemoOn> sipa thank you it fixed it :)
464 2014-12-28 14:58:43 <hegemoOn> 
465 2014-12-28 14:58:55 <sipa> 
466 2014-12-28 16:53:16 <midomido> anyone here ?
467 2014-12-28 17:18:50 <clarinet> ;;Google boot from RAM
468 2014-12-28 17:18:51 <gribble> RAMBOOT: <http://ramboot.org/>; List of Linux distributions that run from RAM - Wikipedia, the free ...: <http://en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM>; BootToRAM - Ubuntu Wiki: <https://wiki.ubuntu.com/BootToRAM>
469 2014-12-28 17:20:24 <midomido> ;;Google boot from RAM
470 2014-12-28 17:20:25 <gribble> RAMBOOT: <http://ramboot.org/>; List of Linux distributions that run from RAM - Wikipedia, the free ...: <http://en.wikipedia.org/wiki/List_of_Linux_distributions_that_run_from_RAM>; BootToRAM - Ubuntu Wiki: <https://wiki.ubuntu.com/BootToRAM>
471 2014-12-28 17:20:30 <midomido> Google boot from RAM
472 2014-12-28 17:20:39 <clarinet> ;;Google LiveCD Customization
473 2014-12-28 17:20:40 <gribble> LiveCDCustomization - Community Help Wiki: <https://help.ubuntu.com/community/LiveCDCustomization>; LiveCDCustomizationFromScratch - Community Help Wiki: <https://help.ubuntu.com/community/LiveCDCustomizationFromScratch>; ubuntu livecd/dvd | Customize Ubuntu: <http://customizeubuntu.com/ubuntu-livecd/>
474 2014-12-28 17:47:06 <midomido> does bitcoin-qt support coinbase/append ?
475 2014-12-28 17:47:25 <midomido> ;;Google does bitcoin-qt support coinbase/append ?
476 2014-12-28 17:47:26 <gribble> Getblocktemplate - Bitcoin: <https://en.bitcoin.it/wiki/Getblocktemplate>; Sending from Bitcoin-Qt to Coinbase - Bitcoin Stack Exchange: <http://bitcoin.stackexchange.com/questions/13519/sending-from-bitcoin-qt-to-coinbase>; Import private key to coinbase? - Bitcoin Stack Exchange: <http://bitcoin.stackexchange.com/questions/21553/import-private-key-to-coinbase>
477 2014-12-28 19:33:42 <tiyoT> anyone got 5min to talk with me regarding HD (hierarchical wallet)
478 2014-12-28 20:45:26 <sipa> heh
479 2014-12-28 20:46:06 <sipa> BIP16's switchover was in april 2012, and BIP30's in march 2012?
480 2014-12-28 20:46:14 <sipa> i thought BIP30 was much later
481 2014-12-28 21:09:00 <sipa> spent some time writing this: http://bitcoin.stackexchange.com/questions/18851/what-bips-are-supported-by-the-standard-client-bitcoin-qt-0-8-6/34213#34213
482 2014-12-28 21:09:13 <sipa> maybe we want that as some doc/.md file in-repository too
483 2014-12-28 21:19:08 <michagogo> Um
484 2014-12-28 21:19:13 <michagogo> What is that spelling? https://github.com/bitcoin/bitcoin/commit/a206b0ea12eb4606b93323268fc81a4f1f952531#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR1270
485 2014-12-28 21:20:22 <sipa> ?
486 2014-12-28 21:21:24 <michagogo> "februari"
487 2014-12-28 21:22:00 <sipa> ah
488 2014-12-28 21:22:03 <sipa> that's dutch :D
489 2014-12-28 21:22:22 <michagogo> also, how come https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki doesn't link to the change that implemented it the way BIP30 did?
490 2014-12-28 21:22:32 <michagogo> sipa: so... why is it in our comment? :P
491 2014-12-28 21:22:42 <sipa> michagogo: because nobody ever noticed, until you did
492 2014-12-28 21:22:49 <michagogo> heh
493 2014-12-28 21:27:49 <michagogo> er, why does https://github.com/bitcoin/bitcoin/pull/5493 say it's open and needs rebase
494 2014-12-28 21:27:57 <michagogo> There's a commit merging it
495 2014-12-28 21:29:17 <sipa> michagogo: closed
496 2014-12-28 21:30:27 <sipa> i assume it may have been left open because wumpus expected further updates to happen still
497 2014-12-28 21:31:13 <michagogo> sipa: anyway, looks like that comment isn't in master anymore
498 2014-12-28 21:31:48 <michagogo> https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1661
499 2014-12-28 21:34:48 <michagogo> Anyway, I should probably get to bed... it's only 11:34 pm, but in a few weeks I'll start needing to wake up and leave the house by 7ish
500 2014-12-28 21:34:54 <michagogo> so... goodnight, everyone
501 2014-12-28 21:35:25 <sipa> so enjoy late night coding while you can :p
502 2014-12-28 21:36:04 <michagogo> Nah, I don't want to just jump into it all at once
503 2014-12-28 21:36:28 <michagogo> That's a recipe for being late for my first several days :P
504 2014-12-28 21:36:53 <michagogo> (I don't drive, so it's not like I can leave 5 minutes late and get there 5 minutes late...)
505 2014-12-28 21:56:20 <ThomasZ> am I correct in assuming that changes in ui-strings are not possible in the 0.10 branch?
506 2014-12-28 21:59:11 <sipa> in the untranslated ones, or the translated ones?
507 2014-12-28 21:59:59 <ThomasZ> in a UI file, so translated one.
508 2014-12-28 22:00:06 <ThomasZ> I just created the pull request for master.
509 2014-12-28 22:08:51 <ThomasZ> sipa: other than submitting a merge request via github, anything else needed?
510 2014-12-28 22:09:35 <sipa> ThomasZ: nope, thanks!
511 2014-12-28 23:11:08 <sipa> wumpus: no post on bitcointalk about rc1?