1 2015-08-10 03:33:10 <phantomcircuit> harding, did i miss something about what you were saying on the ml?
  2 2015-08-10 05:34:00 <harding> phantomcircuit: I think you're looking for dgenr8, who is Tom Harding.  (I'm Dave Harding, a Bitcoin.org contributor.)
  3 2015-08-10 05:54:25 <phantomcircuit> harding, OOOH
  4 2015-08-10 05:54:37 <phantomcircuit> damn you people and the similar names
  5 2015-08-10 06:11:29 <Luke-Jr> lol
  6 2015-08-10 07:39:46 <jonasschnelli> Do i understand that right: Bip44 proposed a bip32chain like "m/44'/0'/0'/0/0 . The second last child is the external/internal chain switch and the last index is the child key at n. The two last elements use non hardened derivation. Is there a difference (security) between parent private key -> child public key AND parent public key -> child public key?
  7 2015-08-10 07:40:05 <jonasschnelli> Doesn't bip44 implies public key derivation?
  8 2015-08-10 07:40:32 <jonasschnelli> or what is the reason that the last two child keys are non-hardened?
  9 2015-08-10 13:01:20 <jonasschnelli> If i interpret the error repots correctly, most abuse mails where complaining fast flux botnet detection.
 10 2015-08-10 13:01:24 <wumpus> not sure how problematic that is in practice, sure, some nodes may get some more traffic than normal...
 11 2015-08-10 13:02:02 <jonasschnelli> It could be triggered by a 50+ dns response or by the low TTL (or by both things together)
 12 2015-08-10 13:02:21 <jouke> The problem would be the hosters shutting down the nodes of their customers.
 13 2015-08-10 13:02:53 <jouke> Oh, the problem with increasing ttl. sorry
 14 2015-08-10 13:03:06 <jonasschnelli> jouke: worst case. Yes. Mostly to do a warning shot.
 15 2015-08-10 13:03:33 <jonasschnelli> In my case they disconnected one of my servers...
 16 2015-08-10 13:03:56 <jouke> Yeah, one of our hosters was about to do the same :(
 17 2015-08-10 13:04:52 <jonasschnelli> The dns seeder application from sipa is – indeed – aggressive. 96 threads scanning the all getaddrs ip addresses (even in non routable spaces).
 18 2015-08-10 13:05:51 <jonasschnelli> But running a full node... common, that should really not trigger a malware detection...
 19 2015-08-10 13:09:09 <wumpus> jouke: wasn't that just about using too much bandwidth?
 20 2015-08-10 13:16:47 <jouke> wumpus: no that was an other hoster and was about using too much disk io
 21 2015-08-10 13:19:29 <jonasschnelli> But running a full node... common, that should really not trigger a malware detection...
 22 2015-08-10 13:19:36 <jonasschnelli> (sry, wrong window)
 23 2015-08-10 13:21:47 <jouke> But I don't think the seeder itself is problematic. Just the fact that our IP was returned by the seednode was reason enough to make a report to the hoster.
 24 2015-08-10 13:57:52 <melvster> i am creating a system that aims go give every github developer and every project a bitcoin address
 25 2015-08-10 13:58:14 <melvster> from what i can see most developers have 2048 bit rsa keys
 26 2015-08-10 13:58:21 <melvster> but most do NOT have bitcoin addresses
 27 2015-08-10 13:59:08 <melvster> is there any way I can use the entropy from an RSA key to create a workflow that allows people to donate to developers and projects in a decentralized way (ie no trusted third party in between)
 28 2015-08-10 14:00:05 <melvster> my thought right now is to create a raxtx, encode with the public key and then let the other person know ... but its not really user friendly
 29 2015-08-10 14:03:32 <melvster> main problem with the workflow is i want the tx to expire
 30 2015-08-10 14:03:45 <melvster> so it can be valid say for 1 week, then go back to sender
 31 2015-08-10 14:03:52 <melvster> i need almost the inverse of nlocketime
 32 2015-08-10 14:17:58 <wumpus> that depends. do you have the full RSA pubkey? if so, you can generate a privkey, send coins to accompanying address, encrypt it with the RSA pubkey, send it to the developer
 33 2015-08-10 14:18:31 <wumpus> then if (s)he doesn't swaap it in say a week, sweep back the funds
 34 2015-08-10 14:18:37 <wumpus> s/swaap/sweep
 35 2015-08-10 14:25:42 <hearn> melvster: a lot of devs don't want to receive bitcoin
 36 2015-08-10 14:25:53 <hearn> melvster: changetip/tip4commit/etc ran into that issue. so i'd recommend you not try that.
 37 2015-08-10 14:26:14 <wumpus> that's beside the point if he's asking how it can be done technically
 38 2015-08-10 14:27:18 <melvster> hearn: yeah i saw that whole debacle, but it was unsolicited tips ... that's why I wanted to make a workflow where the recipient could choose whether they accept a tip or return to sender ... a bit like the changetip workflow which seems to work quite well (imagine amazon :out for delivery", signed, returned type workflow)
 39 2015-08-10 14:27:21 <wumpus> the problem that most devs have with tip4commit is that it pays out per commit, which is a nonsense measure - also it pays out very small amounts
 40 2015-08-10 14:27:45 <melvster> wumpus: also true
 41 2015-08-10 14:27:48 <hearn> melvster: well ..... if you want devs to solicit payments, then they can just do so by publishing a bitcoin address, right?
 42 2015-08-10 14:28:10 <hearn> or a .paymentrequest file etc
 43 2015-08-10 14:28:30 <wumpus> haven't heard any complaints about changetip, if you don't want the tip you can just not claim it, at least it doesn't autospam all developers on a project
 44 2015-08-10 14:29:00 <melvster> hearn: not really easily, github doenst have a field for bitcoin public keys, only ssh public keys (i may be wrong there!)
 45 2015-08-10 14:30:18 <hearn> melvster: README files :-)
 46 2015-08-10 14:30:32 <hearn> wumpus: changetip is a really nice service
 47 2015-08-10 14:30:36 <hearn> centralised though. it's effectively a little bank
 48 2015-08-10 14:30:51 <melvster> hearn: ah yes that works too, in the README, id like it to be a bit more automated tho if possible
 49 2015-08-10 14:30:56 <wumpus> right, it is very centralized
 50 2015-08-10 14:31:13 <melvster> wumpus: yes that's fine, but requires a trusted third party (changetip) ... I can do that, but was wondering if the bitcoin protocol allows anything a little more "Zero trust"
 51 2015-08-10 14:31:37 <hearn> melvster: i guess the question is, why overcomplicate this? you can also just email someone a transaction+private key. or could if there was a standardised format for that.
 52 2015-08-10 14:31:44 <wumpus> melvster: I don't think this is a matter of the bitcoin protocol, but what github offers to put on profile
 53 2015-08-10 14:31:48 <hearn> it's a feature i wanted to add to lighthouse actually
 54 2015-08-10 14:31:51 <hearn> "gift cards" :)
 55 2015-08-10 14:32:48 <wumpus> melvster: I don't think you can access arbitrary dev's public RSA key, can you?
 56 2015-08-10 14:33:05 <melvster> hearn: check out : https://github.com/mikehearn.keys
 57 2015-08-10 14:33:24 <hearn> an SSH key?
 58 2015-08-10 14:33:26 <melvster> yes
 59 2015-08-10 14:33:32 <melvster> rsa 2048 bit is the norm
 60 2015-08-10 14:33:33 <hearn> i'm actually not totally sure which private key that corresponds to!
 61 2015-08-10 14:33:40 <hearn> i suspect this was created by the github desktop app?
 62 2015-08-10 14:34:00 <hearn> anyway, i guess the issue is, if you send someone a small payment, the overhead of collecting it has to be really low
 63 2015-08-10 14:34:04 <melvster> would normally be ~/.ssh/id_rsa
 64 2015-08-10 14:34:27 <hearn> yeah but it's not
 65 2015-08-10 14:34:35 <hearn> my id_rsa.pub contains a different pubkey
 66 2015-08-10 14:34:47 <melvster> oh ok
 67 2015-08-10 14:34:50 <hearn> i don't recall ever explicitly uploading an ssh key to github. i think it must have been done automatically
 68 2015-08-10 14:35:12 <melvster> you can check in your settings, there may be a label there
 69 2015-08-10 14:35:40 <melvster> so i could send a private key -- BUT -- private keys are some times destroyed when new transactions come in
 70 2015-08-10 14:35:44 <melvster> same goes for raw tx
 71 2015-08-10 14:38:46 <melvster> hearn: in your case I could send you a private key (encypted) but since you dont know where you SSH key is, you would not be able to spend it ... so the sender needs to then take that into account and 'revoke' the key
 72 2015-08-10 14:39:20 <melvster> i want to avoid lots of spam, and avoid a centralized workflow
 73 2015-08-10 14:40:38 <wumpus> "private keys are some times destroyed when new transactions come in" huh?
 74 2015-08-10 14:40:59 <melvster> wumpus: sorry what i mean is that the funds associated with a private key may move over time
 75 2015-08-10 14:42:00 <melvster> oh i guess, it's not too much a problem if you construct the private key specifically
 76 2015-08-10 14:42:02 <melvster> and then you have to set up the private key to have the *exact* amount you want to send, normally that would require sending a new tx
 77 2015-08-10 14:42:17 <wumpus> eh, you certainly shouldn't export one of your wallet's private keys
 78 2015-08-10 14:42:49 <wumpus> yes you would generate it specifically to send it
 79 2015-08-10 14:43:00 <melvster> ok agree, bad thought, you could use a brain wallet type private key ...
 80 2015-08-10 14:43:25 <melvster> however it requires sizing the amount by sending a tx ...
 81 2015-08-10 14:43:58 <melvster> whereas sending a raw tx would only be spent when the receiver decodes it
 82 2015-08-10 14:44:34 <melvster> wumpus: because they're public
 83 2015-08-10 14:44:41 <melvster> it's github policy
 84 2015-08-10 14:44:45 <wumpus> they do match awhat is actually on the devices here
 85 2015-08-10 14:44:54 <melvster> sure
 86 2015-08-10 14:45:31 <melvster> yes possibly
 87 2015-08-10 14:46:09 <melvster> wumpus: but it's useful because i can send you encrypted text for example using your ssh public key, and only you can read it ...
 88 2015-08-10 14:46:39 <wumpus> right, that'd be possible, altough: is there any usable tooling for that?
 89 2015-08-10 14:47:43 <melvster> wumpus: i just wrote some node scripts to do exactly that :)
 90 2015-08-10 14:47:57 <wumpus> okay
 91 2015-08-10 14:50:12 <melvster> wumpus: if you're interested *work in progress* https://github.com/gitpay/util
 92 2015-08-10 14:50:30 <melvster> ive done encrypt / decrypt / sign / verify so far
 93 2015-08-10 14:50:39 <melvster> but want to build btc related stuff next
 94 2015-08-10 14:52:14 <melvster> then ill package them up and make a nodejs util you can run from CLI
 95 2015-08-10 15:20:19 <Luke-Jr> jonasschnelli: is there *any* evidence the TTL is relevant?
 96 2015-08-10 15:20:32 <jonasschnelli> Luke-Jr: nope.
 97 2015-08-10 15:20:57 <jonasschnelli> But most fast flux detections does somehow weight the TTL
 98 2015-08-10 15:38:46 <jonasschnelli> Luke-Jr: i think a DNS response of around 20 IPs with a TTL each <60s is very suspicious for a fast flux detection algorithm...
 99 2015-08-10 15:43:34 <Luke-Jr> jonasschnelli: unless the people detecting this crap have said that's their criteria, I don't see a reason to change it
