1 2015-11-22T00:08:33  *** guest234234 has joined #bitcoin-core-dev
  2 2015-11-22T00:14:45  *** guest234234 has quit IRC
  3 2015-11-22T00:26:38  *** ParadoxSpiral has quit IRC
  4 2015-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
  5 2015-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
  6 2015-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.
  7 2015-11-22T00:32:02  <gmaxwell> though I'd prefer to get bitcoinj fixed first; and have that just clean up whatever remains.
  8 2015-11-22T00:32:51  <davec> That is certainly preferred if the new maintainers are willing to change it
  9 2015-11-22T00:34:52  <CodeShark> I think they would given sufficient pressure ;)
 10 2015-11-22T00:35:15  <gmaxwell> We haven't asked the new maintainer yet, I think.
 11 2015-11-22T00:35:38  <gmaxwell> I was thinking of seeing if I could sweet talk bluematt into just sending a patch. :)
 12 2015-11-22T00:38:06  <BlueMatt> i know i know
 13 2015-11-22T00:38:10  <BlueMatt> i told you i would....
 14 2015-11-22T00:38:59  <BlueMatt> oh, this is unrelated to other things
 15 2015-11-22T00:39:07  <BlueMatt> yea, i mean you should be able to ping andreas
 16 2015-11-22T00:39:09  <gmaxwell> yea, actually I'm still waiting on the other thing. :)
 17 2015-11-22T00:39:18  <CodeShark> too late - now you've committed yourself to this as well!
 18 2015-11-22T00:39:37  <CodeShark> slick move, gmaxwell :)
 19 2015-11-22T00:39:54  <BlueMatt> gmaxwell: i think i saw someone else starting to implement that
 20 2015-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.
 21 2015-11-22T00:40:09  <BlueMatt> but i havent looked closely
 22 2015-11-22T00:40:27  <BlueMatt> yea, ok
 23 2015-11-22T00:40:37  <BlueMatt> i mean we should really just disconnect people who relay something we've already seen
 24 2015-11-22T00:40:41  <BlueMatt> dont ban them, but disconnect them
 25 2015-11-22T00:40:51  <BlueMatt> if someone implements this in a broken way, they'll notice a ton of disconnects and stop
 26 2015-11-22T00:41:01  <gmaxwell> Hm, that we already have and didn't request from them? hm. that should actually be okay.
 27 2015-11-22T00:41:05  <BlueMatt> if its a wallet like bitcoinj doing it, the disconnects will almost never happen
 28 2015-11-22T00:41:36  <gmaxwell> (won't actually rescue blocksonly nodes from the noise, but thats fine)
 29 2015-11-22T00:42:05  <BlueMatt> blockonly nodes can also disconnect
 30 2015-11-22T00:42:18  <gmaxwell> I mean they'll never already have.
 31 2015-11-22T00:42:31  *** tulip has joined #bitcoin-core-dev
 32 2015-11-22T00:43:13  <BlueMatt> yes, but they can also disconnect
 33 2015-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)
 34 2015-11-22T00:45:13  <davec> assuming the new tx is relayed to all connected nodes immediately that is
 35 2015-11-22T00:46:00  <CodeShark> race conditions are bad ;)
 36 2015-11-22T00:46:13  <gmaxwell> well getting disconnected is something that happens which you must be able to handle.
 37 2015-11-22T00:46:24  <gmaxwell> still best to get bitcoinj fixed.
 38 2015-11-22T00:46:47  <davec> I'm definitely in favor of getting BitcoinJ fixed and then tightening the protocol
 39 2015-11-22T00:47:09  <davec> I think it should be allowed for whitelisted nodes however
 40 2015-11-22T00:47:42  <davec> if you have a relay node, proxy, etc setup locally, requiring the extra round trip is probably not desirable
 41 2015-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.
 42 2015-11-22T00:48:39  <gmaxwell> though since a peer doesn't know its whitelisted they shouldn't rely on that behavior.
 43 2015-11-22T00:48:51  <gmaxwell> main argument for it I see is enabling very simplistic scripts.
 44 2015-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
 45 2015-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)
 46 2015-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
 47 2015-11-22T00:51:01  <CodeShark> latency isn't really the issue with that, as gmaxwell said - but it simplifies the propagation logic
 48 2015-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
 49 2015-11-22T00:52:57  <davec> agreed
 50 2015-11-22T00:52:57  <CodeShark> and you're not spamming anyone else
 51 2015-11-22T00:53:32  <CodeShark> although perhaps we could have a "strict mode" for testing clients
 52 2015-11-22T00:53:58  <CodeShark> use it for testing, not for production
 53 2015-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.
 54 2015-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.
 55 2015-11-22T00:55:33  <CodeShark> yeah, you're probably right
 56 2015-11-22T00:56:26  <gmaxwell> doing so would allow replacing the inv process with something that actually scales, and so on.
 57 2015-11-22T00:57:46  <davec> while dreaming it would be nice to design it so things like I2P can work too
 58 2015-11-22T01:00:41  <gmaxwell> not just I2P, tor's next HS protocol has larger addresses.
 59 2015-11-22T01:01:11  <gmaxwell> Though those would be not so hard to shoehorn into ye'ole p2p compatbily.
 60 2015-11-22T01:01:52  <davec> yeah I think there was a patch running around for it at some point
 61 2015-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?
 62 2015-11-22T01:07:46  <gmaxwell> I don't think it's particularly desirable.
 63 2015-11-22T01:07:58  <CodeShark> reasons?
 64 2015-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)
 65 2015-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.
 66 2015-11-22T01:09:49  <gmaxwell> This can get efficiency beyond the peers*transactions bound, and has nice anti-DOS properties.
 67 2015-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
 68 2015-11-22T01:11:39  <CodeShark> whereas routing directly to miners (assuming it is practical) might allow direct fee bidding
 69 2015-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.
 70 2015-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.
 71 2015-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.
 72 2015-11-22T01:13:39  <gmaxwell> but as tulip notes, you don't want any mempoolless nodes in your block propagation critical path.
 73 2015-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.
 74 2015-11-22T01:14:49  <gmaxwell> though I consider that largely orthorgonal to general relay changes.
 75 2015-11-22T01:15:50  <gmaxwell> tulip: I'm surprised it's that bad. :( might this be on a VPS with poor IO?
 76 2015-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.
 77 2015-11-22T01:19:01  <CodeShark> and disabling signature validation doesn't significantly reduce the time,  right?
 78 2015-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)
 79 2015-11-22T01:19:56  <tulip> CodeShark: is there a patch around for doing that?
 80 2015-11-22T01:20:25  <CodeShark> it's a one line change in the code, I believe
 81 2015-11-22T01:20:37  <CodeShark> trying to remember which line :)
 82 2015-11-22T01:20:56  <tulip> assuming I can just short circuit the checkpoints line.
 83 2015-11-22T01:21:02  <CodeShark> yeah, I think that's it
 84 2015-11-22T01:21:52  <gmaxwell> yes.
 85 2015-11-22T01:23:49  <tulip> (log snippet from blocksonly dbcache=100 http://pastebin.com/raw.php?i=JGSHbjwW )
 86 2015-11-22T01:26:17  <gmaxwell> if you've got bench on (I guess you do) you can see where the time is going.
 87 2015-11-22T01:26:26  <gmaxwell> The numbers in brackets are cumulative for the whole run.
 88 2015-11-22T01:29:17  <tulip> yep. http://pastebin.com/raw.php?i=QCkcLBNm
 89 2015-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)
 90 2015-11-22T01:30:08  <gmaxwell> wow, all the time in verify. interesting!
 91 2015-11-22T01:34:00  <gmaxwell> hm. I thought we had more resolution in verify. I can't distinguish signature checks from txin lookups. darn.
 92 2015-11-22T01:36:59  <tulip> guess more granularity wouldn't hurt.
 93 2015-11-22T01:37:04  <davec> that said, the idea of set reconciliation is pretty attractive and would save a lot more
 94 2015-11-22T02:04:35  <midnightmagic> ooookay, primary node validates itself just fine.
 95 2015-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
 96 2015-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
 97 2015-11-22T02:35:53  <gmaxwell> CodeShark: hah sorry!
 98 2015-11-22T02:36:44  <CodeShark> ok, what about if disabling script checks also disables relay?
 99 2015-11-22T02:36:47  <CodeShark> :)
