1 2014-12-18 00:01:49 <phantomcircuit> voidDotClass, there's a lot of peers
  2 2014-12-18 00:02:13 <phantomcircuit> i have two on 10 gbps lines
  3 2014-12-18 00:02:45 <voidDotClass> all right, but in the early days that could've been more of a problem
  4 2014-12-18 00:02:45 <voidDotClass> how was it prevented?
  5 2014-12-18 00:02:52 <phantomcircuit> nobody cared to do it
  6 2014-12-18 00:03:07 <phantomcircuit> and even if they did
  7 2014-12-18 00:03:13 <phantomcircuit> it would have only been temporary
  8 2014-12-18 00:03:17 <sipa> also, starting a bew node is.easy
  9 2014-12-18 00:03:22 <sipa> *new
 10 2014-12-18 00:03:53 <voidDotClass> someone could have brought down the whole network when it was ~1000 nodes
 11 2014-12-18 00:04:04 <sipa> maybe
 12 2014-12-18 00:04:23 <voidDotClass> that means any new currencies are vulnerable to it
 13 2014-12-18 00:04:27 <sipa> and when they stopped attacking, it would.just resume
 14 2014-12-18 00:04:57 <voidDotClass> they may resume DDos sporadically until people get frustrated and stop using it, esp. in early days
 15 2014-12-18 00:05:13 <sipa> yup, people certainly could have
 16 2014-12-18 00:05:25 <sipa> probably.still can, given.sufficient money
 17 2014-12-18 00:05:46 <voidDotClass> it can probably be circumvented easily
 18 2014-12-18 00:05:52 <phantomcircuit> sipa, i suspect that would be more expensive than a 51% attack at this point
 19 2014-12-18 00:05:58 <sipa> yup
 20 2014-12-18 00:06:20 <voidDotClass> just store the timestamp and ip of requests, if > X reqs / Y seconds, ignore
 21 2014-12-18 00:06:30 <sipa> oh we do that
 22 2014-12-18 00:06:45 <sipa> to.some extent
 23 2014-12-18 00:06:48 <voidDotClass> although that could still take a lot of processing?
 24 2014-12-18 00:07:01 <phantomcircuit> voidDotClass, that's cheap to do
 25 2014-12-18 00:07:02 <voidDotClass> given sufficient reqs?
 26 2014-12-18 00:07:09 <voidDotClass> ah
 27 2014-12-18 00:07:21 <voidDotClass> any better ways?
 28 2014-12-18 00:07:22 <phantomcircuit> it's expensive to handle bandwidth attacks
 29 2014-12-18 00:07:32 <phantomcircuit> because ultimately you need to pay for more bandwidth
 30 2014-12-18 00:07:48 <voidDotClass> is it possible to just reject them?
 31 2014-12-18 00:08:06 <phantomcircuit> you can drop the traffic once you've received it
 32 2014-12-18 00:08:06 <voidDotClass> if req size > 1 KB = don't receive?
 33 2014-12-18 00:08:14 <voidDotClass> not before receiving?
 34 2014-12-18 00:08:19 <phantomcircuit> but you're already paying for it when it's reached you
 35 2014-12-18 00:08:26 <voidDotClass> darn
 36 2014-12-18 00:08:43 <phantomcircuit> voidDotClass, this is ot in here, you can move to #bitcoin though
 37 2014-12-18 00:08:47 <voidDotClass> but you could blacklist the ip after the first such attack?
 38 2014-12-18 00:08:56 <sipa> yes
 39 2014-12-18 00:18:54 <Luke-Jr> voidDotClass: DDoS protection is basically impossible
 40 2014-12-18 00:19:37 <Luke-Jr> sorry, going ot #bitcoin
 41 2014-12-18 01:59:56 <fenn> typo alert: in https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki CKDpub(CKDpub(CKDpub(M,3),2,5) is missing a closing parenthesis
 42 2014-12-18 02:24:55 <sipa> fenn: fix it
 43 2014-12-18 02:25:51 <moa> )
 44 2014-12-18 02:30:39 <Diablo-D3> better yet
 45 2014-12-18 02:30:50 <Diablo-D3> everyone install rainbow parens for their editors
 46 2014-12-18 02:31:33 <wumpus> rainbow unicorn parenthesis
 47 2014-12-18 04:24:53 <Luke-Jr> wumpus: what header do I need for QT_BEGIN_NAMESPACE?
 48 2014-12-18 07:29:24 <wumpus> Luke-Jr: good point - I have no idea, but any one of them will do
 49 2014-12-18 09:22:00 <lechuga_> am i the only one that notices subtle continuously decreasing txs wrt total output value
 50 2014-12-18 09:22:09 <lechuga_> it happens everyday
 51 2014-12-18 09:22:22 <lechuga_> cant figure out why
 52 2014-12-18 09:22:44 <sipa> ?
 53 2014-12-18 09:23:00 <lechuga_> 7.087..7.086...7.081...7.076..(im truncating, but showing the tren)
 54 2014-12-18 09:23:02 <lechuga_> tend*
 55 2014-12-18 09:23:07 <lechuga_> trend
 56 2014-12-18 09:23:21 <gwillen> lechuga_: that's probably actually repeated small payments and you're seeing change
 57 2014-12-18 09:23:25 <sipa> you mean a sequence of actual transactions?
 58 2014-12-18 09:23:29 <lechuga_> yeah
 59 2014-12-18 09:23:46 <lechuga_> it's almost everday but i start to observe it at different points
 60 2014-12-18 09:23:55 <lechuga_> everyday*
 61 2014-12-18 09:24:04 <sipa> it's a sequence of payouts that should be using multiple outputs instead of separate transactions
 62 2014-12-18 09:24:34 <sipa> people have been doing that for years
 63 2014-12-18 09:24:54 <lechuga_> gambling?
 64 2014-12-18 09:26:00 <lechuga_> the pattern will continue for really long sequences sometimes
 65 2014-12-18 09:27:32 <sipa> or mining payouts
 66 2014-12-18 09:27:55 <lechuga_> ah
 67 2014-12-18 09:36:27 <lechuga_> they usually sum to much larger than a block subsidy in the same interval
 68 2014-12-18 09:37:55 <lechuga_> anyway OT
 69 2014-12-18 10:08:40 <netg> oi5
 70 2014-12-18 10:51:08 <abishek> could somebody advice on what do the terms inputs and outputs mean on a bitcoin transaction?
 71 2014-12-18 10:59:55 <wumpus> the same as they do everywhere? inputs specify what goes in, outputs specify what goes out?
 72 2014-12-18 11:01:04 <wumpus> this is more #bitcoin talk, but anyhow see https://bitcoin.org/en/developer-guide#block-chain
 73 2014-12-18 12:24:56 <abishek> is there a way to know the list of confirmations for a transaction from a block when the transaction is outside of the wallet?
 74 2014-12-18 12:26:51 <iwilcox> Again, probably #bitcoin material.
 75 2014-12-18 12:28:14 <abishek> iwilcox, so this room is only for core bitcoin development and not for apps that are being developed on top of bitcoin using RPC?
 76 2014-12-18 12:29:43 <iwilcox> Opinions seem to differ slightly, but yeah.
 77 2014-12-18 13:02:28 <hearn> iwilcox: nah that sort of question tends to be fine here
 78 2014-12-18 13:02:34 <hearn> iwilcox: #bitcoin is more for general end user chatter
 79 2014-12-18 13:03:27 <sipa> abishek: if you enable -txindex, bitcoind will keep a full index of every transaction it has ever seen, and you can use getrawtransaction <txid> to get information about it
 80 2014-12-18 13:03:52 <sipa> abishek: note that this means slower syncing, and more disk space usage (and it's incompatible with future pruning)
 81 2014-12-18 13:04:29 <sipa> abishek: in general, you should try to use watch-only addresses for something like this if possible, which makes the wallet fully track transactions as if they were yours, without needing the private key
 82 2014-12-18 13:07:04 <abishek> sipa, the problem that I currently have is, I am using a third party service to integrate merchant tools on my application. Though they have multiple levels of security, their API for integration is not complete, so am having a bit of trouble it getting the information about confirmations for the transaction that I am doing with them. If I receive the transactioNId from them, then I though I could query the blockchain locally from my wallet
 83 2014-12-18 13:07:05 <abishek> everytime the block changes.
 84 2014-12-18 13:12:52 <berndj> sipa, does that mean -txindex is deprecated in the long term, or just that you can't both -txindex and prune at the same time, or none of the above?
 85 2014-12-18 13:13:34 <sipa> berndj: it means -txindex won't be usable in combination with pruning, and that i consider that a reason why you should really consider an architecture that doesn't rely on it - but i understand it isn't always possible
 86 2014-12-18 13:14:45 <berndj> sipa, okay, i only -txindex because i like being able to study random transactions locally instead of having to rely on random web things to get info about tx and blocks and stuff
 87 2014-12-18 13:14:58 <sipa> that's a perfectly reasonable usa case
 88 2014-12-18 13:15:01 <sipa> *use case
 89 2014-12-18 13:15:23 <sipa> my only concern is that it encourages people to build really inefficient infrastructure
 90 2014-12-18 13:15:43 <sipa> but if you're doing analysis on the full block chain anyway, and the alternative is querying from a third party, duh
 91 2014-12-18 13:17:37 <berndj> sipa, and re your suggestion to use watch-only addresses, i've always wondered if there can exist transactions that you *can't* notice without having the private key?
 92 2014-12-18 13:18:05 <sipa> berndj: watch-only addresses should cover everything; you can specify just a raw script to watch for
 93 2014-12-18 13:32:05 <hearn> abishek: what provider doesn't expose confidence of transactions to you?
 94 2014-12-18 13:32:16 <hearn> abishek: that sounds like a pretty major issue
 95 2014-12-18 13:33:52 <abishek> not sure if I would like to mention the vendor, but they have an API that doesn't expose any blockchain transaction information at all currently either on their web console or on their API.
 96 2014-12-18 13:37:41 <wumpus> hearn iwilcox abishek: basic questions about the working of the system belong in #bitcoin, but specific questions about RPCs are fine here
 97 2014-12-18 13:40:30 <hearn> abishek: did you consider rolling your own with an api like json-rpc or bitcoinj?
 98 2014-12-18 13:42:53 <abishek> hearn, haven't chosen that option because a) it will require more development b) i have to spend a lot on securing my wallet. In the long run I would like to do that definetely
 99 2014-12-18 13:43:17 <abishek> hearn, and I definetly know that I can customize the hell out with my own wallet
100 2014-12-18 13:51:57 <hearn> abishek: this is a typical merchant scenario, right?
101 2014-12-18 13:53:13 <abishek> yes
102 2014-12-18 18:47:57 <proserpine-> is bitcoin core already using native c libsecp256k1?
103 2014-12-18 18:48:13 <proserpine-> USE_SECP256K1 doesnt seem defined
104 2014-12-18 18:48:18 <Luke-Jr> proserpine-: only for signing
105 2014-12-18 18:48:36 <proserpine-> Luke-Jr: in key.cpp?
106 2014-12-18 18:49:24 <Luke-Jr> proserpine-: I presume
107 2014-12-18 18:49:49 <sipa> proserpine-: indeed
108 2014-12-18 18:50:02 <sipa> USE_SECP256K1 is for verification, but doesn't actually work
109 2014-12-18 18:50:11 <sipa> but for signing it's always used
110 2014-12-18 18:50:16 <sipa> in 0.10 and master at least
111 2014-12-18 18:50:26 <proserpine-> ah right in 0.10
112 2014-12-18 18:50:46 <sipa> the 0.9 branch is a year old :)
113 2014-12-18 18:50:50 <proserpine-> shit i want to use it in my 0.9 fork
114 2014-12-18 18:50:52 <proserpine-> :)
115 2014-12-18 18:51:07 <Luke-Jr> (0.10 and master use different incompatible versions of libsecp256k1, note)
116 2014-12-18 18:51:28 <Luke-Jr> proserpine-: ##altcoin-dev if you're not doing Bitcoin (and if you are, why fork an old version?)
117 2014-12-18 18:52:37 <proserpine-> Luke-Jr: its an old fork of mine.... too many changes in 0.1
118 2014-12-18 18:52:41 <Luke-Jr> ah
119 2014-12-18 18:52:46 <sipa> well, your problem
120 2014-12-18 18:53:02 <Luke-Jr> proserpine-: there's not really much improvement from using libsecp256k1 for signing, IMO
121 2014-12-18 18:53:07 <Luke-Jr> I'd just wait until you upgrade
122 2014-12-18 18:54:03 <Luke-Jr> proserpine-: depending on what your goals are for your personal fork, you might find my personal fork useful (it's updated to 0.10) - on my git as 0.10.x-ljrF
123 2014-12-18 18:55:37 <proserpine-> Luke-Jr: will take a look - ty
124 2014-12-18 20:17:50 <proserpine-> really having trouble linking libsecp256k1, when i use the embedded one it throws undefined reference errors blah blah... with --with-system-libsecp256k1 it just fails to link somehow (bitcoind: error while loading shared libraries: libsecp256k1.so.0: cannot open shared object file: No such file or directory)
125 2014-12-18 20:18:11 <proserpine-> but its there at /usr/local/lib/libsecp256k1.so.0 ...
126 2014-12-18 20:18:52 <sipa> use the embedded one; the api is not stable, so things will brewak
127 2014-12-18 20:19:31 <proserpine-> ok
128 2014-12-18 20:19:52 <sipa> undefined reference probably means you're wrong the wrong version
129 2014-12-18 20:20:03 <sipa> as the API is still changing, you need to use bitcoin code that matches :)
130 2014-12-18 20:22:42 <proserpine-> well no, it's not that
131 2014-12-18 20:23:05 <proserpine-> secp256k1_open was undefined :s
132 2014-12-18 20:23:19 <sipa> there is no such thing
133 2014-12-18 20:23:25 <sipa> you mean secp256k1_start?
134 2014-12-18 20:23:36 <proserpine-> yes sorry that one
135 2014-12-18 20:23:44 <sipa> if that's the case, you're just not linking against libsecp256k1.la
136 2014-12-18 20:24:18 <proserpine-> i am
137 2014-12-18 20:28:15 <Luke-Jr> sipa: .la is basically never used anymore
138 2014-12-18 20:28:28 <Luke-Jr> proserpine-: are you trying to use it for validation?
139 2014-12-18 20:28:49 <proserpine-> Luke-Jr: signing
140 2014-12-18 20:30:38 <sipa> tdlfbx: so my point is that any software doing multisig already needs some way to communicate the public keys anyway; i can't imagine why that same channel couldn't just transfer the whole script, and not bother what the order is
141 2014-12-18 20:31:02 <Luke-Jr> proserpine-: can you pastebin the full thing? is this with my branch?
142 2014-12-18 20:31:16 <tdlfbx> A half-complete script?
143 2014-12-18 20:31:38 <sipa> tdlfbx: why half?
144 2014-12-18 20:31:44 <tdlfbx> Don't have all the keys yet.
145 2014-12-18 20:31:53 <sipa> then you can't do anythin at all
146 2014-12-18 20:32:02 <gmaxwell> have them for what? you need to be more concrete.
147 2014-12-18 20:32:49 <proserpine-> Luke-Jr: no it's not from your branch, your branch builds just fine.. i'm going to have a few more go's at it first
148 2014-12-18 20:33:49 <sipa> tdlfbx: so say you have three parties that decide they're going to construct a p2sh address for a 2-of-3 of them
149 2014-12-18 20:33:53 <Luke-Jr> proserpine-: then what branch? master doesn't have any --with-system-libsecp256k1 option
150 2014-12-18 20:34:01 <sipa> tdlfbx: these parties need to communicate in some way
151 2014-12-18 20:34:15 <sipa> tdlfbx: typically, they'll have some central hub at least acting as a meeting point
152 2014-12-18 20:34:23 <sipa> tdlfbx: that hub can decide the order of the keys
153 2014-12-18 20:34:45 <sipa> i'm not saying your idea isn't valuable, but it's really very minimal benefit imho
154 2014-12-18 20:35:02 <proserpine-> Luke-Jr: out of despair i've stolen those bits from your config/make scripts :p
155 2014-12-18 20:35:04 <tdlfbx> But there doesn't have to be a hub.  Just imagine 3 people emailing/IM'ing keys.  All 3 end up with the keys.  None of the 3 now knows what of the 6 addresses to use.
156 2014-12-18 20:35:28 <sipa> tdlfbx: one of them gathers the keys, sends it to the rest, done :)
157 2014-12-18 20:35:33 <sipa> tdlfbx: it's more efficient too :)
158 2014-12-18 20:35:42 <tdlfbx> ;-)
159 2014-12-18 20:35:46 <sipa> (2N communications instead of N^2(
160 2014-12-18 20:36:06 <sipa> tdlfbx: and yes, i agree, there is no strict requirement for a hub
161 2014-12-18 20:36:18 <Luke-Jr> proserpine-: each change in my branch also has its own independent branch that can be merged (but I wouldn't advise it in this case - messing with libsecp256k1 is more trouble than it's worth usually)
162 2014-12-18 20:36:21 <sipa> but on the other hand, it's also way more flexible that way
163 2014-12-18 20:37:16 <sipa> as it can do more than M-of-N
164 2014-12-18 20:37:26 <sipa> (like A-or-(B-and-C))
165 2014-12-18 20:38:12 <tdlfbx> So what I need is any use case in which multisig parties each end up with all the keys (somehow) but do not end up with the address.
166 2014-12-18 20:38:35 <tdlfbx> Because there's no use case where having M! possible addresses is useful for anything, as far as I can tell.
167 2014-12-18 20:38:38 <sipa> well if you don't have such a use case, what problem are you trying to solve? :)
168 2014-12-18 20:38:59 <tdlfbx> The problem of contributing usefully to bitcoin.  :-P
169 2014-12-18 20:39:25 <tdlfbx> M! is just untidy...
170 2014-12-18 20:39:36 <sipa> there are many things untidy
171 2014-12-18 20:39:39 <sipa> doesn't mean they're a problem
172 2014-12-18 20:40:15 <tdlfbx> Tidy is comprehensible and extensible.  If the goal is to keep bitcoin an incomprehensible mess...
173 2014-12-18 20:40:46 <tdlfbx> Perhaps if there's a time lag between key communication...or adding a party to a multi-sig authority...
174 2014-12-18 20:41:03 <sipa> the reason i'm pushing back, is because what you're trying to solve sounds like humans trying to agree on a script given the keys
175 2014-12-18 20:41:12 <sipa> or something only humans would find a problem, at least
176 2014-12-18 20:41:21 <sipa> and i don't think humans should be touching or seeing keys at all
177 2014-12-18 20:41:35 <tdlfbx> Why?
178 2014-12-18 20:41:48 <sipa> we're terrible at dealing with cryptographic material
179 2014-12-18 20:41:57 <tdlfbx> I'm rather baffled that bitcoin hides keys with addresses.
180 2014-12-18 20:42:12 <sipa> addresses are still cryptographic material; humans shouldn't need to see those
181 2014-12-18 20:42:46 <sipa> (i don't mean to say that it should be impossible to see them - just that no common use case should rely on it)
182 2014-12-18 20:43:11 <tdlfbx> In some ways I agree with you.  But if humans never see those, they instead see a big button that says "do magic shit" and they have no idea the origin, trust, or function of that button.
183 2014-12-18 20:43:21 <sipa> maybe
184 2014-12-18 20:43:40 <sipa> it should be absolutely possible to learn and understand and dig into what the button does
185 2014-12-18 20:43:43 <tdlfbx> Just as I know my bank account number...and I wouldn't want to *not* know it.
186 2014-12-18 20:44:03 <tdlfbx> digging into the function of buttons in software is much harder than verifying account numbers.
187 2014-12-18 20:45:39 <tdlfbx> I think that means I win.
188 2014-12-18 21:05:04 <ajweiss> that's a false equivalence.  account numbers are just big magic buttons, now go and try to explain all the machinations that take place when you present one in a financial transaction...
189 2014-12-18 21:07:46 <ajweiss> hey sipa are you there?
190 2014-12-18 21:11:00 <tdlfbx> It's not a perfect analogy.  But there is an understanding of how they work.
191 2014-12-18 21:14:28 <tdlfbx> People understand account numbers, routing numbers, phone numbers, and in Europe, OTP's too.  They're not too dumb to understand PKI.
192 2014-12-18 21:14:34 <ajweiss> i toyed around with a greasemonkey script for converting all the hashes on blockchain.info to 40-bit word representations
193 2014-12-18 21:14:50 <ajweiss> it's a little better
194 2014-12-18 21:15:28 <ajweiss> mostly just entertaining
195 2014-12-18 21:15:42 <belcher> depending on the person, they might actually feel better about btc if they feel they understand the details
196 2014-12-18 21:16:06 <belcher> or at least think they understand :)
197 2014-12-18 21:17:23 <Luke-Jr> tdlfbx: addresses are not like account numbers, routing numbers, phone numbers, etc
198 2014-12-18 21:17:34 <Luke-Jr> which is part of the problem with addresses
199 2014-12-18 21:17:57 <tdlfbx> Well I know.  I'm only talking about the level of understanding of users.  Users *understand* account numbers.  They could understand PKI too.
200 2014-12-18 21:19:07 <tdlfbx> The philosophy sipa was touting above...to hide everything behind software, I think is flawed.  It brings everything back to trust.  (In the software authors)  We should be visually verifying and understanding what our keys are doing, in ways that can't be circumvented by clever software.
201 2014-12-18 21:21:05 <Luke-Jr> tdlfbx: if you don't trust your software, you're screwed.
202 2014-12-18 21:22:26 <tdlfbx> My point exactly.
203 2014-12-18 21:27:43 <jzk> tdlfbx: looks can be deceiving
204 2014-12-18 21:29:18 <tdlfbx> jzk: in what ways could looks NOT be deceiving.  Banks in Europe for instance show you an entry from your one-time-pad for each transaction.  Very hard to fake in software or MITM.
205 2014-12-18 21:29:23 <Luke-Jr> tdlfbx: if you don't trust your software, you're screwed *regardless* of what you're saying
206 2014-12-18 21:30:03 <kadoban> Sorry if off topic, but be careful bitcoin devs: https://github.com/blog/1938-git-client-vulnerability-announced  remote execution git vulnerability just announced (on case-insensitive filesystems)
207 2014-12-18 21:31:41 <Luke-Jr> oh, only c-i filesystems. I was expecting something more serious
208 2014-12-18 21:31:55 <Luke-Jr> does anyone actually have c-i fs? XD
209 2014-12-18 21:32:06 <ajweiss> stupid os x does
210 2014-12-18 21:32:21 <kadoban> Haha, I dunno. I know OS X can, and Windows? Or did they finally change that at some point?
211 2014-12-18 21:32:25 <harding> kadoban: thanks for the PSA.
212 2014-12-18 21:32:30 <Luke-Jr> meh, if someone is running a proprietary OS, they're basically already compromised
213 2014-12-18 21:36:01 <dhill> like linux?
214 2014-12-18 21:36:03 <dhill> :)
215 2014-12-18 21:37:29 <Luke-Jr> dhill: Linux isn't proprietary.
216 2014-12-18 21:38:51 <dhill> oh, yes, you are correct.. for some reason i was thinking binary blob
217 2014-12-18 22:02:03 <dhill> https://github.com/blog/1938-vulnerability-announced-update-your-git-clients
218 2014-12-18 22:05:42 <tdlfbx> 
ACTION does a git pull.

219 2014-12-18 22:05:48 <tdlfbx> 
ACTION realizes his mistake and screams in horror

220 2014-12-18 22:06:21 <gwillen> Note that you are only affected if your filesystem is case-insensitive (as far as I know.)
221 2014-12-18 22:06:21 <paveljanik> dhill, OOps
222 2014-12-18 22:06:42 <gwillen> so if you're on linux with a reasonable filesystem you're ok.
223 2014-12-18 22:06:43 <paveljanik> yup
224 2014-12-18 22:06:49 <paveljanik> and this is OS X default
225 2014-12-18 22:06:58 <paveljanik> but it is unusable so people don't use it 8)
226 2014-12-18 22:24:32 <Diablo-D3> https://github.com/blog/1938-git-client-vulnerability-announced
227 2014-12-18 22:34:21 <hearn> given that the first thing people do after a git checkout is generally run large piles of code written by someone else, i can't get too excited by such a bug
228 2014-12-18 22:34:31 <hearn> 
ACTION updates anyway

229 2014-12-18 22:35:42 <BlueMatt> hearn: well, at least some of us arent too trigger-happy on that front :p
230 2014-12-18 22:36:05 <BlueMatt> 
ACTION starts running his git client in his development vms instead of outside of them...

231 2014-12-18 22:57:05 <hearn> BlueMatt: don't hate me but i'm writing a dns seed :)
232 2014-12-18 22:57:13 <hearn> BlueMatt: (actually https seed)
233 2014-12-18 22:57:16 <BlueMatt> hearn: good!
234 2014-12-18 22:57:22 <BlueMatt> ok, now I'm dissapointed :(
235 2014-12-18 22:57:32 <hearn> well, dns is sort of a crappy mechanism to fetch peers anyway
236 2014-12-18 22:57:33 <BlueMatt> why no dns?
237 2014-12-18 22:57:38 <hearn> i might add dns
238 2014-12-18 22:57:47 <BlueMatt> indeed, but it works, and we need more dnsseed operators
239 2014-12-18 22:58:05 <BlueMatt> (ie fits into current infrastructure nicely)
240 2014-12-18 22:58:26 <BlueMatt> note: there are still dragons hiding in that old net code with that kind of connection cycling, AFAIK
241 2014-12-18 22:59:46 <hearn> BlueMatt: it's been working OK for me so far. though i've only been crawling testnet
242 2014-12-18 23:00:01 <BlueMatt> well, its more of "let it run for a few days and see what happens" kind of dragons
243 2014-12-18 23:00:07 <BlueMatt> memleaks and the like, afaik
244 2014-12-18 23:00:51 <BlueMatt> and open 20/100 connections per second and see how it blows up
245 2014-12-18 23:01:54 <hearn> right, i haven't left it for a few days yet
246 2014-12-18 23:02:29 <hearn> i've added a throttle for successful connects/sec, but there are so many dead ips being distributed in getaddr responses that even with hundreds of attempted connects/sec, it's hard to get more than about 5-6 successful connects/sec on testnet
247 2014-12-18 23:02:53 <BlueMatt> its pretty similarly hard on mainnet, actually
248 2014-12-18 23:02:58 <BlueMatt> not that bad, but not good