--- Log opened Tue Nov 05 00:00:20 2013
00:05 < gmaxwell> p2pool effectively preforwards blocks to peers, and announces simultaniously from the whole p2pool network. in theory this confers some latency advantage, but it probably only just balances out poorly run nodes.
00:06 < gmaxwell> Although its at 103.2% of its alltime expectation, and that includes a swath of working before those changes when it was at <100% (though now its kind of relatively small compared to the current hashrate)
00:06 < gmaxwell> well, indeed "simultaneously"
00:06 < midnightmagic> gmaxwell: Are you able to translate this? https://twitter.com/eevee/status/397578223434752000
00:07 < gmaxwell> midnightmagic: the fix they propose introduces a vulnerability, though reasonable people could debate if it were better or worse.
00:08 < gmaxwell> basically, their fix makes a sufficently large pool (e.g. btcguild) _always_ have an incentive to delay, even if they're not doing any fancy stunts with annoncements of their delayed blocks.
00:08 < midnightmagic> gmaxwell: The fact that randomly switching to a second-heard block means half the hashrate switches to the new block and potentially erases the strength of growth of the longest chain?
00:08 < gmaxwell> (because you can announce late and half the honest miners (and yourself) will still mine on your blocks.
00:08 < gmaxwell> )
00:09 < midnightmagic> okay.
00:09 < petertodd> gmaxwell: yeah, interesting that they put that fix in their paper, and then on the list pointed out the other idea they had was a deterministic scheme
00:09 < petertodd> gmaxwell: I'll bet you the former was easier to analize....
00:13 < midnightmagic> :-(  may I trouble you to tell me which list? I'm on the bitcoin-development mailing list but I don't see any references to neither Sirer nor Eyal.
00:13 < midnightmagic> i guess that's either-or
00:13 < petertodd> midnightmagic: oh, I'll bet you they're stuck in a mod queue :(
00:13 < midnightmagic> doh
00:14 < midnightmagic> k, thanks.
00:14 < petertodd> midnightmagic: I can forward them to you, email?
00:14 < midnightmagic> sure. thetanix@gmail.com
00:16 < petertodd> sent
00:16 < midnightmagic> cool
00:22 < midnightmagic> wouldn't random-switch decrease overall blockchain growth rate the moment anyone began late-broadcasting?
00:23 < midnightmagic> and so.. yeah everyone would instantly switch to late-broadcasting, which kills it further
00:25 < midnightmagic> what happens when 4 or 7 blocks are late-broadcast?
00:25 < gmaxwell> you start getting big reorgs.
00:38 < petertodd> midnightmagic: you don't need to broadcast more than a single block at a time late
00:38 < petertodd> midnightmagic: in fact, you're better off only revealing your lead the minimum amount possible at a time, which will almost alway sbe a single block
00:41 < petertodd> midnightmagic: oh nvm, I missed the "everyone" part of what you're saying...
00:42 < gmaxwell> most departures from earliest best win are hard to analyize for convergence properties when you have multiple parties. :(
01:37 < pigeons> invite artforz, i mean jdillon
04:46 < pigeons> jeesh reporter, did the paper even claim things like "Bitcoin Protocol Vulnerability Could Lead To a Collapse"
04:50 < gmaxwell> pigeons: go look at the authors blog post thing, it made a bunch of over the top claims.
04:59 < pigeons> wow yeah they make good blog authors
05:01 < pigeons> well most people seem to agree mining needs to decentralize more, and yet the trend hasn't reversed yet. maybe scary headlines will work
05:02 < gmaxwell> no, because it's just being understood as "wrong"
05:02 < gmaxwell> It's hard to sell a nuanced message like "not wrong, but also not very urgent or um. doomful, and with limitations"
05:03 < pigeons> yeah
05:03 < sipa> "Some unknown combination of circumstances may be less safe than previously assumed, which may or may not apply to reality."
05:52 < TD> well
05:52 < TD> the good news is that some journalists do use the press center.
05:53 < TD> i was explaining all this to a guy from new scientist last night
10:56 < phantomcircuit> warren, man why are the centos people so annoying
10:56 < phantomcircuit> "hey guys i need python with hahslib and MySQLdb"
10:56 < phantomcircuit> "HAHAH UR GAY NOOB"
12:59 < K1773R> phantomcircuit: because they use centos ;)
13:40 < BlueMatt> amiller: thanks again for the network map/desktop background ( :) ), any luck figuring out what the patterns were?
13:41 < amiller> hah! no, not yet, the kid working on it disappeared
13:41 < amiller> he must have learned too muhc
14:16 < BlueMatt> amiller: heh, damn grad students
15:31 < gmaxwell> amiller: that connectivity graph looks concerning to me, but perhaps its an artifact of the visualization process.
15:31 < amiller> what about it?
15:32 < gmaxwell> amiller: can you generate some stats like the distrubition of path lengths between nodes?
15:32 < amiller> uh... diameter 8
15:32 < amiller> i have a degree distribution chart somewhere
15:32 < amiller> there are any number of ways in which our analysis can have errors/omissions and the clustering is just some default toy that came with our graph program gephiz
15:32 < gmaxwell> Yea, degree distribution and you have connectivity so you should be able to make a chart of shortest path distances.
15:33 < gmaxwell> Yea, I know your analysis has limits.
15:33 < amiller> what trends are concerning?
15:33 < amiller> (those would help us figure out what to ask, which we don't really have the best ideas for)
15:33 < gmaxwell> If there are discrepancies in the degree/pathlength distribution compared to what we'd expect for how we think it should be wired I'd like to figure out if thats just your measurment method or if something is wrong.
15:34 < amiller> mainly we'd like to try to identify by name/purpose the handful of extra high degree nodes, and understand the group of orange slightly-higher-than-average nodes that also seem mostly connected to each other
15:34 < amiller> here's degree distribution, we don't have shortest path length though but we should http://apps01.mywebapps.net/ajp/bc/degree.pdf
15:34 < gmaxwell> amiller: I think the graph seems to be showing a higher amount of sparely connected clustering than I expected.
15:35 < gmaxwell> also min-cut stats might be interesting.
15:36 < amiller> we have a lot of 1-connected nodes which i think is most likely a problem of us omitting things
15:37 < amiller> it kind of relies on us just connecting to everyone we can, and we can only connect to like half the public nodes because other nodes are saturated already
15:37 < amiller> and we don't particularly try very hard/long
15:46 < adam3us1> so with this selfish-pool attack - did anyone figure out if they are taking into account that the selfish-pool re-actively racing the honest miners, the miner or mining pool they are reacting to will not be convinced
15:49 < phantomcircuit> gmaxwell, the graph is certainly incomplete, indeed i believe it's impossible to come up with a complete network graph without all the remotely connectable peers cooperating
15:51 < gmaxwell> phantomcircuit: sure, since you can't even connect to a lot of nodes.
15:51 < phantomcircuit> gmaxwell, right and you cant know who is connected to peers you can connect to
15:51 < gmaxwell> adam3us1: yea, would be interesting to see their simulation code.. "you can never beat a block in a race to reach the announcer."
15:52 < phantomcircuit> so basically the graph ends up being a graph of connections to your listening nodes
15:52 < gmaxwell> phantomcircuit: you can, thats amiller's magic.
15:52 < phantomcircuit> how?
15:53 < gmaxwell> phantomcircuit: by taking advantage of double spend mutual exclusion. :)
15:53 < phantomcircuit> oh
15:53 < adam3us1> by which I mean say btc guild (30%) http://blockchain.info/pools used the selfish-pool algorithm, it is likely it will compete against ghash.io (20%) eligius (15%) etc as 82% of the network is pooled (possibly more) and so 52% is not controlled by btc guild
15:53 < phantomcircuit> interesting
15:53 < gmaxwell> phantomcircuit: its a cute idea, one which we should eventually build some countermeasures for. We kinda have some already.
15:54 < gmaxwell> amiller: you know that nodes don't immediately relay to all their peers, right?
15:54 < phantomcircuit> adam3us1, the orphan rate they calculated is lower than it would actually be due to there being large pools
15:54 < gmaxwell> we could probably make that more agressive.
15:54 < amiller> how don't they gmaxwell ?
15:54 < phantomcircuit> ironically large pools make the economics of their attack worse
15:55 < phantomcircuit> amiller, trickle
15:55 < amiller> trickly in terms of letting the thread wake up
15:55 < amiller> but no substnatial delay
15:55 < adam3us1> phantomcircuit: right, thats my point
15:55 < phantomcircuit> adam3us1, they did not even try to take that into account
15:55 < gmaxwell> amiller: the trickle sends some right away, some when the queue fills up.
15:56 < phantomcircuit> amiller, see SendMessages
15:56 < gmaxwell> amiller: I assume to close your probing we'll eventually make that more powerful, I've wanted to do that anyways.
15:57 < amiller> more powerful meaning more trickly or transmit faster?
15:57 < gmaxwell> amiller: more trickly
16:00 < amiller> our technique really doesn't rely on precise timing so i don't think that would help
16:02 < gmaxwell> amiller: it's not about timing, is that you can't tell a link exists if the transaction never traverses it.
16:02 < amiller> ok i thought i understood how trickle worked but i might be getting it wrong
16:03 < amiller> i thought trickl just sends them all out over a short period of time, with 25% probability each time it passes over the queue
16:05 < gmaxwell> amiller: no, it's basically 25% upfront, and then otherwise it only gets sent when a queue fills up, and only if it hasn't learned the transaction from the peer already.  But the effect is that e.g.  if node C is connected to both A and B  you might not be able to observe the B<>C link because B->C trickels and so C shows up via the A exclusion.   I think right now it won't stop you, but if made more powerful it might.
16:06 < amiller> interesting.
16:06 < gmaxwell> (the trickel is partially a bandwidth optimization today, it reduces the amount of INVs crossing in flight)
16:07 < gmaxwell> e.g. no point in A->B _and_ B->A
16:07 < amiller> the main observation we have made is that any obvious attempt at keeping node connections hidden leads to some kind of dos compromise
16:08 < gmaxwell> I think thats generally true but may not be meaningful. E.g. I could connect my node only to committers to bitcoin-qt. There is a "dos compromise" (they could all conspire to isolate me) but its not a meaningful one.
16:08 < adam3us> also the race is not normally random either - i would think the proportion of legitimate first within the propagation delay would be in relation to mining power, as even within the 15 sec propagation delay probably mostly its not that close
16:09 < adam3us> (driving the proportion the network that believes each win is first)
16:10 < amiller> is there a bitcoind command to inspect the trickle queue
16:10 < gmaxwell> I've also been thinking about in and out seperation. What if a node was really two nodes from the perspective of transaction relaying: one that only has outbound edges, and one that only has inbound edges.  The outbound edged node would be protected from self selecting connectors without a sybil attack.
16:10 < amiller> like to see the current number of elements in there, average time each items been in there, etc
16:10 < gmaxwell> amiller: gdb and go find them? :P
16:10 < amiller> thx :)
16:13 < adam3us> can multiple miners in a pool vote for different fork?  i think so when the client is doing its own validation?
16:14 < gmaxwell> adam3us: only p2pool. absent bitpenny, solo mining, and p2pool the only miners are the couple pools. The 'miners'— people with hardware— are mostly just people who are selling SHA256 computation to actual miners. They have very little visibility and basically no control over the mining process.
16:15 < gmaxwell> Luke was pushing for people to migrate to the getblocktemplate protocol which would have substantially put hashers in the mining loop... but slush did an endrun with a secretly developed protocol (stratum), which won in the market place because it used less bandwidth... but left hashers as blind as they are with getwork.
16:16 < adam3us> gmaxwell: that sucks - i thought getblocktemplate was the future
16:17 < gmaxwell> Luke's BFGminer software does make _some_ use of the limited visiblity that exists from the block headers. E.g. it can detect when a pool tries to mine a fork against its own prior work and can then switch.
16:17 < gmaxwell> adam3us: well, maybe it is still.. since subsiquently we did come up with another way of using it which is lower bandwidth. ("coinbase only mining" e.g. you only get your coinbase txn from the pool, everything else you do locally, and you merge the coinbase from the pool with your local work)... but the software for that doesn't exist yet.
16:18 < adam3us> so eligius at 15% plus whatever % direct mining < 18% so then the remaining 67% is a blind slave to a miner
16:18 < gmaxwell> People do use GBT some, but as said— stratum is lower bandwidth (because it doesn't send transaction data to miners… and really most hashers don't actually understand the tradeoffs here.
16:18 < Luke-Jr> adam3us: GBT is still the future - just further out now
16:19 < gmaxwell> Even most of eligius' miners are on stratum, as eligius supports stratum too (can't deny the market…)
16:19 < Luke-Jr> now it needs to wait for the ability to compete on bandwidth with stratum, instead of just getwork
16:19 < phantomcircuit> gmaxwell, that also has the problem that the pool then has to do a ton of work to verify the submitted shares
16:20 < Luke-Jr>  or at least a strong advantage
16:20 < adam3us> it seemed to me you could talk udp to a pool; just send it partial wins of what ever difficulty chunk you like
16:20 < Luke-Jr> phantomcircuit: not really
16:20 < gmaxwell> Luke-Jr: another way GBT could be used is to turn a pool's hashers into fast block announcers the way p2pool does.
16:20 < phantomcircuit> Luke-Jr, with coinbase only?
16:20 < phantomcircuit> Luke-Jr, that's what i was talking about
16:20 < gmaxwell> phantomcircuit: no they don't. Beyond spot checking accidentaly misconfiguration ... the intentional case is precisely identical to blockwithholding which can _never_ be detected.
16:20 < Luke-Jr> phantomcircuit: you can cache most of the hashing
16:21 < Luke-Jr> gmaxwell: bfgminer does support that, but I don't think anyone uses it :/
16:21 < adam3us> so far it seems like even GBT is handing out work, this is unnecessary; the client can chose a random starting point and pay to pool address
16:21 < phantomcircuit> Luke-Jr, yeah im just saying that someone intentionally being a nuisance could continuously rearrange transactions
16:21 < adam3us> in that way the client can chose its own work size to suit its power
16:22 < Luke-Jr> adam3us: share difficulty must be predetermined at least
16:22 < gmaxwell> adam3us: you can send flags to GBT, e.g. request only a coinbase  (+header).. I don't think such a flag exists today but it would be trivial to add.
16:22 < phantomcircuit> adam3us, as it stands most pools are issuing 64bits of work per stratum notify
16:22 < Luke-Jr> gmaxwell: pretty sure it does, just not implemented yet
16:22 < phantomcircuit> which is tons
16:22 < adam3us> phantomcircuit: my point is its a waste of interactive bandwidth and round-trips
16:22 < Luke-Jr> phantomcircuit: but stratum can only subdivide in 8-bit chunks, so multiple proxies would chew it up fast
16:22 < adam3us> all you need technically is the pools reward address
16:22 < gmaxwell> Luke-Jr: we could promote miner announcement as a feature which helps with this silly news (in two ways, prevents a pool from being a delayer, and also makes honest pools faster to announce)
16:23 < Luke-Jr> adam3us: for some pools..
16:23 < phantomcircuit> Luke-Jr, well... theoretically you could allow miners to just submit anything with the right prevblock hash and coinbase output then calculate the apparent difficulty of the share and use that instead
16:23 < phantomcircuit> Luke-Jr, it would be fair but only over a large sample
16:23 < gmaxwell> phantomcircuit: no you can't!
16:23 < gmaxwell> phantomcircuit: would you give 25 btc to every miner who finds a block? :P
16:23 < phantomcircuit> gmaxwell, yeah you can but it ends up being a mini lottery
16:24 < phantomcircuit> gmaxwell, no?
16:24 < adam3us> gmaxwell, Luke-Jr: well if someone can figure out a way to reduce miner centralization while addressing the story that would be a nice side-effect win
16:24 < gmaxwell> phantomcircuit: thats what using the apparent diff would do. :P
16:24 < phantomcircuit> gmaxwell, uh no it wouldn't
16:24 < gmaxwell> phantomcircuit: sure it would ... what is the value of a diff 510929738.01615179 share
16:24 < gmaxwell> also WTF HAPPENED TO THE DIFFICULTY
16:24 < gmaxwell> did it just nearly double?!@$#
16:25 < gmaxwell> like .. I thought it was 310 this morning?!
16:25 < phantomcircuit> gmaxwell, nodes would be incentivized to submit everything they found
16:25 < phantomcircuit> so you'd get flooded with diff=1 shares
16:25 < phantomcircuit> technically it would work but it would be super annoying
16:25 < phantomcircuit> and also pointless since you could just count everything as 1
16:25 < Luke-Jr> gmaxwell: there http://bitcointroll.org/?topic=324413.msg3492597#msg3492597
16:26 < gmaxwell> phantomcircuit: in any case, GBT has what is needed, minus someone implemeting a request flag to say "don't send any transactions" and a response flag that says "I'll pay you so long as you have this coinbase, you can change everything"
16:26 < gmaxwell> Luke-Jr: can you add some config examples for BFGMINER?
16:26 < gmaxwell> e.g. how do you configure the announcement?
16:26 < phantomcircuit> Luke-Jr, ha that's neat
16:27 < Luke-Jr> gmaxwell: I think you put #allblocks in the bitcoind pool URI
16:27 < gmaxwell> Luke-Jr: also, you should revise to say "it's not possible for pools to do this without miner cooperation" or something like that.
16:27 < Luke-Jr> -o gbt.mining.eligius.st:9337#allblocks
16:27 < Luke-Jr> err
16:27 < Luke-Jr> -o un:pw@localhost:8332#allblocks
16:27 < gmaxwell> Luke-Jr: cool, so you can even announce to other pools in addition to local stuff.
16:28 < gmaxwell> like -o 1apple:x@gbt.mining.eligius.st:9337#allblocks -o un:pw@localhost:8332#allblocks  ?
16:28 < Luke-Jr> gmaxwell: like this?
16:28 < Luke-Jr> http://bitcointroll.org/?topic=324413.msg3492597#msg3492597
16:28 < Luke-Jr> gmaxwell: you *can*, but they'd likely reject it :P
16:29 < Luke-Jr> http://codepad.org/oKSM9yUT
16:29 < gmaxwell> Luke-Jr: you should fix eloipool to accept notification of blocks that way. :P
16:29 < Luke-Jr> gmaxwell: ?
16:29 < Luke-Jr> oh, .. maybe
16:29 < gmaxwell> Luke-Jr: e.g. if someone mining on another pools finds a block and submits it to you, might as well take it and give it to bitcoind... though you might do some santization to prevent DOS with old blocks.
16:30 < Luke-Jr> gmaxwell: yeah, hard to do because to check we'd have to hash the block
16:30 < gmaxwell> In any case, post "just add -o un:pw@localhost:8332#allblocks as a backup pool to bfgminer and it will send all blocks you find to your local bitcoin daemon"
16:30 < gmaxwell> Luke-Jr: just check the prev== current prev. and difficulty over target. thats enough..
16:30 < Luke-Jr> gmaxwell: checking difficulty means hashing it
16:30 < gmaxwell> just hash the header.
16:31 < gmaxwell> check prev, which is a compare, hash the header— which is what you do to check if a share is good already, no?
16:31 < gmaxwell> an advantage of getting people to put eligius in their configurations is that you turn other pool's miners into block monitoring drones for you.
16:31 < gmaxwell> Plus you get people to setup eligius as a backup pool.
16:32 < gmaxwell> (some of whom won't care if they get paid if it falls over to it....)
16:32 < gmaxwell> plus you can announce it as a change you made to address the issue, which sounds nice.
16:34 < Luke-Jr> gmaxwell: currently we check the user and coinbase-scriptSig-prefix are known before we hash
16:34 < Luke-Jr> and wizkid057 is whinign about server overload stuff, although I can't imagine why it'd overload so easily
16:37 < gmaxwell> Luke-Jr: sounds broken, the hashing of the header should be superduper fast. hm.
16:37 < Luke-Jr> not faster than comparing two strings :P
16:39 < gmaxwell> yea, okay, but if it fails you could just ban the host... doesn't seem like a very useful attack. "I can make you do one pointless sha256 operation per IP!"
16:40 < Luke-Jr> …
16:41 < gmaxwell> Luke-Jr: what? if someone submits something that isn't valid work (either a share or a block solution), why not short term blacklist them? could even just be for 10 seconds.
16:41 < phantomcircuit> gmaxwell, you cant do that, a significant enough % of shares submitted are invalid that you'd block legitimate clients
16:42 < gmaxwell> phantomcircuit: invalid as in the hashes aren't good?!
16:42 < Luke-Jr> gmaxwell: becuase it happens normally
16:42 < Luke-Jr> not often, but it does
16:42 < Luke-Jr> especially with stupid miners
16:42 < gmaxwell> Luke-Jr: uh why aren't miners checking work before they submit it?
16:42 < Luke-Jr> dunno
16:42 < Luke-Jr> I guess that's harder to screw up with GBT..
16:43 < warren> gmaxwell: certainly we've seen that all miners and mining pool ops know what they're doing.
16:43 < phantomcircuit> gmaxwell, yeah i dont get it either but some % of shares submitted by cgminer end up missing the target
16:43 < warren> and understand the code they copied from a random github
16:44 < phantomcircuit> lol
16:45 < Luke-Jr> gmaxwell: heh, denying the authority we basically have seems futile - I'm just going to blame the community that empowers us by not make decisions
16:45 < Luke-Jr> making their own*
16:45 < Luke-Jr> phantomcircuit: well, that's cgminer
16:46 < phantomcircuit> Luke-Jr, i think i've seen it with bfgminer also over stratum but only at trivial amounts
16:46 < phantomcircuit> but certainly banning for a single failed hash wouldn't be a good idea
16:46 < gmaxwell> Luke-Jr: I think his comment is just psycho. he's railing about the bitcoin foundation as if that has anything to do with it.
16:46 < gmaxwell> (especially as if it had anything to do with bfgminer!)
16:46 < warren> bitcon foundation g*something miner
16:47 < Luke-Jr> lol
16:47 < warren> I couldn't think of an amusing g word.
16:47 < Luke-Jr> gmaxwell: well, it doesn't help that someone got a cert to sign B-Qt as "Bitcoin Foundation" :/
16:47 < Luke-Jr> warren: Bitcoin Foundation/Google Miner
16:47 < Luke-Jr> obviously
16:59 < BlueMatt> amiller: http://i.imgur.com/wGNyKLX.jpg (yes, the position of the title is rather arbitrary, but it works well as my desktop background)
17:00 < amiller> :)
17:00 < amiller> i'll let you know if we make a more accurate one :)
17:01 < BlueMatt> meh, I figure its probably pretty far off, but I dont care all that much
17:01 < BlueMatt> still looks cool
17:03 < amiller> :)
17:03 < gmaxwell> https://bitcointalk.org/index.php?topic=325737.msg3492937#msg3492937
17:12 < phantomcircuit> Luke-Jr, does #allblocks work if the stratum server supports get_transactions?
17:13 < Luke-Jr> no
17:13 < phantomcircuit> gmaxwell, sometime later this week i'll work on preventing amiller's mapping method
17:14 < amiller> pls dont
17:14 < phantomcircuit> gmaxwell, any suggestions beyond just improving the trickle out stuff?
17:14 < phantomcircuit> amiller, the problem is you could be mapping nodes to wallets
17:14 < phantomcircuit> which is a general privacy problem
17:15 < phantomcircuit> im sure you're not but
17:15 < gmaxwell> phantomcircuit: well mapping the network increases dos risks. e.g. map the connectivity in the region of a node of interest and DOS its peers.
17:15 < gmaxwell> Now you've isolated it.
17:15 < phantomcircuit> right
17:15 < phantomcircuit> im sure he isn't doing that
17:16 < phantomcircuit> but there are all kinds of problems with beign able to map the network
17:16 < gmaxwell> he's not, but his technique could be used to do so, if it were accurate enough.
17:16 < amiller> well, figure out how to fix it and just let me collect results before deploying it :o
17:18 < gmaxwell> sure sure
17:18 < phantomcircuit> amiller, i would assume that such a fix wont be part of a release for several weeks minimum
17:18 < phantomcircuit> you've got plenty of time
17:18 < amiller> k
17:18 < phantomcircuit> also fun fact i tried to record every message from the entire network but gave up after i filled a 2TB hdd in 15 days
17:18 < amiller> the grad student who's working on this has basically been working on it for 2 years now, he codes slowly
17:19 < phantomcircuit> (yes with extensive deduplication)
17:19 < phantomcircuit> amiller, you maybe want to put a fire under his butt then :/
17:19 < amiller> yep.
17:41 < MC1984_> amiller how are nodes grouped on that graph
17:52 < amiller> MC1984_, arbitrarily
17:52 < amiller> something about mutual connectedness
17:52 < MC1984_> i wondered if the orange cluster on the right was bci
17:53 < MC1984_> and the big yellow one top middle is probably the nsa amirite
17:54 < amiller> petertodd, did you make a javascript bitcoin network simulator and tell me about it some time
17:59 < petertodd> amiller: nope, never written a line of javascript in my life
17:59 < amiller> good, keep it that way
17:59 < amiller> petertodd, are you reeep
18:00 < amiller> not retep, but reeep
18:00 < petertodd> lol, nope
23:12 < midnightmagic> it's 25% iterative, capped when the queue for that peer fills up with enough waiting messages (in which case it floods it out), with a 100 millisecond granularity.
--- Log closed Wed Nov 06 00:00:26 2013