12015-11-22T00:08:33  *** guest234234 has joined #bitcoin-core-dev
  22015-11-22T00:14:45  *** guest234234 has quit IRC
  32015-11-22T00:26:38  *** ParadoxSpiral has quit IRC
  42015-11-22T00:30:42  <davec> gmaxwell: I have noticed that happening to me a while ago as well.  Unfortunately with there being impls like BitcoinJ (and probably others) that rely on that behavior can't really easily stop it
  52015-11-22T00:31:19  <davec> I haven't done any testing, but at one point I was considering doing some type of logic to only allow X unsolicited transactions in Y timeframe
  62015-11-22T00:31:25  <gmaxwell> davec: Part of the motivation for DOS in bitcoin core is that we could ban peers that do a lot of something while leaving others alone.
  72015-11-22T00:32:02  <gmaxwell> though I'd prefer to get bitcoinj fixed first; and have that just clean up whatever remains.
  82015-11-22T00:32:51  <davec> That is certainly preferred if the new maintainers are willing to change it
  92015-11-22T00:34:52  <CodeShark> I think they would given sufficient pressure ;)
 102015-11-22T00:35:15  <gmaxwell> We haven't asked the new maintainer yet, I think.
 112015-11-22T00:35:38  <gmaxwell> I was thinking of seeing if I could sweet talk bluematt into just sending a patch. :)
 122015-11-22T00:38:06  <BlueMatt> i know i know
 132015-11-22T00:38:10  <BlueMatt> i told you i would....
 142015-11-22T00:38:59  <BlueMatt> oh, this is unrelated to other things
 152015-11-22T00:39:07  <BlueMatt> yea, i mean you should be able to ping andreas
 162015-11-22T00:39:09  <gmaxwell> yea, actually I'm still waiting on the other thing. :)
 172015-11-22T00:39:18  <CodeShark> too late - now you've committed yourself to this as well!
 182015-11-22T00:39:37  <CodeShark> slick move, gmaxwell :)
 192015-11-22T00:39:54  <BlueMatt> gmaxwell: i think i saw someone else starting to implement that
 202015-11-22T00:40:05  <gmaxwell> BlueMatt: This is just the "bitcoinj sends unsolicitied full transactions, with no inv" ... which by itself isn't that awful, but as a result of tolerating it there are clowns now relaying every transaction they get this way.
 212015-11-22T00:40:09  <BlueMatt> but i havent looked closely
 222015-11-22T00:40:27  <BlueMatt> yea, ok
 232015-11-22T00:40:37  <BlueMatt> i mean we should really just disconnect people who relay something we've already seen
 242015-11-22T00:40:41  <BlueMatt> dont ban them, but disconnect them
 252015-11-22T00:40:51  <BlueMatt> if someone implements this in a broken way, they'll notice a ton of disconnects and stop
 262015-11-22T00:41:01  <gmaxwell> Hm, that we already have and didn't request from them? hm. that should actually be okay.
 272015-11-22T00:41:05  <BlueMatt> if its a wallet like bitcoinj doing it, the disconnects will almost never happen
 282015-11-22T00:41:36  <gmaxwell> (won't actually rescue blocksonly nodes from the noise, but thats fine)
 292015-11-22T00:42:05  <BlueMatt> blockonly nodes can also disconnect
 302015-11-22T00:42:18  <gmaxwell> I mean they'll never already have.
 312015-11-22T00:42:31  *** tulip has joined #bitcoin-core-dev
 322015-11-22T00:43:13  <BlueMatt> yes, but they can also disconnect
 332015-11-22T00:44:36  <davec> Well depending on the relay speed, that could cause BitcoinJ to get disconnected when the node they are relaying to saw it from elsewhere first (though given the time to process and re-relay, that should be exceedingly rare)
 342015-11-22T00:45:13  <davec> assuming the new tx is relayed to all connected nodes immediately that is
 352015-11-22T00:46:00  <CodeShark> race conditions are bad ;)
 362015-11-22T00:46:13  <gmaxwell> well getting disconnected is something that happens which you must be able to handle.
 372015-11-22T00:46:24  <gmaxwell> still best to get bitcoinj fixed.
 382015-11-22T00:46:47  <davec> I'm definitely in favor of getting BitcoinJ fixed and then tightening the protocol
 392015-11-22T00:47:09  <davec> I think it should be allowed for whitelisted nodes however
 402015-11-22T00:47:42  <davec> if you have a relay node, proxy, etc setup locally, requiring the extra round trip is probably not desirable
 412015-11-22T00:48:20  <gmaxwell> Well, it's probably irrelevant -- if your transactions are latency critical you're doing something wrong. But sure, I don't see a reason whitelisted hosts couldn't be excempted from that.
 422015-11-22T00:48:39  <gmaxwell> though since a peer doesn't know its whitelisted they shouldn't rely on that behavior.
 432015-11-22T00:48:51  <gmaxwell> main argument for it I see is enabling very simplistic scripts.
 442015-11-22T00:49:04  <CodeShark> yes, exempt whitelisted nodes...but in general, it would be best to send invs first if sending to multiple nodes
 452015-11-22T00:49:31  <davec> Right, I was thinking more for specialized nodes (like relay nodes or proxies, which know they're only talking to a local node)
 462015-11-22T00:50:39  <davec> of course, being local on what's probably a 1 or 10Gb link I doubt it would really make any difference anyways
 472015-11-22T00:51:01  <CodeShark> latency isn't really the issue with that, as gmaxwell said - but it simplifies the propagation logic
 482015-11-22T00:52:38  <CodeShark> disconnecting whitelisted nodes is probably a bad idea anyhow, though, since such incidents are more likely to be due to bugs or errors rather than DoS
 492015-11-22T00:52:57  <davec> agreed
 502015-11-22T00:52:57  <CodeShark> and you're not spamming anyone else
 512015-11-22T00:53:32  <CodeShark> although perhaps we could have a "strict mode" for testing clients
 522015-11-22T00:53:58  <CodeShark> use it for testing, not for production
 532015-11-22T00:54:37  <gmaxwell> I'd like that but am not sure that it's worth the code overhead unless it was just a milepost on the way to enforcing those things for everyone.
 542015-11-22T00:55:17  <gmaxwell> At some point just starting on a new, parallel, P2P protocol would be a better investment of time-- and of course that could be maximally strict from the start.
 552015-11-22T00:55:33  <CodeShark> yeah, you're probably right
 562015-11-22T00:56:26  <gmaxwell> doing so would allow replacing the inv process with something that actually scales, and so on.
 572015-11-22T00:57:46  <davec> while dreaming it would be nice to design it so things like I2P can work too
 582015-11-22T01:00:41  <gmaxwell> not just I2P, tor's next HS protocol has larger addresses.
 592015-11-22T01:01:11  <gmaxwell> Though those would be not so hard to shoehorn into ye'ole p2p compatbily.
 602015-11-22T01:01:52  <davec> yeah I think there was a patch running around for it at some point
 612015-11-22T01:06:38  <CodeShark> is it feasible (or even desirable) to move entirely to a tx propagation protocol where txs can be directly routed to miners and recipients rather than flooded?
 622015-11-22T01:07:46  <gmaxwell> I don't think it's particularly desirable.
 632015-11-22T01:07:58  <CodeShark> reasons?
 642015-11-22T01:08:48  <gmaxwell> makes mining more vulnerable to policy risk, dos attack etc. Also forwarding ahead reduces probagation times tremendously (with no caching at all it takes seconds to verify blocks now)
 652015-11-22T01:09:10  <gmaxwell> What I'd like to try doing is to do periodic set reconcillation of the top N mbytes of the mempool, and have that be the only relay mechenism in a p2p protocol.
 662015-11-22T01:09:49  <gmaxwell> This can get efficiency beyond the peers*transactions bound, and has nice anti-DOS properties.
 672015-11-22T01:11:03  <CodeShark> assuming blocks are flooded, all transactions that confirm must get flooded sooner or later...but things like RBF mean that many transactions might get flooded that never confirm
 682015-11-22T01:11:39  <CodeShark> whereas routing directly to miners (assuming it is practical) might allow direct fee bidding
 692015-11-22T01:11:51  <gmaxwell> with that only things likely to get mined soon relay, naturally. ... and it means that replacements that happen between the batching intervals get nicely suppressed. You can scale your bandwidth by scaling how deep and often you reconcile.
 702015-11-22T01:12:32  <tulip> it's effectively required that nodes in the network see transactions before they see them in blocks, 'blocksonly' with 'dbcache=100' frequently sees 20 second or higher times for block verification, I don't think there's any way around that.
 712015-11-22T01:12:41  <gmaxwell> CodeShark: in any case, I think you can take what you're thinking and relax a bit to public relay hubs and then we'd agree.
 722015-11-22T01:13:39  <gmaxwell> but as tulip notes, you don't want any mempoolless nodes in your block propagation critical path.
 732015-11-22T01:14:12  <gmaxwell> I want to get initial announcement of the p2p network in any case; because of privacy problems and the network attacks they're encouraging.
 742015-11-22T01:14:49  <gmaxwell> though I consider that largely orthorgonal to general relay changes.
 752015-11-22T01:15:50  <gmaxwell> tulip: I'm surprised it's that bad. :( might this be on a VPS with poor IO?
 762015-11-22T01:17:45  <tulip> gmaxwell: it's a lot better with a very large dbcache set (more like a normal node, though obviously still slower). that's on a 4+4HT core i7, 7200RPM 2.5" HDD.
 772015-11-22T01:19:01  <CodeShark> and disabling signature validation doesn't significantly reduce the time,  right?
 782015-11-22T01:19:20  <gmaxwell> well default dbcache is 100.  but okay, yea so signature checks won't have that big an effect (esp not since libsecp256k1; which I assume you're using if you're using blocksonly)
 792015-11-22T01:19:56  <tulip> CodeShark: is there a patch around for doing that?
 802015-11-22T01:20:25  <CodeShark> it's a one line change in the code, I believe
 812015-11-22T01:20:37  <CodeShark> trying to remember which line :)
 822015-11-22T01:20:56  <tulip> assuming I can just short circuit the checkpoints line.
 832015-11-22T01:21:02  <CodeShark> yeah, I think that's it
 842015-11-22T01:21:52  <gmaxwell> yes.
 852015-11-22T01:23:49  <tulip> (log snippet from blocksonly dbcache=100 http://pastebin.com/raw.php?i=JGSHbjwW )
 862015-11-22T01:26:17  <gmaxwell> if you've got bench on (I guess you do) you can see where the time is going.
 872015-11-22T01:26:26  <gmaxwell> The numbers in brackets are cumulative for the whole run.
 882015-11-22T01:29:17  <tulip> yep. http://pastebin.com/raw.php?i=QCkcLBNm
 892015-11-22T01:30:07  <davec> I'm with gmaxwell here on the announcement bit.  One of the things I've measured as a part of the multi-peer work is how much data transmission is avoided by keeping track of inflight data and avoiding re-requesting it and such.  It's roughly been on the order of 30-100MB/hr (depending on number of txns, connected nodes, etc)
 902015-11-22T01:30:08  <gmaxwell> wow, all the time in verify. interesting!
 912015-11-22T01:34:00  <gmaxwell> hm. I thought we had more resolution in verify. I can't distinguish signature checks from txin lookups. darn.
 922015-11-22T01:36:59  <tulip> guess more granularity wouldn't hurt.
 932015-11-22T01:37:04  <davec> that said, the idea of set reconciliation is pretty attractive and would save a lot more
 942015-11-22T02:04:35  <midnightmagic> ooookay, primary node validates itself just fine.
 952015-11-22T02:27:31  <GitHub188> [bitcoin] CodeShark opened pull request #7074: Added a command line option -scriptchecks (master...disable_script_checks) https://github.com/bitcoin/bitcoin/pull/7074
 962015-11-22T02:35:01  <GitHub106> [bitcoin] CodeShark closed pull request #7074: Added a command line option -checkscripts (master...disable_script_checks) https://github.com/bitcoin/bitcoin/pull/7074
 972015-11-22T02:35:53  <gmaxwell> CodeShark: hah sorry!
 982015-11-22T02:36:44  <CodeShark> ok, what about if disabling script checks also disables relay?
 992015-11-22T02:36:47  <CodeShark> :)
1002015-11-22T02:37:17  <CodeShark> or disables something else that makes it unusable as an actual node but can still be used for benchmarking
1012015-11-22T02:38:05  <tulip> anecdotally there's some configurations out there people have copied onto their nodes with no real idea of what they do beyond being "suggested", one of them has gen=1 in it, another has par=1 (which is non-obviously named). things like that seem to get entrenched pretty easily.
1022015-11-22T02:38:59  <gmaxwell> CodeShark: I think people will just bypass those other things. It's a bad route in general.
1032015-11-22T02:40:08  <CodeShark> but a strictly benchmarking mode would mean people would need to recompile to bypass it
1042015-11-22T02:40:42  <CodeShark> and that's already the case anyhow :)
1052015-11-22T02:40:46  <gmaxwell> ya, but thats effectively what we have: you just add a comment in one line.
1062015-11-22T02:41:17  <CodeShark> yes, but a runtime switch that allows benchmarking while making the node useless as a node seems...useful :)
1072015-11-22T02:41:39  <gmaxwell> Though we don't promise that it won't dangerously break things, and in fact it does-- if someone wanted to do that to their mining op to 'make it faster' they'd end up mining soft-fork ops. We already had an issue with that this year, with 1% of the hashrate running of an rpi configured thusly. :(
1082015-11-22T02:42:12  <CodeShark> disable GBT, disable the wallet, disable all relay
1092015-11-22T02:42:27  <gmaxwell> CodeShark: then we'll get another "forced fee disabled fork" promoted by some idiot.
1102015-11-22T02:42:45  <gmaxwell> I really don't think this is that useful. Also if all that stuff is off then it's more you can't benchmark!
1112015-11-22T02:43:34  <tulip> I'd like to break out the script portions of debug=bench.
1122015-11-22T02:43:52  <gmaxwell> if we just want to know the time contribution; then thats addressable via making the timing more granular.
1132015-11-22T02:43:58  <gmaxwell> which we really should do.
1142015-11-22T02:44:01  <tulip> is there any reason debug=bench also dumps the peer timestamp offsets? I thought that would be in debug=net.
1152015-11-22T02:44:13  <gmaxwell> tulip: so go try?
1162015-11-22T02:44:23  <gmaxwell> tulip: no clue, sounds like an error, go look for the commit that did it?
1172015-11-22T02:44:27  <tulip> am.
1182015-11-22T02:44:28  *** Ylbam has quit IRC
1192015-11-22T02:48:09  <tulip> looks like the timezone offset thing gets printed for everybody (not specific to bench), my mistake.
1202015-11-22T02:50:40  <gmaxwell> I /thought/ it did. But trusted the guy with the code open. :)
1212015-11-22T02:51:22  <tulip> I've not run in non-bench mode for so long I've forgotten what log prints are normal.
1222015-11-22T02:52:13  <gmaxwell> I ran without debugging options recently and I was super pleasntly surprised how much we've cut down the chattyness.
1232015-11-22T02:53:22  <tulip> yes, it's a lot easier to glance at a log and get a good idea of what's happening.
1242015-11-22T03:01:10  *** d_t has quit IRC
1252015-11-22T03:03:51  *** JackH has quit IRC
1262015-11-22T03:04:40  *** PaulCapestany has quit IRC
1272015-11-22T03:06:26  *** PaulCapestany has joined #bitcoin-core-dev
1282015-11-22T03:08:53  *** d_t has joined #bitcoin-core-dev
1292015-11-22T03:35:53  *** PaulCape_ has joined #bitcoin-core-dev
1302015-11-22T03:38:38  *** jl2012 has quit IRC
1312015-11-22T03:39:07  *** jl2012 has joined #bitcoin-core-dev
1322015-11-22T03:39:15  *** berndj has quit IRC
1332015-11-22T03:39:47  *** jtimon has quit IRC
1342015-11-22T03:39:49  *** wumpus has quit IRC
1352015-11-22T03:40:18  *** morcos_ has joined #bitcoin-core-dev
1362015-11-22T03:40:27  *** jtimon has joined #bitcoin-core-dev
1372015-11-22T03:42:23  *** sdaftuar_ has joined #bitcoin-core-dev
1382015-11-22T03:44:29  *** berndj has joined #bitcoin-core-dev
1392015-11-22T03:45:02  *** PaulCapestany has quit IRC
1402015-11-22T03:45:03  *** dgenr8 has quit IRC
1412015-11-22T03:45:03  *** challisto has quit IRC
1422015-11-22T03:45:03  *** go1111111 has quit IRC
1432015-11-22T03:45:03  *** morcos has quit IRC
1442015-11-22T03:45:03  *** kanzure has quit IRC
1452015-11-22T03:45:03  *** Apocalyptic has quit IRC
1462015-11-22T03:45:05  *** bsm117532 has quit IRC
1472015-11-22T03:45:05  *** jonasschnelli has quit IRC
1482015-11-22T03:45:09  *** kanzure_ has joined #bitcoin-core-dev
1492015-11-22T03:45:45  *** dgenr8 has joined #bitcoin-core-dev
1502015-11-22T03:45:53  *** sdaftuar has quit IRC
1512015-11-22T03:45:53  *** andytoshi has quit IRC
1522015-11-22T03:45:53  *** Guest1235 has quit IRC
1532015-11-22T03:45:53  *** moli has quit IRC
1542015-11-22T03:45:53  *** jgarzik has quit IRC
1552015-11-22T03:45:53  *** murr4y has quit IRC
1562015-11-22T03:45:53  *** pigeons has quit IRC
1572015-11-22T03:45:54  *** nkuttler has quit IRC
1582015-11-22T03:45:54  *** nanotube has quit IRC
1592015-11-22T03:45:54  *** Anduck has quit IRC
1602015-11-22T03:45:55  *** isis has quit IRC
1612015-11-22T03:45:55  *** petertodd has quit IRC
1622015-11-22T03:45:55  *** crescendo has quit IRC
1632015-11-22T03:46:15  *** Apocalyptic has joined #bitcoin-core-dev
1642015-11-22T03:47:09  *** wumpus has joined #bitcoin-core-dev
1652015-11-22T03:50:43  *** go1111111 has joined #bitcoin-core-dev
1662015-11-22T03:51:58  *** challisto has joined #bitcoin-core-dev
1672015-11-22T03:52:28  *** wangchun has quit IRC
1682015-11-22T03:52:56  *** zxzzt has quit IRC
1692015-11-22T03:52:56  *** warren has quit IRC
1702015-11-22T03:53:20  *** pmienk has quit IRC
1712015-11-22T03:56:01  *** bsm117532 has joined #bitcoin-core-dev
1722015-11-22T03:56:01  *** Guest1234 has joined #bitcoin-core-dev
1732015-11-22T03:56:01  *** nanotube has joined #bitcoin-core-dev
1742015-11-22T03:56:01  *** Anduck has joined #bitcoin-core-dev
1752015-11-22T03:56:01  *** isis has joined #bitcoin-core-dev
1762015-11-22T03:56:01  *** petertodd has joined #bitcoin-core-dev
1772015-11-22T03:56:01  *** crescendo has joined #bitcoin-core-dev
1782015-11-22T03:56:05  *** zxzzt has joined #bitcoin-core-dev
1792015-11-22T03:56:06  *** moli has joined #bitcoin-core-dev
1802015-11-22T03:56:06  *** jgarzik has joined #bitcoin-core-dev
1812015-11-22T03:56:06  *** murr4y has joined #bitcoin-core-dev
1822015-11-22T03:56:06  *** pigeons has joined #bitcoin-core-dev
1832015-11-22T03:56:06  *** nkuttler has joined #bitcoin-core-dev
1842015-11-22T03:56:10  *** andytoshi has joined #bitcoin-core-dev
1852015-11-22T03:58:14  *** warren has joined #bitcoin-core-dev
1862015-11-22T04:07:04  *** pmienk has joined #bitcoin-core-dev
1872015-11-22T04:08:30  *** wangchun has joined #bitcoin-core-dev
1882015-11-22T04:38:16  *** jonasschnelli has joined #bitcoin-core-dev
1892015-11-22T05:19:11  <phantomcircuit> gmaxwell, every time i've gone to fix the trickle logic i end up going down the rabbit hole
1902015-11-22T05:21:41  <gmaxwell> phantomcircuit: when that happens it can be useful to look to see what the smallest possible change that makes it clearly better is.. rather than trying to redesign it.
1912015-11-22T05:24:48  <gmaxwell> like ... non-trickle to a fixed number of peers rather than a fixed proportion.
1922015-11-22T05:30:41  <gmaxwell> (and perhaps favor outbound peers)
1932015-11-22T05:33:15  <phantomcircuit> gmaxwell, there's trickle logic for the local peers address as well
1942015-11-22T05:36:36  <phantomcircuit> gmaxwell, it's really not about the minimal change, im not sure that the original logic really worked either tbh
1952015-11-22T05:41:51  <phantomcircuit> oh and there's a race in the inv stuff
1962015-11-22T05:42:14  <phantomcircuit> you cant just decide to disconnect from peers who give you a transaction w/o inv that you've seen before
1972015-11-22T05:42:53  <gmaxwell> phantomcircuit: whats the race? if you get a transaction and you didn't getdata. They're naughty.
1982015-11-22T05:43:47  <phantomcircuit> gmaxwell, yes but if we dont want to disconnect broken spv clients doing the same thing
1992015-11-22T05:43:50  <phantomcircuit> then there's a race
2002015-11-22T05:44:06  <gmaxwell> sure we can't do it yet.
2012015-11-22T05:45:01  <gmaxwell> I suggest step (1) we ask bitcoinj to change, step (2) we do what matt suggests which is disconnect and don't ban on unsolicited tx when we've already have the tx (usually not the case for SPV)
2022015-11-22T05:45:42  <gmaxwell> (2) will usually not punt spv, but if it does they can just reconnect. And if will reliably hang up on the really dumb nodes.
2032015-11-22T05:46:07  <phantomcircuit> gmaxwell, ok that's reasonable
2042015-11-22T05:47:08  <gmaxwell> and (2) is enough to stop people from making more software that behaves like this.
2052015-11-22T05:48:24  <phantomcircuit> gmaxwell, i actually suggest as the first step to fixing the trickle logic... to delete the trickle logic
2062015-11-22T05:48:50  <gmaxwell> oh come on now, it's not that broken.
2072015-11-22T05:49:02  <phantomcircuit> then mark specific peers as "instant relay" peers
2082015-11-22T05:50:50  <phantomcircuit> gmaxwell, there's two goals with the trickle logic
2092015-11-22T05:50:53  <gmaxwell> phantomcircuit: well if you're going that route, rather-- get rid of the idea of instant relay. And just trigger relay more often on some peers.
2102015-11-22T05:51:09  <phantomcircuit> first is to prevent fingerprinting attacks that allow mapping the network
2112015-11-22T05:51:26  <gmaxwell> and to try to stop duplicate data crossing in flight.
2122015-11-22T05:51:33  <phantomcircuit> second is to prevent fingerprinting attacks on the wallet
2132015-11-22T05:51:39  <gmaxwell> then three goals.
2142015-11-22T05:51:53  <gmaxwell> oh you mean addr trivle vs tx.
2152015-11-22T05:52:14  <phantomcircuit> sort of but not exactly
2162015-11-22T05:52:38  <phantomcircuit> those two should definitely be strongly separated in the code as they have similar but different goals
2172015-11-22T05:53:04  <gmaxwell> the mapping should be fixed by peer rotation resulting in little to no static topology.
2182015-11-22T05:53:09  <phantomcircuit> today if you connect to all the nodes on the network you can get a pretty good idea about who is connected to who based on the timing of transaction inv's
2192015-11-22T05:54:01  <phantomcircuit> none of the peer rotation suggestions have been completely dynamic
2202015-11-22T05:54:04  <gmaxwell> well, little, because we want the robustness to short lived eclipse attacks that comes from long lived connections.
2212015-11-22T05:54:09  <gmaxwell> right
2222015-11-22T05:54:15  <phantomcircuit> they all include some fixed set of nodes to make partitioning harder
2232015-11-22T05:54:28  <phantomcircuit> those links would still be vulnerable to fingerprinting attacks
2242015-11-22T05:56:29  <tulip> I don't think you're going to be able to get rid of the timing aspect unless you remove listening nodes altogether.
2252015-11-22T05:57:44  <gmaxwell> well if you effectively firewallet the results of communication between your long lived links and your short lived ones. I dunno if it can be done without overhead.
2262015-11-22T05:58:42  <gmaxwell> e.g. if you effectively run two p2p stacks, one for the long lived connections one for everyone else.. and don't leak data between them except in hugely delayed batches. yadda yadda.
2272015-11-22T06:01:13  <phantomcircuit> gmaxwell, the last time i did this i ended up basically writing a very shitty mixmaster thing
2282015-11-22T06:01:39  <phantomcircuit> it would hold onto all the transactions it received for 1 minute and then send them all out at once to everybody
2292015-11-22T06:02:03  <phantomcircuit> but wlel all invs cross in flight now
2302015-11-22T06:57:31  <GitHub191> [bitcoin] tulip0 opened pull request #7075: Move time data log print to 'net' category to reduce noise (master...no-time-offset-logging) https://github.com/bitcoin/bitcoin/pull/7075
2312015-11-22T07:03:34  *** tripleslash has quit IRC
2322015-11-22T07:04:40  <gmaxwell> phantomcircuit: they don't all cross in flight.. but a lot do.
2332015-11-22T07:06:08  <phantomcircuit> gmaxwell, assuming most clocks are on ntp and that they're +-1 second
2342015-11-22T07:06:19  <phantomcircuit> then they do mostly cross with that kind of simple mixing
2352015-11-22T07:07:14  *** tripleslash has joined #bitcoin-core-dev
2362015-11-22T07:08:14  <tulip> phantomcircuit: most bitcoin nodes don't seem to have very accurate time.
2372015-11-22T07:08:46  <phantomcircuit> tulip, well... i'd rather not write something that assumes that as it's starting point :P
2382015-11-22T07:15:33  <tulip> -95  -84  -22  -14  -5  -4  -3  -3  -2  -2  -1  -1  -1  +0  +0  +0  +15
2392015-11-22T07:15:59  <tulip> -153  -83  -7  -5  -4  -3  -3  -3  -2  -2  -1  -1  -1  -1  -1  -1  -1  -1  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +0  +1  +1  +2  +4  +4  +7  +9  +13  +13  +31
2402015-11-22T07:20:47  <tulip> there's something beautiful about a decentralised consensus running on hardware with less time accuracy than a sundial.
2412015-11-22T07:41:12  *** tulip has quit IRC
2422015-11-22T08:35:22  *** Guyver2 has joined #bitcoin-core-dev
2432015-11-22T08:40:22  *** Ylbam has joined #bitcoin-core-dev
2442015-11-22T08:50:11  *** tulip has joined #bitcoin-core-dev
2452015-11-22T09:00:22  *** tripleslash has quit IRC
2462015-11-22T09:09:31  *** tripleslash has joined #bitcoin-core-dev
2472015-11-22T09:10:23  *** moli has quit IRC
2482015-11-22T09:14:02  *** tripleslash has quit IRC
2492015-11-22T09:19:48  *** tripleslash has joined #bitcoin-core-dev
2502015-11-22T09:22:32  *** Guyver2 has quit IRC
2512015-11-22T09:24:13  *** tripleslash has quit IRC
2522015-11-22T09:33:43  *** trippysalmon has joined #bitcoin-core-dev
2532015-11-22T09:43:00  *** trippysalmon has quit IRC
2542015-11-22T09:52:04  *** ParadoxSpiral has joined #bitcoin-core-dev
2552015-11-22T09:53:16  *** davec has quit IRC
2562015-11-22T09:54:04  *** davec has joined #bitcoin-core-dev
2572015-11-22T09:57:18  *** tripleslash has joined #bitcoin-core-dev
2582015-11-22T10:01:26  *** tripleslash has quit IRC
2592015-11-22T10:01:53  *** tripleslash has joined #bitcoin-core-dev
2602015-11-22T10:10:32  *** MarcoFalke has joined #bitcoin-core-dev
2612015-11-22T10:25:55  *** d_t has quit IRC
2622015-11-22T10:31:26  *** tripleslash has quit IRC
2632015-11-22T10:35:08  *** tripleslash has joined #bitcoin-core-dev
2642015-11-22T11:28:50  <midnightmagic> gmaxwell: http://0bin.net/paste/+xZ53khueVhoT13w#l5HbKrCAajDA6JE1xoOldXZ90NNiQvWlo21vPZ0g4vC  failed again on ppc host.
2652015-11-22T11:29:04  *** JackH has joined #bitcoin-core-dev
2662015-11-22T11:29:11  *** guest234234 has joined #bitcoin-core-dev
2672015-11-22T11:39:42  *** tripleslash has quit IRC
2682015-11-22T11:46:17  *** tripleslash has joined #bitcoin-core-dev
2692015-11-22T11:50:26  *** tripleslash has quit IRC
2702015-11-22T12:18:48  *** moli has joined #bitcoin-core-dev
2712015-11-22T13:00:25  *** MarcoFalke has quit IRC
2722015-11-22T13:20:20  *** tripleslash has joined #bitcoin-core-dev
2732015-11-22T13:24:53  *** tripleslash has quit IRC
2742015-11-22T13:30:00  *** tripleslash has joined #bitcoin-core-dev
2752015-11-22T13:34:17  *** tripleslash has quit IRC
2762015-11-22T14:05:40  *** tulip has quit IRC
2772015-11-22T14:30:00  *** Thireus1 has quit IRC
2782015-11-22T14:31:08  *** Thireus has joined #bitcoin-core-dev
2792015-11-22T14:32:10  *** MarcoFalke has joined #bitcoin-core-dev
2802015-11-22T14:34:53  *** tulip has joined #bitcoin-core-dev
2812015-11-22T14:39:12  *** tripleslash has joined #bitcoin-core-dev
2822015-11-22T14:45:48  *** guest234234 has quit IRC
2832015-11-22T14:50:10  *** belcher has joined #bitcoin-core-dev
2842015-11-22T15:03:54  *** tripleslash has quit IRC
2852015-11-22T15:20:24  *** tulip has quit IRC
2862015-11-22T15:30:14  *** MarcoFalke has quit IRC
2872015-11-22T15:33:42  *** CodeShark has quit IRC
2882015-11-22T15:40:04  *** tripleslash has joined #bitcoin-core-dev
2892015-11-22T15:43:01  *** tripleslash_p has joined #bitcoin-core-dev
2902015-11-22T15:44:48  *** tripleslash has quit IRC
2912015-11-22T15:47:11  *** challisto has quit IRC
2922015-11-22T15:47:27  *** tripleslash_p has quit IRC
2932015-11-22T15:52:47  *** tripleslash has joined #bitcoin-core-dev
2942015-11-22T15:57:28  *** tripleslash has quit IRC
2952015-11-22T16:08:56  *** kanzure_ is now known as kanzure
2962015-11-22T16:11:18  *** MarcoFalke has joined #bitcoin-core-dev
2972015-11-22T16:11:44  <GitHub36> [bitcoin] JSON199216 opened pull request #7076: JSON199216 (master...master) https://github.com/bitcoin/bitcoin/pull/7076
2982015-11-22T16:21:29  *** tripleslash has joined #bitcoin-core-dev
2992015-11-22T16:28:51  <GitHub181> [bitcoin] jonasschnelli closed pull request #7076: JSON199216 (master...master) https://github.com/bitcoin/bitcoin/pull/7076
3002015-11-22T16:30:24  <jgarzik> ?
3012015-11-22T16:36:18  *** tripleslash has quit IRC
3022015-11-22T17:06:01  *** tripleslash has joined #bitcoin-core-dev
3032015-11-22T17:10:56  *** tripleslash has quit IRC
3042015-11-22T17:11:05  *** tripleslash_w has joined #bitcoin-core-dev
3052015-11-22T17:15:30  *** tripleslash_w has quit IRC
3062015-11-22T17:22:42  *** tripleslash has joined #bitcoin-core-dev
3072015-11-22T17:26:46  *** tripleslash has quit IRC
3082015-11-22T17:36:57  *** tripleslash has joined #bitcoin-core-dev
3092015-11-22T17:41:25  *** tripleslash has quit IRC
3102015-11-22T17:45:34  *** moli has quit IRC
3112015-11-22T17:46:51  *** moli has joined #bitcoin-core-dev
3122015-11-22T18:02:53  *** tripleslash has joined #bitcoin-core-dev
3132015-11-22T18:07:37  *** tripleslash_q has joined #bitcoin-core-dev
3142015-11-22T18:07:56  *** tripleslash has quit IRC
3152015-11-22T18:12:11  *** tripleslash_q has quit IRC
3162015-11-22T18:32:29  *** tripleslash has joined #bitcoin-core-dev
3172015-11-22T18:33:12  *** d_t has joined #bitcoin-core-dev
3182015-11-22T18:36:53  *** tripleslash has quit IRC
3192015-11-22T18:53:59  *** ParadoxSpiral has quit IRC
3202015-11-22T19:01:31  *** ParadoxSpiral has joined #bitcoin-core-dev
3212015-11-22T19:11:47  *** tripleslash has joined #bitcoin-core-dev
3222015-11-22T19:16:01  *** tripleslash has quit IRC
3232015-11-22T19:24:06  *** tripleslash has joined #bitcoin-core-dev
3242015-11-22T19:28:26  *** tripleslash has quit IRC
3252015-11-22T19:43:01  *** tripleslash has joined #bitcoin-core-dev
3262015-11-22T20:02:26  *** tripleslash has quit IRC
3272015-11-22T20:03:36  *** Guyver2 has joined #bitcoin-core-dev
3282015-11-22T20:07:17  *** tripleslash has joined #bitcoin-core-dev
3292015-11-22T20:11:26  *** tripleslash has quit IRC
3302015-11-22T20:24:52  *** MarcoFalke has quit IRC
3312015-11-22T20:30:06  *** tripleslash has joined #bitcoin-core-dev
3322015-11-22T20:32:19  *** tripleslash_v has joined #bitcoin-core-dev
3332015-11-22T20:34:19  *** tripleslash has quit IRC
3342015-11-22T20:37:24  *** tripleslash_v has quit IRC
3352015-11-22T20:53:46  <gmaxwell> For blocks only, I think we actually could ban on inv outside of protocol. BitcoinJ doesn't do that AFAICT.
3362015-11-22T20:56:11  <gmaxwell> something called "Bither" does, unfortunately. /me nags
3372015-11-22T20:59:38  <phantomcircuit> gmaxwell, inv outside of protocol is valid for older peers
3382015-11-22T20:59:52  <gmaxwell> phantomcircuit: sure, but it can be protocol version number gated.
3392015-11-22T21:00:12  <phantomcircuit> yes
3402015-11-22T21:00:29  <gmaxwell> the bither thing claims version 70001
3412015-11-22T21:01:57  <gmaxwell> man why do people lie, it doesn't fool anyone.
3422015-11-22T21:03:23  *** tripleslash has joined #bitcoin-core-dev
3432015-11-22T21:04:52  <gmaxwell> e.g. 'Satoshi:0.9.1/: version 70002, blocks=300000,'  doesn't respond to getheaders, and sends a tx out of protocol.
3442015-11-22T21:08:26  *** tripleslash has quit IRC
3452015-11-22T21:08:39  *** tripleslash_o has joined #bitcoin-core-dev
3462015-11-22T21:17:22  *** tripleslash_o has quit IRC
3472015-11-22T21:25:39  *** tripleslash has joined #bitcoin-core-dev
3482015-11-22T21:30:17  <phantomcircuit> gmaxwell, :|
3492015-11-22T21:34:30  *** tripleslash has quit IRC
3502015-11-22T21:45:05  *** tripleslash has joined #bitcoin-core-dev
3512015-11-22T21:52:39  <phantomcircuit> gmaxwell, is there any use for NOT OP_CHECKSIG
3522015-11-22T21:54:06  <gmaxwell> phantomcircuit: No.
3532015-11-22T21:55:19  <phantomcircuit> gmaxwell, thoughts on a soft fork to make OP_CHECKSIG also verify? (and equivalent for OP_CHECKMULTISIG although that's not as easy)
3542015-11-22T21:56:12  <phantomcircuit> actually nvm that doesn't get us very much today
3552015-11-22T21:57:18  <gmaxwell> well CMS breaks batching too. But our ECDSA is not really batchable because we don't know R's signs.
3562015-11-22T21:58:46  *** randy-waterhouse has joined #bitcoin-core-dev
3572015-11-22T22:02:06  <GitHub22> [bitcoin] gmaxwell pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/31de2414c65d...c322652b71b9
3582015-11-22T22:02:07  <GitHub22> bitcoin/master 3587f6a Patick Strateman: Fix relay mechanism for whitelisted peers under blocks only mode....
3592015-11-22T22:02:07  <GitHub22> bitcoin/master d8aaa51 Patick Strateman: Bail early in processing transactions in blocks only mode....
3602015-11-22T22:02:08  <GitHub22> bitcoin/master 08843ed Peter Todd: Add relaytxes status to getpeerinfo
3612015-11-22T22:02:11  <GitHub96> [bitcoin] gmaxwell closed pull request #7046: Net: Improve blocks only mode. (master...2015-11-17-blocksonly) https://github.com/bitcoin/bitcoin/pull/7046
3622015-11-22T22:06:18  <gmaxwell> sipa: #6996 I have a nit related to possible undefined behavior; and am on hold for further review/testing for your response.
3632015-11-22T22:09:26  *** zookolaptop has joined #bitcoin-core-dev
3642015-11-22T22:10:49  <gmaxwell> Hm. I think we should make the wallet rescans run backwards.
3652015-11-22T22:11:08  <gmaxwell> oh darn that would screw up luke's smart order stuff. Actually so does partial rescans.
3662015-11-22T22:11:13  <gmaxwell> actually so does import.
3672015-11-22T22:11:35  <gmaxwell> Luke-Jr: hey the ordering stuff is no longer universal if users import keys.
3682015-11-22T22:14:02  *** Guyver2 has quit IRC
3692015-11-22T22:15:13  *** zookolaptop is now known as zooko
3702015-11-22T22:16:06  *** zooko is now known as zookolaptop
3712015-11-22T22:20:42  *** tripleslash has quit IRC
3722015-11-22T22:22:48  <Luke-Jr> gmaxwell: ?
3732015-11-22T22:24:19  <Luke-Jr> not sure why that would be the case; I don't consider importing used keys to be "supported" usage people should be doing anyway.
3742015-11-22T22:28:48  <gmaxwell> Luke-Jr: e.g. keys a,b   their order in the wallet will depend on which order you imported and rescaned.
3752015-11-22T22:29:17  <gmaxwell> it's probably not an actual problem.
3762015-11-22T22:29:55  *** ParadoxSpiral has quit IRC
3772015-11-22T22:31:01  <Luke-Jr> gmaxwell: that would be the expected behaviour, IMO
3782015-11-22T22:34:02  *** tripleslash has joined #bitcoin-core-dev
3792015-11-22T22:48:19  <GitHub143> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c322652b71b9...9cdd407ca55b
3802015-11-22T22:48:19  <GitHub143> bitcoin/master c800c95 Suhas Daftuar: Remove unmaintained example test script_test.py
3812015-11-22T22:48:20  <GitHub143> bitcoin/master 9cdd407 Gregory Maxwell: Merge pull request #7029...
3822015-11-22T22:48:22  <GitHub35> [bitcoin] gmaxwell closed pull request #7029: Remove unmaintained example test script_test.py (master...script-test-cleanup) https://github.com/bitcoin/bitcoin/pull/7029
3832015-11-22T22:52:04  <GitHub10> [bitcoin] gmaxwell pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9cdd407ca55b...0b0fc179ab87
3842015-11-22T22:52:05  <GitHub10> bitcoin/master cc97574 MarcoFalke: [qa] Split README.md to /qa and /qa/rpc-tests...
3852015-11-22T22:52:05  <GitHub10> bitcoin/master e16ee1c MarcoFalke: [qa] Extend README.md
3862015-11-22T22:52:06  <GitHub10> bitcoin/master 0b0fc17 Gregory Maxwell: Merge pull request #7028...
3872015-11-22T22:52:13  <GitHub145> [bitcoin] gmaxwell closed pull request #7028: [doc] qa: Move README.md and update -help (master...MarcoFalke-2015-qaReadme) https://github.com/bitcoin/bitcoin/pull/7028
3882015-11-22T23:01:02  <GitHub191> [bitcoin] gmaxwell closed pull request #6803: Automatically adjusting Spam Block (master...spamblock) https://github.com/bitcoin/bitcoin/pull/6803
3892015-11-22T23:39:05  *** guest234234 has joined #bitcoin-core-dev
3902015-11-22T23:40:24  *** zookolaptop has quit IRC
3912015-11-22T23:46:51  *** adam3us has joined #bitcoin-core-dev