1 2015-12-03 01:25:41 <mrkent> Okay I remember reading something about the attack on the OP_CHECKSIG limit or something (to artificially reduce the effective blocksize limit)
  2 2015-12-03 01:25:53 <mrkent> Anyone have link to that post?
  3 2015-12-03 12:04:40 <tric3838383838> Hi guys. I am from Cubits, and we tried getting listed on bitcoin.org. So far, nobody helped out with reviewing the wallet, so I wanted to ask for help here. We are a Bitcoin platform, going steady for a year now, with web wallet. In addition, we recently added option to buy Bitcoin at 4500 ATMs in Poland, and Jon Matonis is in our board
  4 2015-12-03 12:05:08 <Diablo-D3> tric3838383838: most likely you got ignored because you're doing a web wallet
  5 2015-12-03 12:06:18 <sipa> harding: ^
  6 2015-12-03 12:07:05 <tric3838383838> Yeah, I am aware that it is not a popular choice. On the other hand, others offering similar services got listed in that section. We had no issues for a year now, and we keep user funds in cold storage. I can get CTO to comment if you guys are interested
  7 2015-12-03 12:57:12 <instagibbs> tric3838383838, you may have to ping the thread again. The review process is pretty thourough, but if it's a web wallet the barriers to getting listed will be even higher most likely.
  8 2015-12-03 12:58:07 <instagibbs> the only web wallets listed thus far are cross-platform(and probably deprecating) GreenAddress, and other huge VC-backed names.
  9 2015-12-03 12:58:20 <instagibbs> also, this is probably #bitcoin
 10 2015-12-03 15:26:25 <jl2012> Why Antpool is not upgrading to BIP65? It is the last major pool to upgrade. Any representative of Antpool here?
 11 2015-12-03 16:08:35 <gmaxwell> jl2012: I heard that they were; they just hadn't yet.
 12 2015-12-03 16:14:10 <jl2012> The adoption of BIP65 is amazingly fast, except for Antpool. Hope it'll be the same for the BIP68 etc later. I guess BIP68 etc is one of the tasks in the after-workshop meetup?
 13 2015-12-03 18:40:09 <gijensen> Is there any reason zapwallettxes and rescan can't be RPC calls? Like if I wrote them would it be as simple as it looks?
 14 2015-12-03 18:52:10 <jonasschnelli> gijensen: for rescan there is a RPC proposal (pull request): https://github.com/bitcoin/bitcoin/pull/7061
 15 2015-12-03 18:52:51 <gijensen> jonasschnelli: Thank you
 16 2015-12-03 18:57:25 <jonasschnelli> meeting today or is everyone already in HK?
 17 2015-12-03 18:58:02 <wumpus> dunno, I suppose some people are not yet or not going like us
 18 2015-12-03 18:59:43 <wumpus> we can try
 19 2015-12-03 18:59:47 <wumpus> #meetingstart
 20 2015-12-03 18:59:51 <lightningbot`> Meeting started Thu Dec  3 18:59:51 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 21 2015-12-03 18:59:51 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
 22 2015-12-03 18:59:51 <wumpus> #startmeeting
 23 2015-12-03 19:00:09 <wumpus> anyone topics?
 24 2015-12-03 19:01:26 <jcorgan> bip68-related pull requests?
 25 2015-12-03 19:01:44 <jonasschnelli> bip68 is a evergreen here... :)
 26 2015-12-03 19:02:06 <wumpus> yes from last week we have: CLTV activation, BIP68/112 implementation, RBF
 27 2015-12-03 19:02:25 <wumpus> action item for CLTV activation was: Post reminder about CLTV deployment next week on social media (btcdrak, 19:28:39)
 28 2015-12-03 19:02:52 <btcdrak> wumpus: I did it a couple days ago
 29 2015-12-03 19:03:02 <wumpus> awesome
 30 2015-12-03 19:03:18 <wumpus> ok, BIP68 it is then
 31 2015-12-03 19:03:30 <wumpus> #topic BIP68-related pull requests
 32 2015-12-03 19:03:33 <btcdrak> is morcos here?
 33 2015-12-03 19:03:36 <gmaxwell> I want to talk briefly about eviction and onion support.
 34 2015-12-03 19:03:39 <morcos> yep, justg showed up
 35 2015-12-03 19:03:49 <wumpus> action item from last week was  Merge BIPs PRs #245 and #248
 36 2015-12-03 19:03:57 <btcdrak> wumpus: that was done
 37 2015-12-03 19:04:01 <Diablo-D3> wait, wtf?
 38 2015-12-03 19:04:02 <wumpus> good
 39 2015-12-03 19:04:08 <Diablo-D3> how the hell did we get that many BIPs
 40 2015-12-03 19:04:25 <wumpus> we didn't, those refer to pull requests, not to pull numbers
 41 2015-12-03 19:04:56 <btcdrak> wumpus: there is one small correction https://github.com/bitcoin/bips/pull/252
 42 2015-12-03 19:05:08 <btcdrak> if that could be merged it would be dandy.
 43 2015-12-03 19:05:12 <morcos> so we're not on the verge of merging 6312 immediately anyway correct?
 44 2015-12-03 19:05:24 <Diablo-D3> wumpus: ahh
 45 2015-12-03 19:05:29 <morcos> it needs more tested ACKS ?
 46 2015-12-03 19:05:31 <morcos> or any
 47 2015-12-03 19:05:36 <wumpus> yes
 48 2015-12-03 19:05:39 <btcdrak> morcos: yes
 49 2015-12-03 19:05:42 <morcos> i don't want to be the cause of delaying it
 50 2015-12-03 19:05:44 <Diablo-D3> wumpus: I was going to say, did I sleep for 10 years or what
 51 2015-12-03 19:05:48 <morcos> but i want to throw something out there
 52 2015-12-03 19:05:56 <sipa> present, from airport
 53 2015-12-03 19:05:57 <wumpus> #action there is one small correction https://github.com/bitcoin/bips/pull/252
 54 2015-12-03 19:06:21 <morcos> i'm trying to figure out how to cache and efficiently check BIP68 validity
 55 2015-12-03 19:06:22 <btcdrak> morcos: although to be fair, I think we're much closer now. Are we going to leave the CNB optimisations till post merge of #6312?
 56 2015-12-03 19:06:37 <wumpus> ok, next topic I guess
 57 2015-12-03 19:06:40 <morcos> we'd realized before this is necessary for reorgs, but more importantly its necessary to make CNB fast
 58 2015-12-03 19:06:58 <morcos> (sorry i guess i intepreted BIP68 related pulls differently :) )
 59 2015-12-03 19:07:10 <btcdrak> wumpus: wait a sec
 60 2015-12-03 19:07:14 <morcos> sdaftuar and i are looking at two approaches
 61 2015-12-03 19:07:34 <morcos> 1 will probably not change the existing code in 6312 at all (or barely)
 62 2015-12-03 19:07:49 <morcos> the other will refactor LockTime(..)  signficiantly
 63 2015-12-03 19:08:10 <sipa> i'd rather see the refactor done uofront
 64 2015-12-03 19:08:16 <morcos> I think if we decide the refactored version is better, exactly
 65 2015-12-03 19:08:21 <morcos> thats what i was going to say
 66 2015-12-03 19:08:33 <btcdrak> sipa: +1
 67 2015-12-03 19:08:50 <morcos> ok, so it may be the refactor is not better anyway, but give us a couple of days to try out the two approaches and let people see them
 68 2015-12-03 19:08:50 <sipa> so not significantly different code goes into backports
 69 2015-12-03 19:09:11 <morcos> sipa: yep, thats what we were discussing
 70 2015-12-03 19:09:55 <morcos> ok..  will make sure we ping people when we have something to show then
 71 2015-12-03 19:10:10 <btcdrak> morcos: so let's revisit the topic next meeting.
 72 2015-12-03 19:10:18 <morcos> ack
 73 2015-12-03 19:10:41 <btcdrak> morcos: if you do make a patch ping me and I'll cherry-pick it into to the PR
 74 2015-12-03 19:11:17 <btcdrak> so I guess the action point is look into refactoring for CNB optimisation
 75 2015-12-03 19:11:43 <wumpus> #action  look into refactoring for CNB optimisation
 76 2015-12-03 19:12:01 <morcos> yeah, but since the code is also for backports that doesn't care about cnb optimisation i think we need to make sure the refactor is reasonable standing on its own as well  (and b/c its consensus code!)
 77 2015-12-03 19:12:13 <btcdrak> morcos: ack
 78 2015-12-03 19:12:27 <sipa> i believe that code that works on master/0.12 will be easier to trivially backport than the other way around
 79 2015-12-03 19:13:26 <morcos> sipa: sure but interesting to think about the data that we'll be getting out of the refactor, these heights and times and so forth, isn't useful in backports
 80 2015-12-03 19:13:56 <sipa> agree
 81 2015-12-03 19:14:16 <morcos> new topic PR 7062?
 82 2015-12-03 19:14:29 <morcos> i know ppl are going to conference now
 83 2015-12-03 19:14:31 <btcdrak> morcos: ack
 84 2015-12-03 19:14:38 <wumpus> gmaxwell proposed a next topic already
 85 2015-12-03 19:14:40 <gmaxwell> I believe we've seen ~no network visbile use or user comments on backports 0.10.x; so I believe we should backport no further than 0.11.x anymore. (and perhaps announce pending end of support on 0.10 on the list to bring anyone out of the woodwork)
 86 2015-12-03 19:14:47 <wumpus> #topic eviction and onions
 87 2015-12-03 19:14:51 <morcos> but sooner we merge that into 0.12, the more test coverage it gets.. (ok sorry, all iw anted to say)
 88 2015-12-03 19:15:14 <btcdrak> gmaxwell: yes
 89 2015-12-03 19:15:32 <gmaxwell> Brief, w/ auto onion support we'll now have a lot of potentially hostile localhost peers, which our eviction code will currently not evict.  #7082 addresses this, but sipa caught me making a locking naughty move.
 90 2015-12-03 19:15:48 <wumpus> we usually keep to one version back, support for 0.10 stops as soon as 0.12 is released
 91 2015-12-03 19:16:11 <wumpus> (excluding super serious bugs and security issues I guess)
 92 2015-12-03 19:16:15 <gmaxwell> I updated to fix it with a kind of gross global lock. But looking around, I see that we frequently update data in node objects with no lock protection. (e.g. pingtimes)
 93 2015-12-03 19:16:52 <btcdrak> wumpus: let's post that to the mailing list so end users are clear about it.
 94 2015-12-03 19:16:59 <btcdrak> wumpus: I was thinking we need a clear EOL statement somewhere
 95 2015-12-03 19:17:10 <gmaxwell> I think its somewhat important to do something about the localhost connections w/ eviction, even in 0.12, to prevent the HS support from bein a liability.
 96 2015-12-03 19:17:21 <sipa> gmaxwell: i know how to fix that
 97 2015-12-03 19:17:37 <wumpus> btcdrak: well it used to be the case that luke-jr was backporting things to older versions, in general other people may still bother
 98 2015-12-03 19:17:51 <gmaxwell> I don't really care what, if I'm getting no comments on that PR because people hate that; lemme know. If someone wants to suggest how to fix the locking mess without the gross global lock I just updated the PR to add, let me know.
 99 2015-12-03 19:18:02 <gmaxwell> sipa: great.
100 2015-12-03 19:18:06 <btcdrak> What PR are we talking about now?
101 2015-12-03 19:18:12 <gmaxwell> 7082
102 2015-12-03 19:18:14 <gmaxwell> Thats all I had for that.
103 2015-12-03 19:18:38 <wumpus> we can still disable the auto HS stuff by default if it's risky
104 2015-12-03 19:19:02 <gmaxwell> I think a very minimal change derisks it, even less than 7082. (7082 without the last commit, basically)
105 2015-12-03 19:19:04 <cfields> gmaxwell: could you describe the issue with nasty localhost peers? I'm not following
106 2015-12-03 19:19:04 <wumpus> the only reason it's enabled by default is because I never got any pushback on that
107 2015-12-03 19:19:59 <gmaxwell> cfields: localhost peers are never evicted; so as soon as you show up on HS someone can prevent anyone else from connecting to you trivially. (just open 125 connections and respond to pings)
108 2015-12-03 19:20:06 <wumpus> #action take a look at #7082
109 2015-12-03 19:20:24 <gmaxwell> thanks.
110 2015-12-03 19:20:47 <jonasschnelli> and there is no other way to distinct between real localhost connections and tor hs localhost connections?
111 2015-12-03 19:20:51 <wumpus> there's already plenty of people that run HS nodes so that is an issue independent of whether auto HS support will be disabled
112 2015-12-03 19:20:59 <wumpus> jonasschnelli: yes, use whitebind
113 2015-12-03 19:21:09 <sipa> jonasschnelli: we could restrict the no-evict behaviour to whitelisted nodes
114 2015-12-03 19:21:18 <sipa> but that may break existing software
115 2015-12-03 19:21:21 <gmaxwell> jonasschnelli: you can whitebind, but that has other effects like force relaying all transactions even redundantly.
116 2015-12-03 19:21:44 <jonasschnelli> why to we special threat localhost in the first place?
117 2015-12-03 19:21:51 <wumpus> jonasschnelli: because of old
118 2015-12-03 19:22:05 <wumpus> if it was decided now, we'd only do it for specially whitelisted nodes
119 2015-12-03 19:22:06 <cfields> gmaxwell: got it now, thanks
120 2015-12-03 19:22:08 <sipa> jonasschnelli: because local software was historically trusted
121 2015-12-03 19:22:17 <sipa> but tor connections aren't really
122 2015-12-03 19:22:22 <gmaxwell> 7082 does not evict whitelisted peers. It removes the special treatment in eviction; and trusts that the fact that eviction does not evict the peers with the 8 lowest ping times, to protect local peers.
123 2015-12-03 19:22:28 <sipa> HS support was only added in 0.6 iirc
124 2015-12-03 19:22:58 <gmaxwell> We still have several other bits of excessive trust of local peers, I think; but this was the most obvious.
125 2015-12-03 19:23:09 <wumpus> in general, P2P connecting software will be able to cope with being disconnected/evicted
126 2015-12-03 19:23:35 <wumpus> gmaxwell: sounds good to me
127 2015-12-03 19:23:52 <gmaxwell> So long has you have less than 8 local peers, and they respond to pings fast just once, they'll still get protected from eviction in 7082.
128 2015-12-03 19:24:06 <wumpus> in the long term we should encourage using whitelisted for special peers
129 2015-12-03 19:24:08 <wumpus> local or not
130 2015-12-03 19:24:14 <sipa> agree
131 2015-12-03 19:24:15 <jonasschnelli> +1!
132 2015-12-03 19:24:24 <jonasschnelli> I think we should take https://github.com/bitcoin/bitcoin/pull/7082/files#diff-9a82240fe7dfe86564178691cc57f2f1L886 in
133 2015-12-03 19:25:14 <wumpus> #action look at  https://github.com/bitcoin/bitcoin/pull/7082/files#diff-9a82240fe7dfe86564178691cc57f2f1L886
134 2015-12-03 19:25:15 <jonasschnelli> i mean remove the if (node->addr.IsLocal()) protection at all
135 2015-12-03 19:25:20 <wumpus> any other topics?
136 2015-12-03 19:25:37 <sipa> topic: 0.12 party
137 2015-12-03 19:25:39 <sipa> :p
138 2015-12-03 19:25:43 <btcdrak> +1
139 2015-12-03 19:25:44 <cfields> i'd like to quickly discuss the HK dev meetup
140 2015-12-03 19:25:45 <wumpus> lol :)
141 2015-12-03 19:25:49 <jonasschnelli> hah!
142 2015-12-03 19:25:59 <wumpus> #topic HK dev meetup
143 2015-12-03 19:26:11 <cfields> everyone who's in hk, come to the dev meetup :)
144 2015-12-03 19:26:13 <cfields> </topic>
145 2015-12-03 19:26:24 <jonasschnelli> ;-)
146 2015-12-03 19:26:28 <cfields> sec, i'll like the mail thread
147 2015-12-03 19:26:36 <wumpus> useful information may be: where, when etc
148 2015-12-03 19:26:57 <sipa> cfields: you'll "like" it, is it on facebook?
149 2015-12-03 19:27:01 <morcos> sorry to be missing it!
150 2015-12-03 19:27:07 <cfields> wumpus: getting there, discussion went faster than i expected. 1 sec :)
151 2015-12-03 19:27:16 <wumpus> twitter has 'likes' now too :')
152 2015-12-03 19:27:22 <cfields> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011712.html
153 2015-12-03 19:27:25 <morcos> we shoudl add on github
154 2015-12-03 19:27:41 <cfields> Dec 8/9, 8am-?
155 2015-12-03 19:27:53 <wumpus> #action all go to HK dev meeting if you're around https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011712.html Dec 8/9, 8am-?
156 2015-12-03 19:27:56 <cfields> same place as the conference. More info at the link above
157 2015-12-03 19:28:22 <cfields> hope everyone can make it. Plan it just to have unstructured dev time.
158 2015-12-03 19:28:55 <btcdrak> with lots of beer
159 2015-12-03 19:29:06 <cfields> If anyone wants to suggest some topics ahead of time, I'm happy to start a list. Otherwise, whatever comes up on its own
160 2015-12-03 19:29:08 <cfields> :(
161 2015-12-03 19:29:09 <sipa> :(
162 2015-12-03 19:29:09 <wumpus> any other topics?
163 2015-12-03 19:29:35 <sdaftuar> topic suggestion: opt-in RBF shoudl have a BIP?
164 2015-12-03 19:29:54 <wumpus> #topic BIP for opt-in RBF
165 2015-12-03 19:29:56 <btcdrak> not really, it is just policy code
166 2015-12-03 19:29:56 <jonasschnelli> definitively!
167 2015-12-03 19:30:12 <sdaftuar> i think it's unfortunate that the only documentation for what wallet writers should do is in a single mailnig list post...
168 2015-12-03 19:30:28 <gmaxwell> Sounds reasonable.
169 2015-12-03 19:30:28 <sipa> standardness has been covered before in BIPs
170 2015-12-03 19:30:28 <wumpus> depends on whether someone is volunteering I suppose
171 2015-12-03 19:30:41 <harding> +1 for a BIP.  I'll write something and coordinate with petertodd
172 2015-12-03 19:30:42 <btcdrak> sdaftaur: I think we should add this FAQ to the release notes https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/
173 2015-12-03 19:30:49 <morcos> its also very intricate policy that is likely to be handled in the exact same way by a high proportion of the network
174 2015-12-03 19:30:49 <sipa> well better communication with wallet authors definitely makes sense
175 2015-12-03 19:30:51 <wumpus> awesome harding
176 2015-12-03 19:30:52 <sdaftuar> awesome, thansk harding
177 2015-12-03 19:31:27 <wumpus> #action harding will coordinate with petertodd about opt-in RBF BIP
178 2015-12-03 19:31:59 <wumpus> next topic?
179 2015-12-03 19:32:20 <sipa> Segmentation faul
180 2015-12-03 19:32:37 <cfields> red flag
181 2015-12-03 19:32:38 <wumpus> #action FAQ useful for BIP: https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/
182 2015-12-03 19:32:47 <gmaxwell> lol
183 2015-12-03 19:33:26 <btcdrak> #link https://www.reddit.com/r/Bitcoin/comments/3urm8o/optin_rbf_is_misunderstood_ask_questions_about_it/
184 2015-12-03 19:34:33 <wumpus> ok, short meeting this time :) have fun in HK everyone that is going
185 2015-12-03 19:35:06 <jonasschnelli> Yes. Have fun. And enjoy the warm weather...
186 2015-12-03 19:35:10 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-03-18.59.log.html
187 2015-12-03 19:35:10 <lightningbot`> Meeting ended Thu Dec  3 19:35:10 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
188 2015-12-03 19:35:10 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-03-18.59.html
189 2015-12-03 19:35:10 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-03-18.59.txt
190 2015-12-03 19:35:10 <wumpus> #endmeeting
191 2015-12-03 19:36:47 <gmaxwell> I didn't want to dive to into it in the meeting; but if people are around;  so I've been observing abusive behavior with the mempool p2p message. There are some nodes connecting to everyone and constantly polling it at high speed.
192 2015-12-03 19:37:26 <gijensen> How can one detect / avoid this?
193 2015-12-03 19:37:30 <wumpus> yes I noticed too...
194 2015-12-03 19:37:47 <gmaxwell> I don't know if their motivation is a upstream bandwdith exhaustion DOS attack, or if they are trying to bypass the batch transmission to determine tx origins, or what. But it sends several megabytes in response right now, on nodes with a big mempool.
195 2015-12-03 19:38:17 <gmaxwell> There are SPV clients that query multiple times, unfortunately (breadwallet for example).
196 2015-12-03 19:38:17 <jonasschnelli> gmaxwell: is the mempool p2p message "in use"? Should we configure that p2p message type and disable it by default?
197 2015-12-03 19:38:39 <gmaxwell> so right now most SPV clients call it on connect to find unconfirmed transactions they were sent before they got online.
198 2015-12-03 19:38:43 <wumpus> jonasschnelli's pull is useful to track bandwidth usage per message
199 2015-12-03 19:39:24 <gmaxwell> The reason some query it multiple times is because they update their bloom filters as they add more keys to their wallets (and for some reason need to deal with time travling people sending them funds...)
200 2015-12-03 19:39:26 <wumpus> gijensen: most straightforward is to disable the message
201 2015-12-03 19:39:32 <jonasschnelli> (https://github.com/bitcoin/bitcoin/pull/6589)
202 2015-12-03 19:39:36 <wumpus> gijensen: you can do that locally, but it's no solution to merge :)
203 2015-12-03 19:39:38 <gmaxwell> jgarzik (who created the message suggested disabling it.
204 2015-12-03 19:39:51 <gmaxwell> )
205 2015-12-03 19:40:03 <gmaxwell> But since it's used I don't think thats a cheap option.
206 2015-12-03 19:40:06 <gijensen> wumpus, jonasschnelli thanks!
207 2015-12-03 19:40:06 <jonasschnelli> disable with a arg to enable?
208 2015-12-03 19:40:24 <gmaxwell> I proposed something complex; but it inspired a nasty rant by hearn.
209 2015-12-03 19:40:54 <instagibbs> was that the PR you posted a few days ago?
210 2015-12-03 19:40:57 <wumpus> gmaxwell: that means you're on the right way *ducks*
211 2015-12-03 19:41:22 <gmaxwell> My proposal is: have it only work with the top 8k feerate sorted transactions; have it use the inv filter to remove dupes; and to only return entries that have been in the mempool for more than a certian amount of time.
212 2015-12-03 19:41:22 <jonasschnelli> or we could add the p2p mempool outbound traffic to the maxuploadtarget rules
213 2015-12-03 19:41:46 <gmaxwell> jonasschnelli: I have a patch that does that, I could PR.
214 2015-12-03 19:41:59 <wumpus> jonasschnelli: that is sensible in any case
215 2015-12-03 19:42:18 <gmaxwell> but it's not really a fix; and if we did the thing I suggested in the PR; I don't think it's needed.
216 2015-12-03 19:42:19 <jonasschnelli> gmaxwell: this would allow to keep the original behavior while reducing it's traffic consumption.
217 2015-12-03 19:42:31 <jonasschnelli> the 8k feerate proposal would slightly change the protocol.
218 2015-12-03 19:42:33 <gmaxwell> (since returning at most 8k entries doesn't use much bandwidth... and the known filtering .. filters.
219 2015-12-03 19:42:49 <wumpus> jonasschnelli: well the other proposed 'fix' is to disable the command completely, gmaxwell's is already a compromise
220 2015-12-03 19:43:22 <gmaxwell> I don't think we should have a p2p message that results in multiple megabytes of transmission with a single request.
221 2015-12-03 19:43:24 <wumpus> I think it's unreasonable to expect nodes to cough up their *entire* mempool
222 2015-12-03 19:43:29 <wumpus> it is privacy sensitive as well
223 2015-12-03 19:43:40 <jonasschnelli> Agree with wumpus
224 2015-12-03 19:43:43 <cfields> agreed
225 2015-12-03 19:43:48 <wumpus> I don't think I was aware of it when the mempool message was introduced, otherwsie I'd probably have pushed back
226 2015-12-03 19:43:51 <jonasschnelli> The SPV wallets will find other ways *duck*
227 2015-12-03 19:44:14 <gmaxwell> There was pushback on the message in fact but it was pretty mild. I think it wouldn't have happened if people realized the privacy problem with it.
228 2015-12-03 19:44:15 <wumpus> gmaxwell: indeed
229 2015-12-03 19:44:52 <jonasschnelli> limit the amount of mempool MB responses by time and node?
230 2015-12-03 19:45:00 <gmaxwell> So in my patch, I picked 8k pretty randomly as "a couple blocks worth", for lack of a better idea.
231 2015-12-03 19:45:10 <cfields> jonasschnelli: that was my thought as well
232 2015-12-03 19:45:11 <wumpus> so if we can somehow neuter the mempool message to be less harmful from a bandwidth and privacy perspective, that sounds good, and is probably more acceptable then deprecating it completely
233 2015-12-03 19:45:29 <wumpus> (as gmaxwell's patch does)
234 2015-12-03 19:45:35 <jonasschnelli> maybe both would be usefull.
235 2015-12-03 19:45:55 <jonasschnelli> If the current abusive behavior is critical, we need a fix without disabling something over an arg or so
236 2015-12-03 19:46:04 <gmaxwell> Yea, I _think_ I achieved that.  I went and talked to breadwallet about their multiple requests (to figure out why they were making them)
237 2015-12-03 19:47:15 <gmaxwell> jonasschnelli: so far, it is only critcial to people running nodes with only a few megabits up... the traffic was pretty much totally knocking out my internet at home.
238 2015-12-03 19:47:26 <jonasschnelli> I read breadwallets source code and just checked it. It seems like they checking if a broadcasted tx was recieved by sending the mempool p2p msg
239 2015-12-03 19:48:05 <jonasschnelli> no.. wait
240 2015-12-03 19:48:08 <gmaxwell> oh interesting; they didn't tell me that when I asked. So much for asking.
241 2015-12-03 19:48:15 <gijensen> Is there not a better way to accomplish that?
242 2015-12-03 19:48:20 <wumpus> is that necessary? we send a reject of a transaction is not accepted right?
243 2015-12-03 19:48:40 <jonasschnelli> no.. i was wrong.
244 2015-12-03 19:48:56 <jonasschnelli> the update the filter, then dispatch the mempool p2p msg
245 2015-12-03 19:48:59 <gmaxwell> in any case they do send more than one.
246 2015-12-03 19:49:35 <gijensen> What did they tell you when you asked?
247 2015-12-03 19:49:38 <gmaxwell> and effectively other SPV clients do-- because they don't stay connected forever, they have short liftimes and always pull.
248 2015-12-03 19:49:40 <wumpus> this again shows that any messages not strictly required for node P2P traffic are DoS liabilities
249 2015-12-03 19:49:51 <gmaxwell> gijensen: what it does; as jonasschnelli corrected; they do it when they update the filter.
250 2015-12-03 19:50:01 <gijensen> Oh okay, thanks
251 2015-12-03 19:50:49 <gmaxwell> in any case, delivery of an unconfirmed transaction isn't guarenteed in the first place.
252 2015-12-03 19:51:59 <jonasschnelli> would it be to harsh to disabled the mempool p2p msg when the maxuploadtraget has been reached?
253 2015-12-03 19:52:08 <wumpus> jonasschnelli: no
254 2015-12-03 19:52:20 <gmaxwell> jonasschnelli: I have a commit to do that.
255 2015-12-03 19:52:29 <jonasschnelli> no response, empty response or a disconnect?
256 2015-12-03 19:52:30 <gmaxwell> I think it's not needed if the amount returned is limited though.
257 2015-12-03 19:52:44 <gmaxwell> I disconnect in mine. but maybe just ignoring would be best.
258 2015-12-03 19:52:44 <wumpus> just don't respond to it
259 2015-12-03 19:53:05 <gmaxwell> okay changing.
260 2015-12-03 19:53:34 <wumpus> disconnecting makes sense if you don't expect anything useful from nodes sending the message after it
261 2015-12-03 19:53:58 <wumpus> full nodes never send it right now so at this point I suppose it makes snese
262 2015-12-03 19:54:23 <jonasschnelli> But how would the SPV wallet react?
263 2015-12-03 19:54:24 <gmaxwell> I wonder if spv clients poll the mempool from all peers, I think they do, I've never seen one _not_ send a mempool request while I was watching.
264 2015-12-03 19:54:36 <jonasschnelli> Would a disconnect not be better,.. so the SPV wallet can go to another node and try?
265 2015-12-03 19:55:04 <wumpus> but what if it's not a SPV wallet? what if you have a (theoretical) full node that sends the message, to collect transactions?
266 2015-12-03 19:55:21 <wumpus> right now the assumption is valid
267 2015-12-03 19:55:40 <wumpus> but there have been ideas to pre-fill the mempool using other nodes mempools
268 2015-12-03 19:55:48 <gmaxwell> I think the only think to ask is it better for the peer to disconnect them.
269 2015-12-03 19:55:51 <wumpus> so the message is not necessarily only for SPVs
270 2015-12-03 19:56:56 <gmaxwell> wumpus: sipa and phantomcircuit both do this during testing. though it takes like ... forever to get the whole thing now. like an hour.
271 2015-12-03 19:57:02 <gmaxwell> (from a node with a big mempool)
272 2015-12-03 19:57:27 <gmaxwell> mempool request sends invs, so you can't even tell which invs were the response to the request.
273 2015-12-03 19:57:27 <wumpus> right, it gets quite confusing to behavior based on assumptions on by whom a message is used
274 2015-12-03 19:57:58 <gmaxwell> I don't think we should ever use this p2p message for mempool syncing. We should have functionality for mempool syncing, but we can add a new message.
275 2015-12-03 19:58:29 <jonasschnelli> But should the SPV response be tiny because of the BF?
276 2015-12-03 19:58:45 <jonasschnelli> shouldn't
277 2015-12-03 19:58:58 <wumpus> yes, but from a DoS perspective that's even worse
278 2015-12-03 19:59:17 <jonasschnelli> fully agreed.
279 2015-12-03 19:59:34 <wumpus> (not from a bandwidth one, agreed)
280 2015-12-03 19:59:47 <jonasschnelli> I see the problem, breadwallet (and probably other), update the filter whenever someone create a new address,.. then get queriy the mempool of n nodes.
281 2015-12-03 20:01:28 <wumpus> gmaxwell: but a new message for mempool syncing will likely have the same issues
282 2015-12-03 20:02:45 <wumpus> (unless it has the same adapted behavior to only return the most important part)
283 2015-12-03 20:02:54 <gmaxwell> wumpus: nah, it would be defined to only work with at most a certian size, defined to give feerate order, defined to respond in a message and not random invs, defined to give data on delay. etc.
284 2015-12-03 20:03:32 <gmaxwell> and potentially use IBLT sync, but I haven't yet been able to measure the performance of set reconcillation on this problem; by rusty's calculations it should work pretty well.
285 2015-12-03 20:03:51 <wumpus> even returning a random selection would be useful I suppose, it can ask multiple nodes to get a more complete picture
286 2015-12-03 20:04:32 <morcos> my 2 cents are i don't find it that useful for testing mempool related pulls.  i'd be happy to see it go.  not sure what about the SPV issues
287 2015-12-03 20:04:42 <jgarzik> damned time zones.
288 2015-12-03 20:04:50 <jgarzik> who invented them and why?
289 2015-12-03 20:04:58 <jonasschnelli> haha
290 2015-12-03 20:05:07 <gmaxwell> jgarzik: set your clocks to utc and avoid that problem... thats what I do.
291 2015-12-03 20:05:08 <wumpus> right, for testing it's better to use RPC commands morcos
292 2015-12-03 20:05:30 <jgarzik> gmaxwell, I do that for all my VPS's... should do for local too :)
293 2015-12-03 20:05:48 <wumpus> good idea gmaxwell
294 2015-12-03 20:07:05 <jonasschnelli> morcos: I guess the SPV issue is: how to get wallet releated tx when you update the filter (after creating a new key).
295 2015-12-03 20:07:28 <wumpus> though I think there is some sense in timezones, DST on the other hand can't wait for it to be consigned to the dustbin of history
296 2015-12-03 20:07:56 <gmaxwell> jonasschnelli: thing is, unless the sender has a time machine or there are multiple copies of the same wallet running; theyre couldn't exist any matching transactions yet.
297 2015-12-03 20:08:34 <jonasschnelli> gmaxwell: heh. Good point. :)
298 2015-12-03 20:08:41 <jonasschnelli> Unless its a bip32 re-creation?
299 2015-12-03 20:08:46 <sipa> jonasschnelli: when you create a new keuly, there cannot be any transaction to it
300 2015-12-03 20:08:47 <wumpus> gmaxwell: I guess when importing a key or so
301 2015-12-03 20:08:48 <wumpus> gmaxwell: I guess when importing a key or so
302 2015-12-03 20:09:03 <gmaxwell> in any case, my PR is fine for that use.
303 2015-12-03 20:09:09 <wumpus> yes
304 2015-12-03 20:09:12 <sipa> yeah, it is useful for importing a key, but that inevitably needs a rescan, not just mempool resync
305 2015-12-03 20:09:42 <gmaxwell> because the response is filtered you can call it often too, to make up for the delay.
306 2015-12-03 20:09:45 <jonasschnelli> right... Breadwallet probably needs to disable the mempool check after updating the filter because of a new generated address
307 2015-12-03 20:09:55 <jonasschnelli> but better threat the node side
308 2015-12-03 20:10:37 <wumpus> yes no matter what they do... the node side still has to mitigate the DoS potential of the message
309 2015-12-03 20:10:57 <cfields> oh, speaking of tor, i noticed something yesterday. wumpus: did you ever notice tor preferring !streamisolation via socks5? On my local machine, given the options for auth/no auth, tor selects no auth (and !streamisolation as a result)
310 2015-12-03 20:11:30 <cfields> docs hint at an option for that behavior, but it's supposed to be disabled by default
311 2015-12-03 20:11:52 <wumpus> cfields: you mean at the tor side or the bitcoin side?
312 2015-12-03 20:12:08 <cfields> wumpus: bitcoin's connection to the proxy
313 2015-12-03 20:13:34 <cfields> wumpus: when connecting to the proxy, you give it a list of acceptable forms of auth. we give it "none or user/pass". It then replies with its preference and you use that mode. My testing shows that it always replies with "none" if you list "none" as an option
314 2015-12-03 20:13:35 <cfields> wumpus: when connecting to the proxy, you give it a list of acceptable forms of auth. we give it "none or user/pass". It then replies with its preference and you use that mode. My testing shows that it always replies with "none" if you list "none" as an option
315 2015-12-03 20:13:35 <wumpus> cfields: I'm quite sure our stream isolation works? TOR offers two authentication options: NONE and PASSWORD, we pick PASSWORD if we can and send a random user/pass
316 2015-12-03 20:14:15 <wumpus> cfields: huh! I tested it extensively when I worked on that pull
317 2015-12-03 20:14:18 <cfields> wumpus: not doubting that it works, only wondering why i see that behavior.
318 2015-12-03 20:14:18 <Luke-Jr> wumpus: I may continue on 0.10 once you're done with it, since that is still my main wallet
319 2015-12-03 20:14:47 <cfields> (and, if we should reject "none" if -streamisolation is on, and disconnect instead)
320 2015-12-03 20:14:48 <cfields> (and, if we should reject "none" if -streamisolation is on, and disconnect instead)
321 2015-12-03 20:15:02 <cfields> wumpus: maybe it's my old tor version?
322 2015-12-03 20:15:03 <cfields> wumpus: maybe it's my old tor version?
323 2015-12-03 20:17:04 <wumpus> cfields: does your tor version support stream isolation?
324 2015-12-03 20:17:22 <cfields> wumpus: yes. if i remove the "none" option and give it only "auth", it requests auth.
325 2015-12-03 20:17:23 <cfields> wumpus: yes. if i remove the "none" option and give it only "auth", it requests auth.
326 2015-12-03 20:18:09 <wumpus> let me try with -debug=proxy ...
327 2015-12-03 20:18:10 <wumpus> let me try with -debug=proxy ...
328 2015-12-03 20:19:23 <wumpus> 2015-12-03 20:19:15 SOCKS5 sending proxy authentication 2952828871:1412341242  works for me
329 2015-12-03 20:19:54 <wumpus> probably your tor version, or an configuration issue at the tor side
330 2015-12-03 20:19:55 <wumpus> probably your tor version, or an configuration issue at the tor side
331 2015-12-03 20:21:02 <cfields> yes, -debug=proxy doesn't show that here. must be local indeed.
332 2015-12-03 20:22:16 <cfields> wumpus: that behavior's deceiving, though. if isolation is requested but not used, i think disconnecting would be the more reasonable expectation?
333 2015-12-03 20:22:42 <wumpus> what you could do is try to switch the methods? put 0x02 first then 0x00
334 2015-12-03 20:22:43 <wumpus> what you could do is try to switch the methods? put 0x02 first then 0x00
335 2015-12-03 20:22:50 <wumpus> cfields: that'll mess with "auto detection" badly
336 2015-12-03 20:22:52 <cfields> same result, had the same thought :)
337 2015-12-03 20:22:53 <cfields> same result, had the same thought :)
338 2015-12-03 20:23:31 <cfields> i'll see if i can track down when the behavior changed
339 2015-12-03 20:23:32 <wumpus> the reason for implementing it this way is that this still works with non-tor proxies
340 2015-12-03 20:23:33 <wumpus> the reason for implementing it this way is that this still works with non-tor proxies
341 2015-12-03 20:23:45 <wumpus> which is the only reason why it could be enabled by default
342 2015-12-03 20:24:12 <wumpus> I guess you could add an explicit proxyrandomize=force option that disconnects if it can't do it
343 2015-12-03 20:24:18 <cfields> wumpus: what if the non-tor proxy accepts auth as well as none? surely a random user/pass would fail in that case
344 2015-12-03 20:24:25 <wumpus> but I'm not so sure that's so useful, right now it's pretty much 'best effort'
345 2015-12-03 20:24:42 <wumpus> cfields: sure, *except* in that case, but remember we don't support auth at all
346 2015-12-03 20:24:51 <wumpus> cfields: there's always -proxyrandomize=0
347 2015-12-03 20:25:16 <wumpus> I'd really prefer to leave it as it
348 2015-12-03 20:25:17 <wumpus> I'd really prefer to leave it as it
349 2015-12-03 20:25:22 <cfields> ok. just trying to weigh expectations vs results.
350 2015-12-03 20:27:32 <wumpus> if you value your privacy don't use a very old tor version, they have more bugs
351 2015-12-03 20:28:59 <wumpus> and as said I'm not against adding a -proxyrandomize=force option, just can't make it default
352 2015-12-03 20:29:57 <cfields> ok
353 2015-12-03 20:29:58 <cfields> ok
354 2015-12-03 20:30:23 <gmaxwell> Is anyone around that knows, cares, anything about the versionbits BIP?  I want to steal a bit.
355 2015-12-03 20:30:41 <morcos> wumpus: Just for the record.  There is a comparison of unsigned ints in GetMinRelayFee that is comparing an underflow now that DEFAULT_BLOCK_PRIORITY_SIZE = 0.  This has the same effect has removing GetMinRelayFee which is what we're going to do anyway.  So nothing to be done.
356 2015-12-03 20:30:42 <morcos> wumpus: Just for the record.  There is a comparison of unsigned ints in GetMinRelayFee that is comparing an underflow now that DEFAULT_BLOCK_PRIORITY_SIZE = 0.  This has the same effect has removing GetMinRelayFee which is what we're going to do anyway.  So nothing to be done.
357 2015-12-03 20:31:07 <morcos> But just wanted to point out that the code was structured in such a way that a change to a DEFAULT caused a buggy comparison
358 2015-12-03 20:32:10 <wumpus> morcos: what is the bug?
359 2015-12-03 20:32:36 <gmaxwell> main.cpp~:        if (nBytes < (DEFAULT_BLOCK_PRIORITY_SIZE - 1000))
360 2015-12-03 20:32:37 <morcos> if (nBytes < (DEFAULT_BLOCK_PRIORITY_SIZE - 1000))
361 2015-12-03 20:33:29 <wumpus> ouch
362 2015-12-03 20:33:53 <gmaxwell> policy/policy.h:static const unsigned int DEFAULT_BLOCK_PRIORITY_SIZE = 0;
363 2015-12-03 20:33:55 <gmaxwell> thats unsigned.
364 2015-12-03 20:33:55 <sdaftuar> yeah we were wondering why the rpc tests didn't all break after the value was set (it looks like that code should stop all free transactions from the mempool)
365 2015-12-03 20:33:56 <gmaxwell> thats unsigned.
366 2015-12-03 20:34:00 <gmaxwell> so it's not undefined.
367 2015-12-03 20:34:24 <morcos> did i misuese the term underflow?
368 2015-12-03 20:34:28 <morcos> misuse
369 2015-12-03 20:34:30 <wumpus> morcos: no
370 2015-12-03 20:34:47 <wumpus> it's an underflow, whether it is defined is just language lawyerism :)
371 2015-12-03 20:34:48 <gmaxwell> Your use is fine, but I was expecting undefined behavior.
372 2015-12-03 20:35:20 <wumpus> if it was undefined the compiler could give a warning
373 2015-12-03 20:36:05 <sipa> indeed, seems unsigned integers are just defined as doing arithmetic modulo 2^32 (apart from division?)
374 2015-12-03 20:36:06 <sipa> indeed, seems unsigned integers are just defined as doing arithmetic modulo 2^32 (apart from division?)
375 2015-12-03 20:36:26 <sdaftuar> funny thing about division that i learned recently...
376 2015-12-03 20:36:48 <sdaftuar> have you looked at what CFeeRate does if you pass in a negative fee?
377 2015-12-03 20:36:49 <sdaftuar> have you looked at what CFeeRate does if you pass in a negative fee?
378 2015-12-03 20:36:53 <morcos> anyway, like i said, no reason to do anything now, the last commit from 7062 removes the function anyway, and that is the same as the current state
379 2015-12-03 20:37:37 <wumpus> what I find strangest about "  if (nBytes < (DEFAULT_BLOCK_PRIORITY_SIZE - 1000))" is that is abuses a default
380 2015-12-03 20:37:55 <wumpus> it's supposed to be default for a parameter, not used to compare against
381 2015-12-03 20:38:11 <morcos> yeah, thats why we just now noticed, this, when sdaftuar said,hmm the change we made to RPC tests wouldn't have actually affected that
382 2015-12-03 20:38:12 <sdaftuar> yes!
383 2015-12-03 20:38:39 <sdaftuar> {
384 2015-12-03 20:38:39 <sdaftuar> CFeeRate::CFeeRate(const CAmount& nFeePaid, size_t nSize)
385 2015-12-03 20:38:39 <sdaftuar> if (nSize > 0)
386 2015-12-03 20:38:39 <sdaftuar> nSatoshisPerK = nFeePaid*1000/nSize;
387 2015-12-03 20:38:50 <wumpus> sipa: division modulo 2^32 would be interesting but probably not what people want :)
388 2015-12-03 20:39:06 <sdaftuar> so on a platform where size_t is 8 bytes, this doesn't work with negative numbers
389 2015-12-03 20:39:22 <sipa> oh wow
390 2015-12-03 20:39:30 <sdaftuar> yeah it's troubling
391 2015-12-03 20:39:31 <sdaftuar> yeah it's troubling
392 2015-12-03 20:40:00 <wumpus> why would you use it with negative numbers?
393 2015-12-03 20:40:10 <morcos> feeDeltas
394 2015-12-03 20:40:10 <sdaftuar> prioritisetransaction
395 2015-12-03 20:40:15 <wumpus> what is the meaning of a negative fee?
396 2015-12-03 20:40:17 <wumpus> oh
397 2015-12-03 20:40:26 <wumpus> probably should regard that as a zero fee though?
398 2015-12-03 20:40:27 <sdaftuar> i was just surprised to learn it didn't work
399 2015-12-03 20:40:43 <sdaftuar> (when i wrote the prioritise_transaction.py test recently, i couldn't figure out why my test was breaking)
400 2015-12-03 20:40:44 <sdaftuar> (when i wrote the prioritise_transaction.py test recently, i couldn't figure out why my test was breaking)
401 2015-12-03 20:41:10 <sdaftuar> i think we could just fix this?
402 2015-12-03 20:41:28 <sdaftuar> i was nervous at first, but it seems like fixing it to be properly negative should be safe (?)
403 2015-12-03 20:41:29 <sdaftuar> i was nervous at first, but it seems like fixing it to be properly negative should be safe (?)
404 2015-12-03 20:41:47 <wumpus> what is the expectation if you feed it a negative number?
405 2015-12-03 20:41:48 <wumpus> what is the expectation if you feed it a negative number?
406 2015-12-03 20:42:24 <morcos> wumpus: Without understanding more about how feeDeltas are used, I think capping it at 0 could have unintended consequences.  People might expect to apply a cost Delta and benefit Delta and them net propertly or something
407 2015-12-03 20:42:25 <sdaftuar> well, i would think that it would be worse (ie to mine) than any 0-fee rate transaction
408 2015-12-03 20:42:39 <sdaftuar> and yes what morcos said...
409 2015-12-03 20:43:07 <wumpus> just be careful that nothing in the code that handles fees probably takes into account that they can be negative
410 2015-12-03 20:43:34 <wumpus> this could be just one exampel
411 2015-12-03 20:43:35 <wumpus> this could be just one exampel
412 2015-12-03 20:43:44 <sdaftuar> the scary thing about this example is that it's platform dependent, i think
413 2015-12-03 20:43:45 <morcos> we actually think it works now, except with the possible exception of some printing issues, since FeeRates aren't actually used for much
414 2015-12-03 20:43:46 <morcos> we actually think it works now, except with the possible exception of some printing issues, since FeeRates aren't actually used for much
415 2015-12-03 20:44:01 <sdaftuar> i haven't tested on 32-bit platforms, but i tried doing the same calculation with an unsigned int rather than a size_t
416 2015-12-03 20:44:10 <sdaftuar> and the calculation results in a negative value
417 2015-12-03 20:44:28 <wumpus> yes it is platform dependent
418 2015-12-03 20:44:29 <wumpus> yes it is platform dependent
419 2015-12-03 20:44:45 <Lightsword> btw I tested CNB with TestBlockValidity patched out and it get’s it down to ~10ms, otherwise it is over 100ms, if that can be put in a background thread and made not to block it looks like the speed increase should be fairly significant
420 2015-12-03 20:45:24 <sdaftuar> so if we think the code is safe on 32-bit platforms, it should be fine to fix on 64-bit platforms.  that is perhaps a big assumption :)
421 2015-12-03 20:45:25 <sdaftuar> so if we think the code is safe on 32-bit platforms, it should be fine to fix on 64-bit platforms.  that is perhaps a big assumption :)
422 2015-12-03 20:45:47 <wumpus> nFeePaid is a signed 64 bit integer, if nSize is a 32 bit unsigned integer then this works fine (it's casted up to 64 bit signed), but if 64 bit unsigned then everything will be done as 64 bit unsigned arithmethic
423 2015-12-03 20:45:48 <wumpus> nFeePaid is a signed 64 bit integer, if nSize is a 32 bit unsigned integer then this works fine (it's casted up to 64 bit signed), but if 64 bit unsigned then everything will be done as 64 bit unsigned arithmethic
424 2015-12-03 20:46:03 <morcos> Lightsword: yay!  I think the background thread can be a future improvement.  The reason I didn't try to do that now is it wasn't clear to me what to do if it fails in the background thread.  although to be fair, its not really clear what to do if it fails when its synchronous
425 2015-12-03 20:46:32 <Lightsword> morcos, it’s a fatal error anyways so it should just terminate I think
426 2015-12-03 20:46:45 <wumpus> sdaftuar: agreed
427 2015-12-03 20:47:39 <Lightsword> morcos, if TestBlockValidity fails and GBT has already returned worst case is a miner is only invalid work for 30 seconds before bitcoind terminates
428 2015-12-03 20:48:31 <wumpus> sdaftuar: ((int64_t)nSize) would already work to fix the arithmetic, of course given that nSize itself fits into that...
429 2015-12-03 20:48:32 <wumpus> sdaftuar: ((int64_t)nSize) would already work to fix the arithmetic, of course given that nSize itself fits into that...
430 2015-12-03 20:48:48 <sdaftuar> wumpus: agreed
431 2015-12-03 20:49:19 <morcos> Lightsword: yeah so its not a hard fix, but i think we'll have to live with the 100ms for 0.12
432 2015-12-03 20:49:25 <morcos> better than it was!
433 2015-12-03 20:50:07 <Lightsword> morcos, hmm, can we just move TestBlockValidity right to right after GBT returns?
434 2015-12-03 20:50:23 <Lightsword> TestBlockValidity to right after*
435 2015-12-03 20:50:57 <Lightsword> that may be simpler than a background thread