100 2015-11-22T02:37:17  <CodeShark> or disables something else that makes it unusable as an actual node but can still be used for benchmarking
101 2015-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.
102 2015-11-22T02:38:59  <gmaxwell> CodeShark: I think people will just bypass those other things. It's a bad route in general.
103 2015-11-22T02:40:08  <CodeShark> but a strictly benchmarking mode would mean people would need to recompile to bypass it
104 2015-11-22T02:40:42  <CodeShark> and that's already the case anyhow :)
105 2015-11-22T02:40:46  <gmaxwell> ya, but thats effectively what we have: you just add a comment in one line.
106 2015-11-22T02:41:17  <CodeShark> yes, but a runtime switch that allows benchmarking while making the node useless as a node seems...useful :)
107 2015-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. :(
108 2015-11-22T02:42:12  <CodeShark> disable GBT, disable the wallet, disable all relay
109 2015-11-22T02:42:27  <gmaxwell> CodeShark: then we'll get another "forced fee disabled fork" promoted by some idiot.
110 2015-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!
111 2015-11-22T02:43:34  <tulip> I'd like to break out the script portions of debug=bench.
112 2015-11-22T02:43:52  <gmaxwell> if we just want to know the time contribution; then thats addressable via making the timing more granular.
113 2015-11-22T02:43:58  <gmaxwell> which we really should do.
114 2015-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.
115 2015-11-22T02:44:13  <gmaxwell> tulip: so go try?
116 2015-11-22T02:44:23  <gmaxwell> tulip: no clue, sounds like an error, go look for the commit that did it?
117 2015-11-22T02:44:27  <tulip> am.
118 2015-11-22T02:44:28  *** Ylbam has quit IRC
119 2015-11-22T02:48:09  <tulip> looks like the timezone offset thing gets printed for everybody (not specific to bench), my mistake.
120 2015-11-22T02:50:40  <gmaxwell> I /thought/ it did. But trusted the guy with the code open. :)
121 2015-11-22T02:51:22  <tulip> I've not run in non-bench mode for so long I've forgotten what log prints are normal.
122 2015-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.
123 2015-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.
124 2015-11-22T03:01:10  *** d_t has quit IRC
125 2015-11-22T03:03:51  *** JackH has quit IRC
126 2015-11-22T03:04:40  *** PaulCapestany has quit IRC
127 2015-11-22T03:06:26  *** PaulCapestany has joined #bitcoin-core-dev
128 2015-11-22T03:08:53  *** d_t has joined #bitcoin-core-dev
129 2015-11-22T03:35:53  *** PaulCape_ has joined #bitcoin-core-dev
130 2015-11-22T03:38:38  *** jl2012 has quit IRC
131 2015-11-22T03:39:07  *** jl2012 has joined #bitcoin-core-dev
132 2015-11-22T03:39:15  *** berndj has quit IRC
133 2015-11-22T03:39:47  *** jtimon has quit IRC
134 2015-11-22T03:39:49  *** wumpus has quit IRC
135 2015-11-22T03:40:18  *** morcos_ has joined #bitcoin-core-dev
136 2015-11-22T03:40:27  *** jtimon has joined #bitcoin-core-dev
137 2015-11-22T03:42:23  *** sdaftuar_ has joined #bitcoin-core-dev
138 2015-11-22T03:44:29  *** berndj has joined #bitcoin-core-dev
139 2015-11-22T03:45:02  *** PaulCapestany has quit IRC
140 2015-11-22T03:45:03  *** dgenr8 has quit IRC
141 2015-11-22T03:45:03  *** challisto has quit IRC
142 2015-11-22T03:45:03  *** go1111111 has quit IRC
143 2015-11-22T03:45:03  *** morcos has quit IRC
144 2015-11-22T03:45:03  *** kanzure has quit IRC
145 2015-11-22T03:45:03  *** Apocalyptic has quit IRC
146 2015-11-22T03:45:05  *** bsm117532 has quit IRC
147 2015-11-22T03:45:05  *** jonasschnelli has quit IRC
148 2015-11-22T03:45:09  *** kanzure_ has joined #bitcoin-core-dev
149 2015-11-22T03:45:45  *** dgenr8 has joined #bitcoin-core-dev
150 2015-11-22T03:45:53  *** sdaftuar has quit IRC
151 2015-11-22T03:45:53  *** andytoshi has quit IRC
152 2015-11-22T03:45:53  *** Guest1235 has quit IRC
153 2015-11-22T03:45:53  *** moli has quit IRC
154 2015-11-22T03:45:53  *** jgarzik has quit IRC
155 2015-11-22T03:45:53  *** murr4y has quit IRC
156 2015-11-22T03:45:53  *** pigeons has quit IRC
157 2015-11-22T03:45:54  *** nkuttler has quit IRC
158 2015-11-22T03:45:54  *** nanotube has quit IRC
159 2015-11-22T03:45:54  *** Anduck has quit IRC
160 2015-11-22T03:45:55  *** isis has quit IRC
161 2015-11-22T03:45:55  *** petertodd has quit IRC
162 2015-11-22T03:45:55  *** crescendo has quit IRC
163 2015-11-22T03:46:15  *** Apocalyptic has joined #bitcoin-core-dev
164 2015-11-22T03:47:09  *** wumpus has joined #bitcoin-core-dev
165 2015-11-22T03:50:43  *** go1111111 has joined #bitcoin-core-dev
166 2015-11-22T03:51:58  *** challisto has joined #bitcoin-core-dev
167 2015-11-22T03:52:28  *** wangchun has quit IRC
168 2015-11-22T03:52:56  *** zxzzt has quit IRC
169 2015-11-22T03:52:56  *** warren has quit IRC
170 2015-11-22T03:53:20  *** pmienk has quit IRC
171 2015-11-22T03:56:01  *** bsm117532 has joined #bitcoin-core-dev
172 2015-11-22T03:56:01  *** Guest1234 has joined #bitcoin-core-dev
173 2015-11-22T03:56:01  *** nanotube has joined #bitcoin-core-dev
174 2015-11-22T03:56:01  *** Anduck has joined #bitcoin-core-dev
175 2015-11-22T03:56:01  *** isis has joined #bitcoin-core-dev
176 2015-11-22T03:56:01  *** petertodd has joined #bitcoin-core-dev
177 2015-11-22T03:56:01  *** crescendo has joined #bitcoin-core-dev
178 2015-11-22T03:56:05  *** zxzzt has joined #bitcoin-core-dev
179 2015-11-22T03:56:06  *** moli has joined #bitcoin-core-dev
180 2015-11-22T03:56:06  *** jgarzik has joined #bitcoin-core-dev
181 2015-11-22T03:56:06  *** murr4y has joined #bitcoin-core-dev
182 2015-11-22T03:56:06  *** pigeons has joined #bitcoin-core-dev
183 2015-11-22T03:56:06  *** nkuttler has joined #bitcoin-core-dev
184 2015-11-22T03:56:10  *** andytoshi has joined #bitcoin-core-dev
185 2015-11-22T03:58:14  *** warren has joined #bitcoin-core-dev
186 2015-11-22T04:07:04  *** pmienk has joined #bitcoin-core-dev
187 2015-11-22T04:08:30  *** wangchun has joined #bitcoin-core-dev
188 2015-11-22T04:38:16  *** jonasschnelli has joined #bitcoin-core-dev
189 2015-11-22T05:19:11  <phantomcircuit> gmaxwell, every time i've gone to fix the trickle logic i end up going down the rabbit hole
190 2015-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.
191 2015-11-22T05:24:48  <gmaxwell> like ... non-trickle to a fixed number of peers rather than a fixed proportion.
192 2015-11-22T05:30:41  <gmaxwell> (and perhaps favor outbound peers)
193 2015-11-22T05:33:15  <phantomcircuit> gmaxwell, there's trickle logic for the local peers address as well
194 2015-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
195 2015-11-22T05:41:51  <phantomcircuit> oh and there's a race in the inv stuff
196 2015-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
197 2015-11-22T05:42:53  <gmaxwell> phantomcircuit: whats the race? if you get a transaction and you didn't getdata. They're naughty.
198 2015-11-22T05:43:47  <phantomcircuit> gmaxwell, yes but if we dont want to disconnect broken spv clients doing the same thing
199 2015-11-22T05:43:50  <phantomcircuit> then there's a race
200 2015-11-22T05:44:06  <gmaxwell> sure we can't do it yet.
201 2015-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)
202 2015-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.
203 2015-11-22T05:46:07  <phantomcircuit> gmaxwell, ok that's reasonable
204 2015-11-22T05:47:08  <gmaxwell> and (2) is enough to stop people from making more software that behaves like this.
205 2015-11-22T05:48:24  <phantomcircuit> gmaxwell, i actually suggest as the first step to fixing the trickle logic... to delete the trickle logic
206 2015-11-22T05:48:50  <gmaxwell> oh come on now, it's not that broken.
207 2015-11-22T05:49:02  <phantomcircuit> then mark specific peers as "instant relay" peers
208 2015-11-22T05:50:50  <phantomcircuit> gmaxwell, there's two goals with the trickle logic
209 2015-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.
210 2015-11-22T05:51:09  <phantomcircuit> first is to prevent fingerprinting attacks that allow mapping the network
211 2015-11-22T05:51:26  <gmaxwell> and to try to stop duplicate data crossing in flight.
212 2015-11-22T05:51:33  <phantomcircuit> second is to prevent fingerprinting attacks on the wallet
213 2015-11-22T05:51:39  <gmaxwell> then three goals.
214 2015-11-22T05:51:53  <gmaxwell> oh you mean addr trivle vs tx.
215 2015-11-22T05:52:14  <phantomcircuit> sort of but not exactly
216 2015-11-22T05:52:38  <phantomcircuit> those two should definitely be strongly separated in the code as they have similar but different goals
217 2015-11-22T05:53:04  <gmaxwell> the mapping should be fixed by peer rotation resulting in little to no static topology.
218 2015-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
219 2015-11-22T05:54:01  <phantomcircuit> none of the peer rotation suggestions have been completely dynamic
220 2015-11-22T05:54:04  <gmaxwell> well, little, because we want the robustness to short lived eclipse attacks that comes from long lived connections.
221 2015-11-22T05:54:09  <gmaxwell> right
222 2015-11-22T05:54:15  <phantomcircuit> they all include some fixed set of nodes to make partitioning harder
223 2015-11-22T05:54:28  <phantomcircuit> those links would still be vulnerable to fingerprinting attacks
224 2015-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.
225 2015-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.
226 2015-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.
227 2015-11-22T06:01:13  <phantomcircuit> gmaxwell, the last time i did this i ended up basically writing a very shitty mixmaster thing
228 2015-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
229 2015-11-22T06:02:03  <phantomcircuit> but wlel all invs cross in flight now
230 2015-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
231 2015-11-22T07:03:34  *** tripleslash has quit IRC
232 2015-11-22T07:04:40  <gmaxwell> phantomcircuit: they don't all cross in flight.. but a lot do.
233 2015-11-22T07:06:08  <phantomcircuit> gmaxwell, assuming most clocks are on ntp and that they're +-1 second
234 2015-11-22T07:06:19  <phantomcircuit> then they do mostly cross with that kind of simple mixing
235 2015-11-22T07:07:14  *** tripleslash has joined #bitcoin-core-dev
236 2015-11-22T07:08:14  <tulip> phantomcircuit: most bitcoin nodes don't seem to have very accurate time.
237 2015-11-22T07:08:46  <phantomcircuit> tulip, well... i'd rather not write something that assumes that as it's starting point :P
238 2015-11-22T07:15:33  <tulip> -95  -84  -22  -14  -5  -4  -3  -3  -2  -2  -1  -1  -1  +0  +0  +0  +15
239 2015-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
240 2015-11-22T07:20:47  <tulip> there's something beautiful about a decentralised consensus running on hardware with less time accuracy than a sundial.
241 2015-11-22T07:41:12  *** tulip has quit IRC
242 2015-11-22T08:35:22  *** Guyver2 has joined #bitcoin-core-dev
243 2015-11-22T08:40:22  *** Ylbam has joined #bitcoin-core-dev
244 2015-11-22T08:50:11  *** tulip has joined #bitcoin-core-dev
245 2015-11-22T09:00:22  *** tripleslash has quit IRC
246 2015-11-22T09:09:31  *** tripleslash has joined #bitcoin-core-dev
247 2015-11-22T09:10:23  *** moli has quit IRC
248 2015-11-22T09:14:02  *** tripleslash has quit IRC
249 2015-11-22T09:19:48  *** tripleslash has joined #bitcoin-core-dev
250 2015-11-22T09:22:32  *** Guyver2 has quit IRC
251 2015-11-22T09:24:13  *** tripleslash has quit IRC
252 2015-11-22T09:33:43  *** trippysalmon has joined #bitcoin-core-dev
253 2015-11-22T09:43:00  *** trippysalmon has quit IRC
254 2015-11-22T09:52:04  *** ParadoxSpiral has joined #bitcoin-core-dev
255 2015-11-22T09:53:16  *** davec has quit IRC
256 2015-11-22T09:54:04  *** davec has joined #bitcoin-core-dev
257 2015-11-22T09:57:18  *** tripleslash has joined #bitcoin-core-dev
258 2015-11-22T10:01:26  *** tripleslash has quit IRC
259 2015-11-22T10:01:53  *** tripleslash has joined #bitcoin-core-dev
260 2015-11-22T10:10:32  *** MarcoFalke has joined #bitcoin-core-dev
261 2015-11-22T10:25:55  *** d_t has quit IRC
262 2015-11-22T10:31:26  *** tripleslash has quit IRC
263 2015-11-22T10:35:08  *** tripleslash has joined #bitcoin-core-dev
264 2015-11-22T11:28:50  <midnightmagic> gmaxwell: http://0bin.net/paste/+xZ53khueVhoT13w#l5HbKrCAajDA6JE1xoOldXZ90NNiQvWlo21vPZ0g4vC  failed again on ppc host.
265 2015-11-22T11:29:04  *** JackH has joined #bitcoin-core-dev
266 2015-11-22T11:29:11  *** guest234234 has joined #bitcoin-core-dev
267 2015-11-22T11:39:42  *** tripleslash has quit IRC
268 2015-11-22T11:46:17  *** tripleslash has joined #bitcoin-core-dev
269 2015-11-22T11:50:26  *** tripleslash has quit IRC
270 2015-11-22T12:18:48  *** moli has joined #bitcoin-core-dev
271 2015-11-22T13:00:25  *** MarcoFalke has quit IRC
272 2015-11-22T13:20:20  *** tripleslash has joined #bitcoin-core-dev
273 2015-11-22T13:24:53  *** tripleslash has quit IRC
274 2015-11-22T13:30:00  *** tripleslash has joined #bitcoin-core-dev
275 2015-11-22T13:34:17  *** tripleslash has quit IRC
276 2015-11-22T14:05:40  *** tulip has quit IRC
277 2015-11-22T14:30:00  *** Thireus1 has quit IRC
278 2015-11-22T14:31:08  *** Thireus has joined #bitcoin-core-dev
279 2015-11-22T14:32:10  *** MarcoFalke has joined #bitcoin-core-dev
280 2015-11-22T14:34:53  *** tulip has joined #bitcoin-core-dev
281 2015-11-22T14:39:12  *** tripleslash has joined #bitcoin-core-dev
282 2015-11-22T14:45:48  *** guest234234 has quit IRC
283 2015-11-22T14:50:10  *** belcher has joined #bitcoin-core-dev
284 2015-11-22T15:03:54  *** tripleslash has quit IRC
285 2015-11-22T15:20:24  *** tulip has quit IRC
286 2015-11-22T15:30:14  *** MarcoFalke has quit IRC
287 2015-11-22T15:33:42  *** CodeShark has quit IRC
288 2015-11-22T15:40:04  *** tripleslash has joined #bitcoin-core-dev
289 2015-11-22T15:43:01  *** tripleslash_p has joined #bitcoin-core-dev
290 2015-11-22T15:44:48  *** tripleslash has quit IRC
291 2015-11-22T15:47:11  *** challisto has quit IRC
292 2015-11-22T15:47:27  *** tripleslash_p has quit IRC
293 2015-11-22T15:52:47  *** tripleslash has joined #bitcoin-core-dev
294 2015-11-22T15:57:28  *** tripleslash has quit IRC
295 2015-11-22T16:08:56  *** kanzure_ is now known as kanzure
296 2015-11-22T16:11:18  *** MarcoFalke has joined #bitcoin-core-dev
297 2015-11-22T16:11:44  <GitHub36> [bitcoin] JSON199216 opened pull request #7076: JSON199216 (master...master) https://github.com/bitcoin/bitcoin/pull/7076
298 2015-11-22T16:21:29  *** tripleslash has joined #bitcoin-core-dev
299 2015-11-22T16:28:51  <GitHub181> [bitcoin] jonasschnelli closed pull request #7076: JSON199216 (master...master) https://github.com/bitcoin/bitcoin/pull/7076
300 2015-11-22T16:30:24  <jgarzik> ?
301 2015-11-22T16:36:18  *** tripleslash has quit IRC
302 2015-11-22T17:06:01  *** tripleslash has joined #bitcoin-core-dev
303 2015-11-22T17:10:56  *** tripleslash has quit IRC
304 2015-11-22T17:11:05  *** tripleslash_w has joined #bitcoin-core-dev
305 2015-11-22T17:15:30  *** tripleslash_w has quit IRC
306 2015-11-22T17:22:42  *** tripleslash has joined #bitcoin-core-dev
307 2015-11-22T17:26:46  *** tripleslash has quit IRC
308 2015-11-22T17:36:57  *** tripleslash has joined #bitcoin-core-dev
309 2015-11-22T17:41:25  *** tripleslash has quit IRC
310 2015-11-22T17:45:34  *** moli has quit IRC
311 2015-11-22T17:46:51  *** moli has joined #bitcoin-core-dev
312 2015-11-22T18:02:53  *** tripleslash has joined #bitcoin-core-dev
313 2015-11-22T18:07:37  *** tripleslash_q has joined #bitcoin-core-dev
314 2015-11-22T18:07:56  *** tripleslash has quit IRC
315 2015-11-22T18:12:11  *** tripleslash_q has quit IRC
316 2015-11-22T18:32:29  *** tripleslash has joined #bitcoin-core-dev
317 2015-11-22T18:33:12  *** d_t has joined #bitcoin-core-dev
318 2015-11-22T18:36:53  *** tripleslash has quit IRC
319 2015-11-22T18:53:59  *** ParadoxSpiral has quit IRC
320 2015-11-22T19:01:31  *** ParadoxSpiral has joined #bitcoin-core-dev
321 2015-11-22T19:11:47  *** tripleslash has joined #bitcoin-core-dev
322 2015-11-22T19:16:01  *** tripleslash has quit IRC
323 2015-11-22T19:24:06  *** tripleslash has joined #bitcoin-core-dev
324 2015-11-22T19:28:26  *** tripleslash has quit IRC
325 2015-11-22T19:43:01  *** tripleslash has joined #bitcoin-core-dev
326 2015-11-22T20:02:26  *** tripleslash has quit IRC
327 2015-11-22T20:03:36  *** Guyver2 has joined #bitcoin-core-dev
328 2015-11-22T20:07:17  *** tripleslash has joined #bitcoin-core-dev
329 2015-11-22T20:11:26  *** tripleslash has quit IRC
330 2015-11-22T20:24:52  *** MarcoFalke has quit IRC
331 2015-11-22T20:30:06  *** tripleslash has joined #bitcoin-core-dev
332 2015-11-22T20:32:19  *** tripleslash_v has joined #bitcoin-core-dev
333 2015-11-22T20:34:19  *** tripleslash has quit IRC
334 2015-11-22T20:37:24  *** tripleslash_v has quit IRC
335 2015-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.
336 2015-11-22T20:56:11  <gmaxwell> something called "Bither" does, unfortunately. /me nags
337 2015-11-22T20:59:38  <phantomcircuit> gmaxwell, inv outside of protocol is valid for older peers
338 2015-11-22T20:59:52  <gmaxwell> phantomcircuit: sure, but it can be protocol version number gated.
339 2015-11-22T21:00:12  <phantomcircuit> yes
340 2015-11-22T21:00:29  <gmaxwell> the bither thing claims version 70001
341 2015-11-22T21:01:57  <gmaxwell> man why do people lie, it doesn't fool anyone.
342 2015-11-22T21:03:23  *** tripleslash has joined #bitcoin-core-dev
343 2015-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.
344 2015-11-22T21:08:26  *** tripleslash has quit IRC
345 2015-11-22T21:08:39  *** tripleslash_o has joined #bitcoin-core-dev
346 2015-11-22T21:17:22  *** tripleslash_o has quit IRC
347 2015-11-22T21:25:39  *** tripleslash has joined #bitcoin-core-dev
348 2015-11-22T21:30:17  <phantomcircuit> gmaxwell, :|
349 2015-11-22T21:34:30  *** tripleslash has quit IRC
350 2015-11-22T21:45:05  *** tripleslash has joined #bitcoin-core-dev
351 2015-11-22T21:52:39  <phantomcircuit> gmaxwell, is there any use for NOT OP_CHECKSIG
352 2015-11-22T21:54:06  <gmaxwell> phantomcircuit: No.
353 2015-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)
354 2015-11-22T21:56:12  <phantomcircuit> actually nvm that doesn't get us very much today
355 2015-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.
356 2015-11-22T21:58:46  *** randy-waterhouse has joined #bitcoin-core-dev
357 2015-11-22T22:02:06  <GitHub22> [bitcoin] gmaxwell pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/31de2414c65d...c322652b71b9
358 2015-11-22T22:02:07  <GitHub22> bitcoin/master 3587f6a Patick Strateman: Fix relay mechanism for whitelisted peers under blocks only mode....
359 2015-11-22T22:02:07  <GitHub22> bitcoin/master d8aaa51 Patick Strateman: Bail early in processing transactions in blocks only mode....
360 2015-11-22T22:02:08  <GitHub22> bitcoin/master 08843ed Peter Todd: Add relaytxes status to getpeerinfo
361 2015-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
362 2015-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.
363 2015-11-22T22:09:26  *** zookolaptop has joined #bitcoin-core-dev
364 2015-11-22T22:10:49  <gmaxwell> Hm. I think we should make the wallet rescans run backwards.
365 2015-11-22T22:11:08  <gmaxwell> oh darn that would screw up luke's smart order stuff. Actually so does partial rescans.
366 2015-11-22T22:11:13  <gmaxwell> actually so does import.
367 2015-11-22T22:11:35  <gmaxwell> Luke-Jr: hey the ordering stuff is no longer universal if users import keys.
368 2015-11-22T22:14:02  *** Guyver2 has quit IRC
369 2015-11-22T22:15:13  *** zookolaptop is now known as zooko
370 2015-11-22T22:16:06  *** zooko is now known as zookolaptop
371 2015-11-22T22:20:42  *** tripleslash has quit IRC
372 2015-11-22T22:22:48  <Luke-Jr> gmaxwell: ?
373 2015-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.
374 2015-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.
375 2015-11-22T22:29:17  <gmaxwell> it's probably not an actual problem.
376 2015-11-22T22:29:55  *** ParadoxSpiral has quit IRC
377 2015-11-22T22:31:01  <Luke-Jr> gmaxwell: that would be the expected behaviour, IMO
378 2015-11-22T22:34:02  *** tripleslash has joined #bitcoin-core-dev
379 2015-11-22T22:48:19  <GitHub143> [bitcoin] gmaxwell pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c322652b71b9...9cdd407ca55b
380 2015-11-22T22:48:19  <GitHub143> bitcoin/master c800c95 Suhas Daftuar: Remove unmaintained example test script_test.py
381 2015-11-22T22:48:20  <GitHub143> bitcoin/master 9cdd407 Gregory Maxwell: Merge pull request #7029...
382 2015-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
383 2015-11-22T22:52:04  <GitHub10> [bitcoin] gmaxwell pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9cdd407ca55b...0b0fc179ab87
384 2015-11-22T22:52:05  <GitHub10> bitcoin/master cc97574 MarcoFalke: [qa] Split README.md to /qa and /qa/rpc-tests...
385 2015-11-22T22:52:05  <GitHub10> bitcoin/master e16ee1c MarcoFalke: [qa] Extend README.md
386 2015-11-22T22:52:06  <GitHub10> bitcoin/master 0b0fc17 Gregory Maxwell: Merge pull request #7028...
387 2015-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
388 2015-11-22T23:01:02  <GitHub191> [bitcoin] gmaxwell closed pull request #6803: Automatically adjusting Spam Block (master...spamblock) https://github.com/bitcoin/bitcoin/pull/6803
389 2015-11-22T23:39:05  *** guest234234 has joined #bitcoin-core-dev
390 2015-11-22T23:40:24  *** zookolaptop has quit IRC
391 2015-11-22T23:46:51  *** adam3us has joined #bitcoin-core-dev