100 2015-08-10 15:44:13 <Luke-Jr> or at least someone having done testing to show it matters
101 2015-08-10 17:57:04 <phantomcircuit> jonasschnelli, the bitcoin seed stuff obviously looks like fast flux.... because it is!
102 2015-08-10 17:57:26 <phantomcircuit> but that isn't a good reason to send an automated letter to someones ISP
103 2015-08-10 17:57:58 <phantomcircuit> in fact i would bet that the people sending those letters are breaking defamation laws in a bunch of contries
104 2015-08-10 17:58:03 <phantomcircuit> countries*
105 2015-08-10 17:58:54 <jonasschnelli> phantomcircuit: I think with a response of 10 IPs per DNS request/response and a TTL of 3600s it would be not detected by most ff malware detection.
106 2015-08-10 18:00:05 <phantomcircuit> jonasschnelli, it's literally a fast flux network though
107 2015-08-10 18:02:03 <jonasschnelli> phantomcircuit: Yes. Kind of. But because every node can response to p2p getaddr, the fast in the flux is not really required. Most botnet DNS systems probably require TTLs around 60s.
108 2015-08-10 18:03:30 <phantomcircuit> jonasschnelli, iirc state of the art is now p2p botnets with the dns stuff just being an introduction point
109 2015-08-10 18:03:45 <phantomcircuit> which is probably why they're being super aggressive with the abuse complaints
110 2015-08-10 18:03:53 <phantomcircuit> it's a losing battle for sure though
111 2015-08-10 18:04:17 <phantomcircuit> they're not going to get domain names that only need to be online for an hour taken down fast enough
112 2015-08-10 18:04:49 <jonasschnelli> Maybe we should reconsider mike hearns httpseed: https://github.com/mikehearn/httpseed
113 2015-08-10 18:05:16 <jonasschnelli> would be more flexible than DNS, hard to detect (https) but not ISP caching/distirbution.
114 2015-08-10 18:05:44 <jonasschnelli> i think they use it in bitcoinXT?
115 2015-08-10 18:07:21 <jonasschnelli> obviously it would require to rewrite it in a different language than java. :)
116 2015-08-10 18:07:44 <Luke-Jr> jonasschnelli: problem is that it gives seeds too much info
117 2015-08-10 18:07:55 <Luke-Jr> right now, we have layers of caching proxies built-in
118 2015-08-10 18:09:02 <jonasschnelli> Luke-Jr: Yeah. That's indeed an issue.
119 2015-08-10 18:10:07 <Luke-Jr> maybe TXT records would be sufficient
120 2015-08-10 18:12:09 <Luke-Jr> can we easily serve TXT, and failover to A/AAAA only when that is blocked?
121 2015-08-10 18:12:27 <Luke-Jr> sipa should be here.. :/
122 2015-08-10 18:13:32 <ajweiss> i thought most malware used DGAs, rather than rapidly changing A records...
123 2015-08-10 18:14:29 <jonasschnelli> IIRC sipa once told me that serving TXT would require to change the way how the seeder handle DNS queries,.. at the moment it uses OS functions... TXT would require special implementation i guess.
124 2015-08-10 18:15:01 <dgenr8> phantomcircuit: i'm sticking by "we'll see".  the problem with gold lease rates is too many people think there's actual gold in the vaults.
125 2015-08-10 18:15:24 <Luke-Jr> ajweiss: the use of fast-flux A records appears to be to run phishing sites
126 2015-08-10 18:15:31 <jonasschnelli> My idea was to patch a djbdns (D. Bernsteins DNS implementation in C) to server crawled data.
127 2015-08-10 18:15:50 <jonasschnelli> Would not be that hard... maybe 1-2 weeks of effort.
128 2015-08-10 18:15:54 <Luke-Jr> ajweiss: not for C&C
129 2015-08-10 18:16:12 <ajweiss> you'd have to learn djbc : )
130 2015-08-10 18:16:36 <ajweiss> substdio and all the rest
131 2015-08-10 18:16:46 <jonasschnelli> his c is code is like good Italian spaghetti... :)
132 2015-08-10 18:16:51 <jonasschnelli> but very stable.
133 2015-08-10 18:17:32 <phantomcircuit> ajweiss, DGA?
134 2015-08-10 18:17:33 <ajweiss> the top level programs are hard to read, unless you know all his support libs
135 2015-08-10 18:18:49 <ajweiss> phantomcircuit: a lot of malware will generate psuedorandom domain names and probe them for command and control servers
136 2015-08-10 18:19:30 <phantomcircuit> ajweiss, oh domain generation algorithms right
137 2015-08-10 18:19:50 <phantomcircuit> ajweiss, iirc the state of the art is to have them act as introduction points into a p2p network
138 2015-08-10 18:19:58 <ajweiss> naw the seeder builds its own dns responses
139 2015-08-10 18:20:42 <ajweiss> i had a poke through here before looking to see how hard it would be to add support for blacklisting bogon addresses
140 2015-08-10 18:20:47 <jonasschnelli> ajweiss: i once tried to add TXT support... it wasn't easy IIRC.
141 2015-08-10 18:21:33 <ajweiss> wasn't there another objection to using TXT records?
142 2015-08-10 18:21:59 <ajweiss> i liked that idea as well, but i thought someone said that some ISPs filter them
143 2015-08-10 18:22:32 <ajweiss> (this all came up when you added the xor'd address support to core iirc)
144 2015-08-10 18:25:26 <ajweiss> has anyone actually reported any issues with the current setup?
145 2015-08-10 18:26:40 <jonasschnelli> You mean DNS / ISP blocking issues? https://github.com/sipa/bitcoin-seeder/pull/31#issuecomment-129428140
146 2015-08-10 18:27:50 <gmaxwell> jonasschnelli: setting a ttl of 3600 would result in really bad hotspotting (especially with only 10 results)
147 2015-08-10 18:29:42 <gmaxwell> jonasschnelli: TTLs of a few seconds are common in practice in any case, so that can't be what they're triggering on.
148 2015-08-10 18:30:05 <gmaxwell> (lots of services use DNS for geographic load balancing)
149 2015-08-10 18:30:09 <ajweiss> looks like google is 60s
150 2015-08-10 18:30:38 <gmaxwell> ajweiss: IIRC thats the minimum any dns seed should be
151 2015-08-10 18:31:59 <ajweiss> perhaps the difference is that the seeder replies with a different batch of addresses on every request?
152 2015-08-10 18:39:21 <ajweiss> ooh yikes, it looks like people detect these things based on number of ASNs returned for a specific domain/host over a healthy stretch of time
153 2015-08-10 19:16:26 <gmaxwell> ajweiss: yea, that sounds plausable.
154 2015-08-10 19:29:19 <ajweiss> interesting and complicated problem.
155 2015-08-10 19:35:21 <gmaxwell> It could probably by greatly improved by someone writing a nice essay,  "The internet's war on distributed systems" that laments anything that it's a major commercial service is randomly subjected to varrious blocking because of anti-abuse crusaders being short sighted.
156 2015-08-10 19:39:21 <ajweiss> it's one of those funny things though, as one of the design goals is to try to make it hard to stop/censor... which is a property shared with many abusive practices...
157 2015-08-10 19:39:41 <ajweiss> hard to stop/censor and decentralized
158 2015-08-10 19:41:08 <gmaxwell> ajweiss: if it were only that it wouldn't be so bad, but e.g. go run your own SMTP server-- even if its configured perfectly, if it isn't one of the big hosted email providers (e.g. gmail/hotmail) you'll find your email intermittently and randomly blocked.
159 2015-08-10 19:41:36 <ajweiss> yeah i've heard that has become a nightmare
160 2015-08-10 19:41:57 <gmaxwell> It's worse when there are similarities, but since some huge percentage of users only use the internet in very narrow ways the agressive anti-abuse activity leaves the internet randomly broken for anything that isn't one of those ways, even if it looks very little like a botnet.
161 2015-08-10 19:42:47 <ajweiss> dmarc and mailing lists is a good example
162 2015-08-10 19:44:45 <phantomcircuit> ajweiss, i noticed that dmarc is breaking a bunch of other things as well
163 2015-08-10 19:52:45 <ajweiss> in any case, it seems like the "clean" solution in an ideal world would be to have the user go get some seed addresses on their own and manually enter them.  in practice that seems like it would be a disaster though///
164 2015-08-10 19:53:44 <phantomcircuit> ajweiss, amusingly there are actually enough publicly connectible nodes that scanning the entire internet searching for one would be annoying and ridiculous but not absurd
165 2015-08-10 19:54:18 <ajweiss> seems a little absurd to me : )
166 2015-08-10 19:54:33 <phantomcircuit> ajweiss, 6000 / (2**32) / 2
167 2015-08-10 19:54:49 <phantomcircuit> er
168 2015-08-10 19:54:50 <ajweiss> plus that sort of activity would look suspicious as well
169 2015-08-10 19:54:53 <phantomcircuit> 2**32 / 6000 / 2
170 2015-08-10 19:55:05 <phantomcircuit> amusingly less so than the dns stuff
171 2015-08-10 19:55:24 <phantomcircuit> it would take 357913 attempts on average to find a peer
172 2015-08-10 19:55:30 <phantomcircuit> a syn packet is 80 bytes
173 2015-08-10 19:55:33 <phantomcircuit> so 28MB
174 2015-08-10 19:55:51 <phantomcircuit> brb implementing fallback of the fallback of the fallback for peer discovery
175 2015-08-10 20:32:11 <hearn> jonasschnelli: cartographer/httpseed serves non-SSL with cache headers
176 2015-08-10 20:32:22 <hearn> jonasschnelli: so transparent HTTP proxies will sit in front and answer queries to it
177 2015-08-10 20:32:38 <hearn> jonasschnelli: however a better solution is just do the lookup via tor ....
178 2015-08-10 20:33:30 <hearn> and it's written in kotlin, not java
179 2015-08-10 20:36:53 <helo> until ipv6...
180 2015-08-10 22:03:56 <ajweiss> i'm much less interested in who the bus would be hitting, the interesting question is who would be driving the bus?
181 2015-08-10 22:24:42 <Luke-Jr> lol
182 2015-08-10 22:38:14 <phantomcircuit> hearn_, DNS is actually cached everywhere
183 2015-08-10 22:38:32 <phantomcircuit> http is actually not cached anywhere
184 2015-08-10 22:38:40 <phantomcircuit> it's meaningfully different
185 2015-08-10 22:39:12 <hearn_> http is often cached at the ISP level
186 2015-08-10 22:39:28 <hearn_> but you know that and we had this discussion already. i'm not going to have it again.
187 2015-08-10 22:47:36 <phantomcircuit> hearn_, prove it
188 2015-08-10 22:49:53 <ajweiss> i used to work for an isp and was responsible for setting up an http cache 17 years ago.  it was a piece of junk and we turned it off, but i wouldn't be surprised if transparent http caches are mature and in widespread use now...
189 2015-08-10 22:57:30 <gmaxwell> ajweiss: they're widely used in some places, e.g. .au.  They're fairly rare in the US except on mobile networks.  They're common enough that if you assume they aren't there they will break your service.
190 2015-08-10 22:57:59 <gmaxwell> there are also a number of other things which are similar but different in intent that are fairly common, e.g. censorware proxies.
191 2015-08-10 22:58:51 <gmaxwell> It's incompariable to DNS caching; but at the same time I wouldn't agree that its non-existant.  On enwp a couple years ago it looked like a couple percent of the traffic was going through third party proxies (from my recollection).
192 2015-08-10 23:00:29 <gmaxwell> ajweiss: the context here is that the universality of DNS recursive resolution and caching means that the DNS seed stuff is not an outright "phone home". (which is also why we've specified that DNS seeds should have a minimum TTL that isn't too low)
193 2015-08-10 23:00:43 <gmaxwell> (not to mention that very low TTLs just get ignored by some 'helpful' resolvers)
194 2015-08-10 23:01:12 <ajweiss> it's true it does just kinda distribute a ton of addressess all over the internet
195 2015-08-10 23:02:40 <gmaxwell> (though I also advised when we changed to this that we'd have the same problems we had with IRC... :( I'm somewhat surprised that its taken this long.)
196 2015-08-10 23:05:22 <ajweiss> maybe the quick solution would be to just return AAAA records with the prefix set to something that won't raise eyebrows
197 2015-08-10 23:06:34 <ajweiss> that at least fixes the wide distribution of ASNs problem
198 2015-08-10 23:06:49 <phantomcircuit> ajweiss, btw i wasn't joking about trying to find a peer by scanning the internets
199 2015-08-10 23:06:59 <gmaxwell> ajweiss: resolvers don't always return AAAA records. :(
200 2015-08-10 23:07:17 <gmaxwell> phantomcircuit: that _also_ gets you whiny letters from your ISP. :)
201 2015-08-10 23:07:20 <phantomcircuit> we should probably have a thread in the background doing that at low rates to avoid breaking nat on cheap routers
202 2015-08-10 23:07:42 <phantomcircuit> but that could potentially be a powerful way of avoiding network partitions
203 2015-08-10 23:08:49 <ajweiss> that's pretty bad netiquette
204 2015-08-10 23:08:58 <phantomcircuit> gmaxwell, i've done crazy stuff like scan the entire ipv4 space for bitcoin nodes and only gotten complaints from a single iranian university
205 2015-08-10 23:09:25 <phantomcircuit> ajweiss, rates slow enough to avoid knocking over cheap nat routers would be quite slow
206 2015-08-10 23:09:37 <gmaxwell> phantomcircuit: depends on your provider, many networks run local IDS on their outbound traffic (not so much public ISPs but corporate networks and universities); and doing that will light them up.
207 2015-08-10 23:09:39 <phantomcircuit> like 1 per 30 seconds
208 2015-08-10 23:09:52 <gmaxwell> well 1 per 30 seconds wouldn't but ... also not likely to find anything.
209 2015-08-10 23:10:07 <phantomcircuit> gmaxwell, the idea is to have everybody doing it
210 2015-08-10 23:10:31 <phantomcircuit> lol i setup an http server with aggressive cache controls
211 2015-08-10 23:10:35 <ajweiss> nobody would route port 8333 traffic ever again :)
212 2015-08-10 23:10:35 <phantomcircuit> within minutes of it being up
213 2015-08-10 23:10:36 <phantomcircuit> 45.55.147.255 - - [10/Aug/2015:19:07:48 -0400] "GET / HTTP/1.0" 200 151 "-" "Mozilla/5.0 (compatible; NetcraftSurveyAgent/1.0; +info@netcraft.com)"
214 2015-08-10 23:10:52 <gmaxwell> Netcraft is dying, netcraft confirms it.
215 2015-08-10 23:11:06 <phantomcircuit> gmaxwell, 1/30 seconds isn't going to light up anything anymore than bitcoin itself will
216 2015-08-10 23:11:49 <gmaxwell> phantomcircuit: I see what your'e suggesting, if all do it the aggregate rate is fairly high and will find things, even if a single node never does.
217 2015-08-10 23:12:09 <gmaxwell> I wouldn't put that at the top of my list for anti-partitioning, but it might be interesting.
218 2015-08-10 23:12:33 <phantomcircuit> gmaxwell, it's certainly not at the top of my list either... but it should be pretty easy to implement