1 2016-02-12T00:00:16  *** frankenmint has joined #bitcoin-core-dev
  2 2016-02-12T00:01:10  *** frankenmint has joined #bitcoin-core-dev
  3 2016-02-12T00:05:22  *** frankenmint has quit IRC
  4 2016-02-12T00:13:00  *** adnn has joined #bitcoin-core-dev
  5 2016-02-12T00:23:34  *** jujumax has quit IRC
  6 2016-02-12T00:24:44  *** randy-waterhouse has joined #bitcoin-core-dev
  7 2016-02-12T00:42:43  *** zooko has joined #bitcoin-core-dev
  8 2016-02-12T00:43:15  *** laurentmt has joined #bitcoin-core-dev
  9 2016-02-12T00:43:38  *** laurentmt has quit IRC
 10 2016-02-12T00:45:18  *** PRab has quit IRC
 11 2016-02-12T00:46:11  *** laurentmt has joined #bitcoin-core-dev
 12 2016-02-12T00:52:02  *** bsm117532 has quit IRC
 13 2016-02-12T00:53:00  *** bsm1175321 has joined #bitcoin-core-dev
 14 2016-02-12T00:53:24  *** frankenmint has joined #bitcoin-core-dev
 15 2016-02-12T00:54:29  *** jujumax has joined #bitcoin-core-dev
 16 2016-02-12T00:56:49  *** Sparyx has joined #bitcoin-core-dev
 17 2016-02-12T00:57:33  *** mm_1 has quit IRC
 18 2016-02-12T00:58:06  *** mm_1 has joined #bitcoin-core-dev
 19 2016-02-12T00:59:50  *** ghtdak has quit IRC
 20 2016-02-12T01:03:50  *** frankenmint has quit IRC
 21 2016-02-12T01:05:23  *** ghtdak has joined #bitcoin-core-dev
 22 2016-02-12T01:06:06  *** laurentmt has quit IRC
 23 2016-02-12T01:09:44  *** adnn has quit IRC
 24 2016-02-12T01:11:38  *** adnn has joined #bitcoin-core-dev
 25 2016-02-12T01:14:26  *** frankenmint has joined #bitcoin-core-dev
 26 2016-02-12T01:16:18  *** adnn has quit IRC
 27 2016-02-12T01:18:17  *** frankenmint has quit IRC
 28 2016-02-12T01:28:10  *** jujumax has quit IRC
 29 2016-02-12T01:33:54  *** fkhan has quit IRC
 30 2016-02-12T01:48:16  *** fkhan has joined #bitcoin-core-dev
 31 2016-02-12T01:58:25  *** Ylbam has quit IRC
 32 2016-02-12T02:00:10  *** dermoth has quit IRC
 33 2016-02-12T02:00:53  *** dermoth has joined #bitcoin-core-dev
 34 2016-02-12T02:01:07  *** jujumax has joined #bitcoin-core-dev
 35 2016-02-12T02:02:30  *** Sparyx has quit IRC
 36 2016-02-12T02:15:40  *** Thireus has quit IRC
 37 2016-02-12T02:16:00  *** Thireus has joined #bitcoin-core-dev
 38 2016-02-12T02:18:12  *** justanotheruser has quit IRC
 39 2016-02-12T02:20:55  *** justanotheruser has joined #bitcoin-core-dev
 40 2016-02-12T02:30:15  *** brg444 has quit IRC
 41 2016-02-12T02:41:26  *** bityogi has quit IRC
 42 2016-02-12T02:47:09  *** jtimon has quit IRC
 43 2016-02-12T02:47:14  *** frankenmint has joined #bitcoin-core-dev
 44 2016-02-12T02:56:04  <Luke-Jr> maybe it'd be easier to try to figure out 7521 here? [ gmaxwell morcos ]
 45 2016-02-12T02:56:19  *** Sparyx has joined #bitcoin-core-dev
 46 2016-02-12T02:57:00  <morcos> i'm here
 47 2016-02-12T02:57:18  <sipa> Luke-Jr: with or without 7521, an evicted transaction is not accepted back into the mempool
 48 2016-02-12T02:57:27  <sipa> without it, however, it does get rebroadcast
 49 2016-02-12T02:57:46  <Luke-Jr> ok, but I think that's the expected/desired behaviour
 50 2016-02-12T02:58:10  <Luke-Jr> how is it ever going to get mined if the sender/receiver don't rebroadcast it?
 51 2016-02-12T02:58:31  <morcos> If it got evicted, its not likely to ever get mined
 52 2016-02-12T02:58:31  <sipa> yes, that should be fixed
 53 2016-02-12T02:58:47  <sipa> we should retry to get it into the mempool, and when it does, rebroadcast
 54 2016-02-12T02:58:57  <sipa> but not rebroadcast despite violating your own rules
 55 2016-02-12T02:59:25  <morcos> sipa: so you don't like the fix in 7521?  or you just think we should eventually make a better one?
 56 2016-02-12T02:59:35  <sipa> morcos: i don't think it's enough, but it's an improvement
 57 2016-02-12T02:59:40  <morcos> i think its really unlikely to make it back into your own mempool
 58 2016-02-12T02:59:57  <sipa> morcos: i think mempool pressure goes up and down
 59 2016-02-12T02:59:59  <Luke-Jr> morcos: stuck transactions are never good behaviour
 60 2016-02-12T02:59:59  <morcos> it would be much better to just abandon it and try again with a higher fee
 61 2016-02-12T03:00:12  <Luke-Jr> we don't have wallet RBF support in 0.12..
 62 2016-02-12T03:00:13  *** dermoth has quit IRC
 63 2016-02-12T03:00:19  <morcos> you don't need wallet support
 64 2016-02-12T03:00:31  <Luke-Jr> …
 65 2016-02-12T03:00:45  *** jl2012 has quit IRC
 66 2016-02-12T03:00:51  <Luke-Jr> morcos: what you're proposing there results in transactions that are literally stuck forever and unrecoverable
 67 2016-02-12T03:00:58  *** dermoth has joined #bitcoin-core-dev
 68 2016-02-12T03:01:04  *** jl2012 has joined #bitcoin-core-dev
 69 2016-02-12T03:01:06  <morcos> that is what abandontransaction is for
 70 2016-02-12T03:01:26  <Luke-Jr> abandontransaction is not usable to users
 71 2016-02-12T03:01:39  <Luke-Jr> it shouldn't be encouraged, much less requied
 72 2016-02-12T03:02:06  <morcos> what about the attack i and gmaxwell described above
 73 2016-02-12T03:02:09  * Luke-Jr gets a sense we had that discussion before
 74 2016-02-12T03:02:31  <morcos> you send small very low fee txs to random addresses
 75 2016-02-12T03:03:01  <morcos> for instance if you send 1000 sat/kB txs repeatedly they'll eventually be accepted and then evicted/expired with high probability
 76 2016-02-12T03:03:16  <morcos> then the nodes you sent them to will continually rebroadcast them frequently
 77 2016-02-12T03:03:30  <Luke-Jr> 0.11 would do this too
 78 2016-02-12T03:03:35  <morcos> both contributing to a bandwidth DoS attack and compromising their privacy
 79 2016-02-12T03:03:44  <sipa> Luke-Jr: but with 0.11 you can't be certain
 80 2016-02-12T03:03:53  <Luke-Jr> sipa: ?
 81 2016-02-12T03:04:07  <Luke-Jr> 0.11 never prunes its mempool, so it will always be there
 82 2016-02-12T03:04:12  <sipa> Luke-Jr: with current 0.12, you can send a mempool command, and if the result doesn't contain the transaction, you know it's theirs
 83 2016-02-12T03:04:21  <Luke-Jr> ah
 84 2016-02-12T03:04:56  <Luke-Jr> so what sipa suggested, add to our own before rebroadcasting
 85 2016-02-12T03:05:03  <morcos> i tried that first
 86 2016-02-12T03:05:05  <Luke-Jr> if it fails, don't rebroadcast until it doesn't fail anymore
 87 2016-02-12T03:05:12  <morcos> as i mentioned on the PR
 88 2016-02-12T03:05:18  <Luke-Jr> also, how frequent is wallet rebroadcast? I thought it was some hours
 89 2016-02-12T03:05:38  <Luke-Jr> morcos: the lock shouldn't be a problem, why do you think it is?
 90 2016-02-12T03:05:38  *** jujumax has quit IRC
 91 2016-02-12T03:06:03  <morcos> some time in the next 30 mins
 92 2016-02-12T03:06:07  <morcos> it looks like
 93 2016-02-12T03:06:21  <Luke-Jr> still rare enough to be okay locking I think?
 94 2016-02-12T03:06:42  <Luke-Jr> (on that note, we should probably never rebroadcast to the same connection twice?)
 95 2016-02-12T03:06:45  <sipa> morcos: i wonder if rebroadcast could just call "ProcessMessage" and send a tx message to the node...
 96 2016-02-12T03:06:48  <morcos> well, my first attempt at figuring out how it would lock makes it seem like you would have to lock cs_main while you iterate through every tx in your wallet and then send the ones that need sending
 97 2016-02-12T03:07:20  <morcos> i think you guys are trying to solve for a non-existant problem
 98 2016-02-12T03:07:33  <Luke-Jr> sipa: my local hacks includes abstracting the "tx" message to a function so I can basically simulate that. maybe worth upstreaming for this
 99 2016-02-12T03:07:49  <sipa> morcos: nah, lock cs_wallet, copy the matching ones to a stack-allocated vector, unlock cs_wallet, accepttomemorypool
100 2016-02-12T03:08:14  <morcos> if you have a very small mempool, then maybe you are right..  but at the size peoples mempools are now... if you get evicted/exprired...  you really have no business being rebroadcast
101 2016-02-12T03:08:29  <Luke-Jr> morcos: it's not a problem because we don't have the bug you'd be introducing yet! :P
102 2016-02-12T03:08:38  <morcos> i'd be introducting?
103 2016-02-12T03:08:59  <Luke-Jr> morcos: right now, transactions never get stuck due to failure to rebroadcast
104 2016-02-12T03:09:07  *** PRab has joined #bitcoin-core-dev
105 2016-02-12T03:09:38  <morcos> sipa: yeah ok, i mean i agree its solvable.  but i just think its silly to solve
106 2016-02-12T03:09:58  <morcos> i think you're trying to reaccept and rebroadcast garbage basically
107 2016-02-12T03:10:04  <Luke-Jr> morcos: as soon as the fee rate goes up, you'd have a permanently stuck transaction
108 2016-02-12T03:10:17  <Luke-Jr> and nothing the user could do to fix it
109 2016-02-12T03:10:30  <sipa> morcos: there will always be transactions that are close to acceptable, and random variations push them below and above
110 2016-02-12T03:11:09  <morcos> sipa: i think we made mempools big enough that the bottom of the mempool basically never gets confirmed
111 2016-02-12T03:12:40  <morcos> i mean if we changed the rebroadcast interval to be once a week instead of once every 30 mins, then maybe it would make sense?  but do people really want txs that might get confirmed in a week or two
112 2016-02-12T03:12:51  <Luke-Jr> morcos: if the mempool is filled with spam, it could be that ONLY the bottom gets confirmed ;)
113 2016-02-12T03:12:56  <morcos> it seems like its just a cleaner UI to be be like, sorry, that tx probably didnt make it
114 2016-02-12T03:13:17  <morcos> anywya, i certainly don't object to attempting to stick it in the mempool first
115 2016-02-12T03:13:21  <Luke-Jr> morcos: it's only an attempt every 30 mins. if it fails for a week, it will take a week..
116 2016-02-12T03:13:24  <morcos> i just think its a bigger change for no good reason
117 2016-02-12T03:13:33  <morcos> so i'll let someone else make that change
118 2016-02-12T03:13:39  <Luke-Jr> sorry, that tx probably didnt make it <-- we cannot say this until there is a recourse
119 2016-02-12T03:13:43  <aj> Luke-Jr: how would that work? bottom of the mempool = high priority, so the middle (low fee, low pri) is never confirmed? or?
120 2016-02-12T03:14:05  <morcos> personally i think we should turn off all wallet rebroadcast by default
121 2016-02-12T03:14:07  <Luke-Jr> aj: middle/top gets ignored by miners with better spam filters
122 2016-02-12T03:14:09  <morcos> i doubt it does any good
123 2016-02-12T03:14:21  <Luke-Jr> morcos: …
124 2016-02-12T03:14:25  <aj> Luke-Jr: how do you filter spam by anything other than fee/priority?
125 2016-02-12T03:14:37  <morcos> once you have propagated your tx, its either going to get mined or not
126 2016-02-12T03:14:40  <Luke-Jr> aj: some spammers use repeated patterns, for example
127 2016-02-12T03:14:56  <morcos> trying again (especially frequently) is not a worthwhile effort
128 2016-02-12T03:14:57  <aj> Luke-Jr: is there a blog post or something about that anywhere?
129 2016-02-12T03:15:02  <Luke-Jr> aj: no
130 2016-02-12T03:15:11  <aj> Luke-Jr: *arrgghhh*
131 2016-02-12T03:15:11  <Luke-Jr> or maybe there is, but I wouldn't know because I don't spend time on blogs
132 2016-02-12T03:15:48  <aj> Luke-Jr: s/or something/or an email thread, or a reddit post, or a paper, or.../
133 2016-02-12T03:15:50  <Luke-Jr> morcos: right now, it is an assumption that wallets must rebroadcast if they want transactions to get mined
134 2016-02-12T03:16:00  <Luke-Jr> morcos: any wallet that fails to do so is considered broken
135 2016-02-12T03:16:25  <sipa> morcos: due to non-uniform policies across nodes on the network, i think rebroadcasting actually helps confirmation
136 2016-02-12T03:16:38  <sipa> though that isn't relevant here; we still rebroadcast, just not after eviction
137 2016-02-12T03:16:49  <aj> Luke-Jr: or a github repo with code that discriminates between spam txes?
138 2016-02-12T03:17:01  <Luke-Jr> aj: I have a spamfilter branch that isn't entirely up to date.
139 2016-02-12T03:17:08  <sipa> Luke-Jr: do you use it?
140 2016-02-12T03:17:19  <Luke-Jr> sipa: spamfilter? of course
141 2016-02-12T03:17:31  <Luke-Jr> (merged into a current branch)
142 2016-02-12T03:17:50  <aj> Luke-Jr: !!!
143 2016-02-12T03:18:29  <Luke-Jr> obsolete is better than nothing at all still ;)
144 2016-02-12T03:21:33  <morcos> well like i said, i'm not opposed to trying to reaccept first and then relaying.  i just didn't personally think it was worth it.
145 2016-02-12T03:24:30  <Luke-Jr> ok, so is someone working on this, or should I be?
146 2016-02-12T03:25:36  <sipa> i'm having a look
147 2016-02-12T04:12:59  *** adnn has joined #bitcoin-core-dev
148 2016-02-12T04:14:17  *** Sparyx has quit IRC
149 2016-02-12T04:17:06  *** adnn has quit IRC
150 2016-02-12T04:29:17  <Luke-Jr> wumpus: I collected a bunch of bugfixes in master missing in 0.12 - I assume I should let them all wait for 0.12.1?
151 2016-02-12T04:30:16  <Luke-Jr> mostly typos, the only ones I'd really consider are:
152 2016-02-12T04:30:21  <Luke-Jr> * e54f412 peers.dat, banlist.dat recreated when missing
153 2016-02-12T04:30:22  <Luke-Jr> * 54608c1 GUI: Disable tab navigation for peers tables.
154 2016-02-12T04:38:30  *** zooko has quit IRC
155 2016-02-12T05:05:25  *** Sparyx has joined #bitcoin-core-dev
156 2016-02-12T05:06:43  *** adnn has joined #bitcoin-core-dev
157 2016-02-12T05:09:42  *** lightningbot has joined #bitcoin-core-dev
158 2016-02-12T05:09:44  *** jl2012 has quit IRC
159 2016-02-12T05:10:11  *** Arnavion has quit IRC
160 2016-02-12T05:10:16  *** Arnavion3 has joined #bitcoin-core-dev
161 2016-02-12T05:10:20  *** Arnavion3 is now known as Arnavion
162 2016-02-12T05:11:27  *** Cory has quit IRC
163 2016-02-12T05:12:54  *** Pasha has joined #bitcoin-core-dev
164 2016-02-12T05:19:47  *** Pasha is now known as Cory
165 2016-02-12T05:25:09  *** jl2012 has joined #bitcoin-core-dev
166 2016-02-12T05:42:01  <GitHub22> [bitcoin] luke-jr opened pull request #7522: Bugfix: Only use git for build info if the repository is actually the right one (master...bugfix_gitdir) https://github.com/bitcoin/bitcoin/pull/7522
167 2016-02-12T05:42:44  <paveljanik> Luke-Jr, I understand your attitude to it - the same applies to me :-) But during years I've got some decent knowledge of it and your notation - i.e. ]AC_...[ - with reversed parens got me 8)
168 2016-02-12T05:43:27  <Luke-Jr> paveljanik: it's de-quoting so it's substituted
169 2016-02-12T05:43:37  <paveljanik> I was even analysing our bitcoin_qt.m4 yesterday for missing quotes etc...
170 2016-02-12T05:44:12  <Luke-Jr> [] are usually called brackets in English FWIW; () are parens ;)
171 2016-02-12T05:45:36  <paveljanik> in Czech, they are round (kulaté) vs. rectangle [hranaté] parens (závorky) ;-)
172 2016-02-12T05:46:29  <Luke-Jr> interesting
173 2016-02-12T05:46:39  <Luke-Jr> {} are sometimes "curly brackets", but usually just "braces"
174 2016-02-12T05:48:53  <Luke-Jr> paveljanik: can I convince you to in 20160211_LibreSSL_compile_fix do: git rebase HEAD^ --onto 3cd836c1d
175 2016-02-12T05:49:11  <paveljanik> {složené} závorky
176 2016-02-12T05:49:19  <paveljanik> Luke-Jr, sure
177 2016-02-12T05:49:33  <Luke-Jr> what does složené mean?
178 2016-02-12T05:50:28  <paveljanik> {} are slozene zavorky, where slozene means composed
179 2016-02-12T05:50:33  <Luke-Jr> i c
180 2016-02-12T05:52:00  <paveljanik> Luke-Jr, done
181 2016-02-12T05:52:20  <Luke-Jr> paveljanik: thanks. that will merge cleanly to 0.12 and master both
182 2016-02-12T05:52:51  <Luke-Jr> someone with repo push access: care to copy tags from my fork? branch-0.{9..12}
183 2016-02-12T05:55:58  <Luke-Jr> (these are the last-common-commit for the branch and master)
184 2016-02-12T05:59:21  <Luke-Jr> paveljanik: oh, your new LogPrintf is missing a space
185 2016-02-12T05:59:40  <Luke-Jr> quick, before anyone else notices! :P
186 2016-02-12T06:02:02  <paveljanik> :-))
187 2016-02-12T06:04:13  <paveljanik> force pushed
188 2016-02-12T06:10:57  <Luke-Jr> thanks, utACK'd
189 2016-02-12T06:16:29  *** Sparyx has quit IRC
190 2016-02-12T06:22:27  <paveljanik> m4/autoconf is almost the same nightmare as sendmail's cf was.
191 2016-02-12T06:40:36  <Luke-Jr> paveljanik: and somehow every attempt to replace it has been a disaster
192 2016-02-12T06:56:25  <paveljanik> so called vendor-lock in ;-)
193 2016-02-12T07:09:29  *** Sparyx has joined #bitcoin-core-dev
194 2016-02-12T07:11:37  *** frankenmint has quit IRC
195 2016-02-12T07:30:25  *** frankenmint has joined #bitcoin-core-dev
196 2016-02-12T07:48:09  *** BashCo has quit IRC
197 2016-02-12T07:57:26  *** Sparyx has quit IRC
198 2016-02-12T08:00:44  *** paveljanik has quit IRC
199 2016-02-12T08:04:57  *** Ylbam has joined #bitcoin-core-dev
200 2016-02-12T08:09:03  *** BashCo has joined #bitcoin-core-dev
201 2016-02-12T08:14:53  *** Sparyx has joined #bitcoin-core-dev
202 2016-02-12T08:22:17  *** frankenmint has quit IRC
203 2016-02-12T08:24:33  *** davec has quit IRC
204 2016-02-12T08:30:03  *** zesi has joined #bitcoin-core-dev
205 2016-02-12T08:30:08  *** davec has joined #bitcoin-core-dev
206 2016-02-12T08:40:27  *** JackH has joined #bitcoin-core-dev
207 2016-02-12T08:42:54  *** Evel-Knievel has quit IRC
208 2016-02-12T08:45:06  *** Evel-Knievel has joined #bitcoin-core-dev
209 2016-02-12T08:49:37  *** frankenmint has joined #bitcoin-core-dev
210 2016-02-12T08:52:26  <GitHub170> [bitcoin] wodry opened pull request #7523: Fix of semantic failure "meet pay" (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/7523
211 2016-02-12T08:56:46  *** Sparyx has quit IRC
212 2016-02-12T09:09:19  *** zesi has quit IRC
213 2016-02-12T09:12:06  <GitHub88> [bitcoin] laanwj closed pull request #7523: Fix of semantic failure "meet pay" (0.12...patch-1) https://github.com/bitcoin/bitcoin/pull/7523
214 2016-02-12T09:12:06  <GitHub26> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/04503f78c750...02d707ff37a1
215 2016-02-12T09:12:06  <GitHub26> bitcoin/0.12 e473c2d wodry: Fix of semantic failure "meet pay"...
216 2016-02-12T09:12:07  <GitHub26> bitcoin/0.12 02d707f Wladimir J. van der Laan: Merge #7523: Fix of semantic failure "meet pay"...
217 2016-02-12T09:15:55  *** AaronvanW has joined #bitcoin-core-dev
218 2016-02-12T09:16:12  *** Guyver2 has joined #bitcoin-core-dev
219 2016-02-12T09:16:32  *** paveljanik has joined #bitcoin-core-dev
220 2016-02-12T09:16:32  *** paveljanik has joined #bitcoin-core-dev
221 2016-02-12T09:22:29  *** Sparyx has joined #bitcoin-core-dev
222 2016-02-12T10:02:06  *** randy-waterhouse has quit IRC
223 2016-02-12T10:13:16  *** Sparyx has quit IRC
224 2016-02-12T10:16:12  <wumpus> hm RPC/univalue seems to generate invalid json on special floating point values like NaN, -inf, +inf, not sure what should be generated in that case though (and luckily there is no place in the API where those are normally returned)
225 2016-02-12T10:19:51  <gmaxwell> The hashrate estimate thing left me wondering if it could return a nan in some case.
226 2016-02-12T10:19:59  <gmaxwell> but it didn't look like it.
227 2016-02-12T10:20:09  <gmaxwell> The ping time might be another place.
228 2016-02-12T10:20:19  <gmaxwell> hm guess we don't divide there at least.
229 2016-02-12T10:20:37  *** Sparyx has joined #bitcoin-core-dev
230 2016-02-12T10:20:41  *** Guyver2 has quit IRC
231 2016-02-12T10:20:44  <wumpus> difficulty for an all-zeros target ;)
232 2016-02-12T10:21:36  <wumpus> in any case it should be fixed at some point, I'll report an issue, but doesn't look urgent.
233 2016-02-12T10:23:00  *** dgenr8 has quit IRC
234 2016-02-12T10:23:20  *** dgenr8 has joined #bitcoin-core-dev
235 2016-02-12T10:24:50  *** dgenr8 has joined #bitcoin-core-dev
236 2016-02-12T10:29:21  <wumpus> https://github.com/jgarzik/univalue/issues/19
237 2016-02-12T10:37:12  <wumpus> cfields: did you find a clue why your gitian output doesn't match?
238 2016-02-12T10:40:19  <gmaxwell> wumpus: have you followed the discussion about wallet transaction rebroadcast?
239 2016-02-12T10:41:01  <wumpus> yes
240 2016-02-12T10:41:53  <wumpus> not going to hold up 0.12.0 for another wallet issue though
241 2016-02-12T10:43:36  <wumpus> at some point we just need to make the cut
242 2016-02-12T10:43:51  <wumpus> I hate having to say this every release
243 2016-02-12T10:46:09  <wumpus> leave something to be fixed in 0.12.1
244 2016-02-12T10:46:21  <wumpus> I'm sure more issues will come up
245 2016-02-12T10:47:27  <gmaxwell> OK
246 2016-02-12T10:47:41  <wumpus> this last-minute-based development is unduely stressful
247 2016-02-12T10:48:21  <gmaxwell> well that was why I did hope that the fix for that could be made very small. but indeed.
248 2016-02-12T10:49:13  <gmaxwell> but yes, I don't disagree at all.
249 2016-02-12T10:51:38  <wumpus> a 'small' change still needs testing, especially if made in a hurry
250 2016-02-12T10:52:04  <wumpus> in any case if it turn out we really do need another rc because cfields cannot build this one deterministically, then we can include it
251 2016-02-12T11:07:53  *** Sparyx has quit IRC
252 2016-02-12T11:20:20  *** laurentmt has joined #bitcoin-core-dev
253 2016-02-12T12:01:30  *** frankenmint has quit IRC
254 2016-02-12T12:07:23  <GitHub105> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2f3f4af4cc2b...621940e04090
255 2016-02-12T12:07:23  <GitHub105> bitcoin/master a0a17b3 Pavel Janík: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead
256 2016-02-12T12:07:24  <GitHub105> bitcoin/master 621940e Wladimir J. van der Laan: Merge #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead...
257 2016-02-12T12:07:27  <GitHub160> [bitcoin] laanwj closed pull request #7520: LibreSSL doesn't define OPENSSL_VERSION, use LIBRESSL_VERSION_TEXT instead (master...20160211_LibreSSL_compile_fix) https://github.com/bitcoin/bitcoin/pull/7520
258 2016-02-12T12:09:50  *** frankenmint has joined #bitcoin-core-dev
259 2016-02-12T12:17:00  *** amiller has quit IRC
260 2016-02-12T12:23:17  *** Guest58194 has joined #bitcoin-core-dev
261 2016-02-12T13:04:25  <cfields> wumpus: finally gave up on poking at it and created a clean setup on my macbook, building now. i'll figure out my issue later
262 2016-02-12T13:06:59  <wumpus> okay- there was no trivial difference, the executables were completely out of whack?
263 2016-02-12T13:10:24  <cfields> yea
264 2016-02-12T13:11:07  <cfields> i'll keep my build objects on the fresh builder for comparison. i'd still like to hunt it down, just to be aware of the variable
265 2016-02-12T13:12:19  *** drnet has joined #bitcoin-core-dev
266 2016-02-12T13:20:18  *** Kexkey has joined #bitcoin-core-dev
267 2016-02-12T13:26:01  *** drnet has quit IRC
268 2016-02-12T13:26:57  *** Kexkey has quit IRC
269 2016-02-12T13:44:30  *** Thireus has quit IRC
270 2016-02-12T13:48:01  *** zooko has joined #bitcoin-core-dev
271 2016-02-12T14:10:33  *** Thireus has joined #bitcoin-core-dev
272 2016-02-12T15:09:00  *** paveljanik has quit IRC
273 2016-02-12T15:26:40  *** bityogi has joined #bitcoin-core-dev
274 2016-02-12T15:33:15  *** Thireus1 has joined #bitcoin-core-dev
275 2016-02-12T15:34:13  *** BashCo has quit IRC
276 2016-02-12T15:36:30  *** Thireus has quit IRC
277 2016-02-12T15:43:27  *** Thireus1 has quit IRC
278 2016-02-12T15:43:44  *** Thireus has joined #bitcoin-core-dev
279 2016-02-12T15:47:37  <wumpus> the only thing I can think of that can cause such large differences would be a gcc upgrade on the base image
280 2016-02-12T15:47:52  <wumpus> if it's just some compiled-in variable it's usually just a few bytes difference
281 2016-02-12T15:57:28  *** BashCo has joined #bitcoin-core-dev
282 2016-02-12T15:59:00  *** zooko has quit IRC
283 2016-02-12T16:01:30  *** Guest58194 has quit IRC
284 2016-02-12T16:01:30  *** Guest58194 has joined #bitcoin-core-dev
285 2016-02-12T16:01:30  *** Guest58194 is now known as amiller
286 2016-02-12T16:02:30  *** skyraider_ has joined #bitcoin-core-dev
287 2016-02-12T16:04:21  <GitHub174> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/621940e04090...80d1f2e48364
288 2016-02-12T16:04:22  <GitHub174> bitcoin/master c6c2f0f Alex Morcos: Implement SequenceLocks functions...
289 2016-02-12T16:04:22  <GitHub174> bitcoin/master da6ad5f Suhas Daftuar: Add RPC test exercising BIP68 (mempool only)
290 2016-02-12T16:04:23  <GitHub174> bitcoin/master a51c79b Alex Morcos: Bug fix to RPC test
291 2016-02-12T16:04:26  <GitHub95> [bitcoin] laanwj closed pull request #7184: Implement SequenceLocks functions for BIP 68 (master...alternate68) https://github.com/bitcoin/bitcoin/pull/7184
292 2016-02-12T16:16:26  <btcdrak> OMG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1
293 2016-02-12T16:16:29  <btcdrak> \o/
294 2016-02-12T16:23:02  <wumpus> more gitian problems, this time building macosx. What is happening? https://github.com/bitcoin/gitian.sigs/pull/304
295 2016-02-12T16:29:35  <JackH> this is huge, huge huge huge
296 2016-02-12T16:30:56  <Ylbam> \o/
297 2016-02-12T16:40:16  *** ryitpm has joined #bitcoin-core-dev
298 2016-02-12T16:44:18  *** treehug88 has joined #bitcoin-core-dev
299 2016-02-12T16:45:06  <cfields> wumpus: sigh, another mismatch for me
300 2016-02-12T16:46:57  <wumpus> cfields: strange
301 2016-02-12T16:47:09  <wumpus> so this is with a new base image?
302 2016-02-12T16:49:46  <wumpus> going to have a look at it
303 2016-02-12T16:49:48  <cfields> newish, but i'll try again
304 2016-02-12T16:50:10  <cfields> i think the deps are all equal, so should be much quicker
305 2016-02-12T16:50:24  *** treehug88 has quit IRC
306 2016-02-12T16:52:18  <wumpus> all the mingw .deb packages are equal between us
307 2016-02-12T16:52:38  <wumpus> so that rules out the compiler or binutils
308 2016-02-12T16:53:42  <wumpus> can you upload your win64 result please?
309 2016-02-12T16:55:52  <cfields> yep, sec
310 2016-02-12T17:01:45  *** frankenmint has quit IRC
311 2016-02-12T17:02:22  <cfields> wumpus: https://www.dropbox.com/s/nv27zxuit0202l9/bitcoin-0.12.0-win64.zip
312 2016-02-12T17:04:08  <wumpus> got it
313 2016-02-12T17:05:48  <cfields> actually, some deps don't match on this new build
314 2016-02-12T17:05:55  <wumpus> cfields: so bench_bitcoin, bitcoin-cli, bitcoin-tx match - bitcoind, bitcoin-qt, test-bitcoin and test-bitcoin-qt differ
315 2016-02-12T17:06:04  <wumpus> wild guess: openssl?
316 2016-02-12T17:06:41  <cfields> wumpus: openssl dep matched yours, no?
317 2016-02-12T17:06:50  <wumpus> I didn't check yet
318 2016-02-12T17:07:05  <wumpus> but yes that kind of rules it out
319 2016-02-12T17:07:18  *** paveljanik has joined #bitcoin-core-dev
320 2016-02-12T17:08:46  <wumpus> non-matching executables are the same size - this rules out serious code/version differences
321 2016-02-12T17:10:04  <wumpus> what the hell.
322 2016-02-12T17:10:27  <wumpus> no, I can't make sense of this either, looks like scattered random differences
323 2016-02-12T17:10:31  <cfields> yea, it seems things are just rearranged
324 2016-02-12T17:10:47  <cfields> the random differences are mostly 1/2 bytes, which are just jump offsets
325 2016-02-12T17:11:05  <cfields> s/offsets/addresses/
326 2016-02-12T17:11:31  <wumpus> some gcc random seed issue again?
327 2016-02-12T17:11:38  <cfields> so my guess was that functions got rearranged
328 2016-02-12T17:11:52  <wumpus> or maybe file ordering within .a
329 2016-02-12T17:11:55  <cfields> wumpus: well the weird part is that everyone else matched
330 2016-02-12T17:12:27  <wumpus> my bet would be file ordering, and you using another file system than us
331 2016-02-12T17:12:41  <cfields> otherwise i'd agree. it still points to pebkac, i just can't figure out what's different
332 2016-02-12T17:12:49  <cfields> hmm, could be
333 2016-02-12T17:12:58  <wumpus> or a locale leaking in issue, but you're not in a strange part of the world :-)
334 2016-02-12T17:13:37  <cfields> well i think i did build the day after you guys
335 2016-02-12T17:13:54  <cfields> (and building a 3rd day today)
336 2016-02-12T17:14:01  <wumpus> last time I had an issue like this I compared the linker maps
337 2016-02-12T17:14:14  <wumpus> good point, I'll build mine again to see if it changed.
338 2016-02-12T17:14:55  <cfields> great, thanks. i'll rebuild with a fresh image
339 2016-02-12T17:15:17  <wumpus> are you using LXC or KVM?
340 2016-02-12T17:15:29  <wumpus> (no, I don't think that's what makes the difference)
341 2016-02-12T17:15:31  <cfields> kvm
342 2016-02-12T17:15:35  <wumpus> me too.
343 2016-02-12T17:15:52  <wumpus> but kvm has less chance of external things leaking in
344 2016-02-12T17:16:30  <cfields> right. and i built before on my desktop as usual, today with debian->trusty on my macbook
345 2016-02-12T17:16:37  <cfields> that one should be about as "pure" as it gets
346 2016-02-12T17:29:58  <GitHub164> [bitcoin] btcdrak opened pull request #7524: BIP-112: Mempool-only CHECKSEQUENCEVERIFY (master...checksequenceverify) https://github.com/bitcoin/bitcoin/pull/7524
347 2016-02-12T18:02:35  *** frankenmint has joined #bitcoin-core-dev
348 2016-02-12T18:07:35  *** frankenmint has quit IRC
349 2016-02-12T18:22:38  *** degriff has joined #bitcoin-core-dev
350 2016-02-12T18:42:18  <GitHub81> [bitcoin] jloughry opened pull request #7526: fix spelling of advertise (shows up in the debug log) (master...advertize-advertise) https://github.com/bitcoin/bitcoin/pull/7526
351 2016-02-12T18:42:31  <cfields> wumpus: got a match
352 2016-02-12T18:44:41  *** treehug88 has joined #bitcoin-core-dev
353 2016-02-12T18:46:49  <wumpus> cfields: awesome! so upgrading the base image did it?
354 2016-02-12T18:47:25  <cfields> wumpus: i just made a completely fresh one from debian and moved it over
355 2016-02-12T18:47:59  <wumpus> holy shit I built from scratch (without cache) get a different output now
356 2016-02-12T18:48:12  <cfields> maybe it has something to do with the fact that mine was a much older trusty image, so packages got held back or something
357 2016-02-12T18:48:13  <cfields> ...
358 2016-02-12T18:48:43  <wumpus> -    b13f362e4efbcdcc539398010ef3b287209dc497a057f1f86805cc610c1e6796  bitcoin-0.12.0-win64.zip
359 2016-02-12T18:48:43  <wumpus> +    b785149cc0cc56dfb1c28626300f85ff8ea1b9658f8016bd9b202e32180a2bd9  bitcoin-0.12.0-win64.zip
360 2016-02-12T18:49:14  <wumpus> that's not your output either, it's a third different one?
361 2016-02-12T18:49:25  <cfields> wait, i wonder if that matches my unmatched macbook build
362 2016-02-12T18:49:31  <cfields> sec, let me see if i still have it
363 2016-02-12T18:50:23  <cfields> b785149cc0cc56dfb1c28626300f85ff8ea1b9658f8016bd9b202e32180a2bd9
364 2016-02-12T18:50:33  <cfields> 4098c47e08a882892b2a2b88761cf688ae11d6a5a1d02270a154d60c0393e7fb  bitcoin-0.12.0-win-unsigned.tar.gz
365 2016-02-12T18:50:34  <cfields> ?
366 2016-02-12T18:50:56  <wumpus> wrong file
367 2016-02-12T18:51:26  <cfields> yes, my first file matched yours. was asking if the final result matched too :)
368 2016-02-12T18:52:45  <wumpus> this looks like a different issue: bench, cli, bitcoind, -tx matches, -qt, test_* does not
369 2016-02-12T18:53:02  <wumpus> 4098c47e08a882892b2a2b88761cf688ae11d6a5a1d02270a154d60c0393e7fb yes that's it
370 2016-02-12T18:54:12  <cfields> ok, so there was definitely some recent update that broke us
371 2016-02-12T18:55:04  <wumpus> a small segment of code looks different, no string changes
372 2016-02-12T18:55:14  <wumpus> no jump table scatter either though
373 2016-02-12T18:55:27  <wumpus> yep
374 2016-02-12T18:56:13  <wumpus> -    3a23c66f383d6f26482333a963189f6aed948fc59b651daed3a7a57944d9ac44  i686-w64-mingw32/boost/boost-1_59_0-00e14fdbc48.tar.gz
375 2016-02-12T18:56:14  <wumpus> +    92058863d4944dfb2d5fae3b46014e6121870cb9fc5a016b093afe3f0671fd81  i686-w64-mingw32/boost/boost-1_59_0-00e14fdbc48.tar.gz
376 2016-02-12T18:56:37  <wumpus> -    158452df335b82928c16f70efd3753482c4a737ba0a1c13bb1fa444e1f32738a  x86_64-w64-mingw32/qt/qt-5.5.0-70c250502c5.tar.gz
377 2016-02-12T18:56:37  <wumpus> +    98b13ab377646e3aaebfee54555233b876ecbcc56ac60df88529adfca072bfbb  x86_64-w64-mingw32/qt/qt-5.5.0-70c250502c5.tar.gz
378 2016-02-12T18:56:47  <wumpus> ok ok almost every dependency is different
379 2016-02-12T18:57:08  <wumpus> may be the dependencies were built with older .deb packages, I cannot verify that
380 2016-02-12T18:57:10  <GitHub167> [bitcoin] instagibbs opened pull request #7527: [RPC] Fix and listreceivedbyX documentation (master...listfix) https://github.com/bitcoin/bitcoin/pull/7527
381 2016-02-12T18:57:20  <wumpus> I don't have them anymore I deleted them instead of moving them :(
382 2016-02-12T18:57:59  <cfields> i think i still have copies of everything
383 2016-02-12T18:58:11  <wumpus> but it certainly looks like there are more toolchain versions in play, that's the only explanation I can think of
384 2016-02-12T18:58:48  <cfields> yea. i've been poking for the last few hours on/off, while building. i don't see anything obvious that's updated since november
385 2016-02-12T18:59:14  <Luke-Jr> bisect?
386 2016-02-12T18:59:25  <wumpus> bisect ubuntu?
387 2016-02-12T19:00:02  <Luke-Jr> oh, recent OS update
388 2016-02-12T19:00:34  <cfields> wumpus: well, i'll fixup depends to make sure it detects any kind of system change
389 2016-02-12T19:00:59  <cfields> wumpus: for now, want to just take that last result, since it's the result of a fresh/clean build?
390 2016-02-12T19:01:12  <Luke-Jr> depends should work without determinism, right?
391 2016-02-12T19:01:33  <wumpus> cfields: indeed, having some toolchain version info part of the cache hash would make sense
392 2016-02-12T19:02:23  <wumpus> cfields: yes, I think so. We'll have to recommend everyone to update their base image and rebuild
393 2016-02-12T19:03:09  <cfields> wumpus: yea, i was planning to add `$cc -v | sha256` to the hash, but now i'm thinking it might make sense to take an additional optional seed as well. in gitian's case, it'll be the result of `dpkg -l` or so
394 2016-02-12T19:03:35  *** frankenmint has joined #bitcoin-core-dev
395 2016-02-12T19:03:47  <wumpus> I'm not sure any change in dpkg should cause a rebuild
396 2016-02-12T19:03:57  <cfields> (without trying to add each tool by hand)
397 2016-02-12T19:04:04  <wumpus> right...
398 2016-02-12T19:04:09  <wumpus> we should at least log the tool versions though
399 2016-02-12T19:04:22  <wumpus> (somewhere in the cache directory)
400 2016-02-12T19:04:39  <cfields> well it should only be the toolchain, but i'm not sure we want to enumerate each binary that could change build output
401 2016-02-12T19:04:48  <cfields> yes
402 2016-02-12T19:05:20  <wumpus> I understand. Well maybe detection of every single tool change is too much work, but would be nice to have them somewhere to compare if something like this happens
403 2016-02-12T19:05:24  <cfields> wumpus: did you have to update your base to change the result, or simply nuke the cache?
404 2016-02-12T19:05:52  <wumpus> just the cache
405 2016-02-12T19:06:01  <cfields> ok
406 2016-02-12T19:06:17  <wumpus> the updates should happen automatically
407 2016-02-12T19:06:40  <wumpus> (which can take a long time, especially with LXC, as it starts off with an image with ancient packages)
408 2016-02-12T19:07:01  <wumpus> (but upgrades it before build every time)
409 2016-02-12T19:08:40  *** frankenmint has quit IRC
410 2016-02-12T19:10:11  <cfields> right
411 2016-02-12T19:11:20  <wumpus> so probably a *mingw* .deb upgrade happened in last week
412 2016-02-12T19:12:57  <wumpus> probably yesterday
413 2016-02-12T19:13:39  <wumpus> hm no we can't actually know for sure - I don't know when my last cache was built. But it can't be too long ago.
414 2016-02-12T19:14:41  <wumpus> in any case: everyone should nuke cache and rebuild rc5
415 2016-02-12T19:15:28  *** Arnavion has quit IRC
416 2016-02-12T19:15:57  <cfields> right
417 2016-02-12T19:16:31  <cfields> i'll make the toolchain detection top priority. will try to pr something today, once i/we track down what actually changed
418 2016-02-12T19:18:01  <wumpus> well top priority is getting rc5 out :) but yes would certainly be useful to have, even if it's just a dpkg -l >> $CACHEDIR   so that if something like this happens we can compare the package state under which the old and new cache was built
419 2016-02-12T19:18:05  *** Arnavion has joined #bitcoin-core-dev
420 2016-02-12T19:19:03  <wumpus> because the caching right now  makes the list in the .assert only partially useful
421 2016-02-12T19:20:18  <cfields> yes
422 2016-02-12T19:20:22  <cfields> well
423 2016-02-12T19:20:35  <cfields> i suppose we should rebuild everything, then. might not be mingw related
424 2016-02-12T19:20:46  <cfields> doing osx now
425 2016-02-12T19:21:32  <wumpus> ideally it would list the state under which the cache is built in the assert as well in a separate section, but that would require changes to gitian. In any case having these kind of things tracable would be great.
426 2016-02-12T19:22:00  <wumpus> I don't see how it could be non mingw related
427 2016-02-12T19:22:20  <wumpus> but sure, I'll try rebuilding linux and osx as well
428 2016-02-12T19:24:34  <wumpus> if those differ it would make me even more interested in what changed
429 2016-02-12T19:27:25  <cfields> wumpus: native_protobuf differs already for me. looks like it's system-wide
430 2016-02-12T19:27:49  * wumpus gets his tinfoil hat
431 2016-02-12T19:28:55  <cfields> haha
432 2016-02-12T19:28:56  <wumpus> osx uses a compiler that isn't even part of an ubuntu package right?
433 2016-02-12T19:29:16  <cfields> i had considered that, but dismissed it so far :)
434 2016-02-12T19:29:23  <wumpus> I don't see how this is possible, I want to put 0.12.0 on hold until it is clear what causes this
435 2016-02-12T19:29:40  <cfields> wumpus: yes, but it builds some native packages with the system toolchain first
436 2016-02-12T19:30:04  <cfields> for ex: gcc builds protoc, which preprocesses, and apple-clang builds
437 2016-02-12T19:30:29  <wumpus> but it build *our* protoc, it would be weird if the output of protoc changes based on what compiles it
438 2016-02-12T19:30:41  <cfields> right
439 2016-02-12T19:30:51  <wumpus> suspicious, even
440 2016-02-12T19:30:55  <cfields> i only pointed out that native_protoc changed, not sure if it affects the end result
441 2016-02-12T19:31:14  <cfields> (presumably that one wouldn't, as you said)
442 2016-02-12T19:31:20  <wumpus> sure, let's hope for the best, I don't have build output either yet
443 2016-02-12T19:31:58  * wumpus looking at asm difference 
444 2016-02-12T19:32:59  <cfields> i can't really think of anything that would change the osx result, beyond a gcc change that would really be cause for alarm, enough to affect the behavior of the osx-binutils
445 2016-02-12T19:33:10  <cfields> (cctools)
446 2016-02-12T19:33:28  <cfields> brb
447 2016-02-12T19:33:45  <wumpus> agreed. linux build difference could be explained by *both* a linux and mingw toolchain chainge, but macosx difference would be nearly impossible
448 2016-02-12T19:34:10  <gmaxwell> lets hope the protobuff wasn't backdoored. :)
449 2016-02-12T19:34:41  <wumpus> gmaxwell: in this case it would be the compiler that inserts a backdoor into protobuf </tinfoil hat mode> ;)
450 2016-02-12T19:36:36  <wumpus> well the compiler would insert a backdoor into protoc, which generates C++ code with a backdoor, which gets compiled in. And it's sneaky enough to result in an executable of the same size with some bytes different. Nahh... ;)
451 2016-02-12T19:44:21  <cfields> wumpus: the osx dmg result is the same, but the unsigned .tar.gz is different
452 2016-02-12T19:44:47  <cfields> wumpus: notice also that the comparisontool is different, which is just one file stuffed into a tarball
453 2016-02-12T19:45:10  <cfields> so i'm guessing it's either something related to file-ordering (no clue how), or something low-level like zlib
454 2016-02-12T19:45:34  <wumpus> linux result stays the same for me *happy*
455 2016-02-12T19:46:26  <wumpus> now building mac too, let's see if we at least get the same
456 2016-02-12T19:46:52  <paveljanik> BTW - this week I have read something about ls changes - quoting of filenames with space, different ordering etc...
457 2016-02-12T19:48:30  <wumpus> right, it wouldn't be impossible for a system tool like that to actually make a difference somewhere paveljanik
458 2016-02-12T19:48:40  <cfields> crap, i've gtg. back in an hour or so
459 2016-02-12T19:48:50  <cfields> wumpus: c427d4076e1827d5fd3d645d26f3e1504ffe8b53c33c559c5dc49605d0b10cbd  bitcoin-0.12.0-osx-unsigned.tar.gz
460 2016-02-12T19:49:13  <wumpus> ok thanks, later
461 2016-02-12T19:51:58  <paveljanik> wumpus, http://lists.gnu.org/archive/html/coreutils/2016-02/msg00000.html
462 2016-02-12T19:54:47  <paveljanik> ie. ls from coreutils 8.25. But I think this new version was not in your builds...
463 2016-02-12T19:57:33  <wumpus> I doubt ubuntu stable will upgrade coreutils that soon, and AFAIK we don't use ls anywhere (at least directly), it's likely not that exact issue (but it could be a similar one)
464 2016-02-12T20:01:08  *** laurentmt has quit IRC
465 2016-02-12T20:01:11  <wumpus> f153f1555b60edd61fa57a9b2f6b43d8d6449fd5c0e6a4ef0f4ba745c6376566  bitcoin-0.12.0-osx-unsigned.tar.gz   didn't change for me cfields, osx output is the same
466 2016-02-12T20:06:11  <wumpus> so that points at a mingw toolchain change, and only a mingw toolchain change only. Not sure what causes your .tar.gz difference, but if the dmg is the same at least the executable is the same.
467 2016-02-12T20:13:38  <wumpus> from what I can see from the assembler difference it's exactly the same code, just using slightly different instructions to accomplish the same (e.g. mov shr and instead of testb setne). Typical of a compiler update.
468 2016-02-12T20:14:00  * wumpus takes off his tinfoil hat and goes to bed
469 2016-02-12T20:15:55  * Luke-Jr steals wumpus's tinfoil hat and runs away
470 2016-02-12T20:16:18  <wumpus> hehe
471 2016-02-12T20:27:27  <midnightmagic> yay other people having gitian problems besides me
472 2016-02-12T20:27:58  <midnightmagic> I bet it's just because I do late gitian builds after you guys are all asleep
473 2016-02-12T20:28:31  <midnightmagic> wumpus: but this sort of change makes it hard to reconstruct gitian sigs for earlier 0.12.0rc*
474 2016-02-12T20:29:23  *** treehug88 has quit IRC
475 2016-02-12T20:45:37  *** Guyver2 has joined #bitcoin-core-dev
476 2016-02-12T20:47:30  <GitHub136> [bitcoin] knocte opened pull request #7528: autogen.sh: warn about needing autoconf if autoreconf is not found (master...warn-autoconf) https://github.com/bitcoin/bitcoin/pull/7528
477 2016-02-12T20:51:04  <Luke-Jr> since when is ~/.bitcoin/testnet3/bitcoin.conf ignored and why?
478 2016-02-12T20:52:19  <wumpus> midnightmagic: yes, the caching complicates that, as the package list in the assert is no longer that package state with which everything was built, that's why  isuggested above to also log that
479 2016-02-12T20:52:37  <wumpus> Luke-Jr: that's always been the case, there has never been support for per-chain config files
480 2016-02-12T20:52:44  <Luke-Jr> also, is there any reason *not* to have regtest use non-testnet QSettings?
481 2016-02-12T20:53:09  <Luke-Jr> (this means QApplication appname change)
482 2016-02-12T20:53:11  <wumpus> I don't think regtest in the GUI is very well supported
483 2016-02-12T20:53:28  <wumpus> it works, but probably there's some flukes here and there
484 2016-02-12T20:53:40  <Luke-Jr> any complaint if I make it use its own appname/qsettings? :P
485 2016-02-12T20:53:50  <wumpus> I don't really care, no
486 2016-02-12T20:54:03  <wumpus> it's not something that affects end users
487 2016-02-12T20:54:15  <wumpus> so if that makes testing easier why not
488 2016-02-12T20:54:31  <Luke-Jr> well, IMO it's necessary for saving the network port number in QSettings
489 2016-02-12T20:54:45  <Luke-Jr> (#7107)
490 2016-02-12T20:54:49  *** treehug88 has joined #bitcoin-core-dev
491 2016-02-12T20:54:51  <wumpus> just make sure it doesn't cause any other reversions, as we have hardly/none automatic tests for that stuff
492 2016-02-12T20:55:10  *** xabbix has quit IRC
493 2016-02-12T20:55:21  *** treehug88 has quit IRC
494 2016-02-12T20:55:33  <Luke-Jr> does anything use appname besides qsettings?
495 2016-02-12T20:55:56  *** treehug88 has joined #bitcoin-core-dev
496 2016-02-12T20:56:11  <wumpus> I don't know by heart, I suppose qt docs can help you
497 2016-02-12T20:56:54  * Luke-Jr shocked wumpus doesn't have the entire codebase memorised. :P jk
498 2016-02-12T20:57:41  <wumpus> hey that's unfair it was a aquestion about upstream :P
499 2016-02-12T20:58:13  *** xabbix has joined #bitcoin-core-dev
500 2016-02-12T20:58:14  *** xabbix has joined #bitcoin-core-dev
501 2016-02-12T20:58:19  <midnightmagic> wumpus: apparently there is an effort in debianland to build an archival package-state database which can be used to sync to specific sets of packages.
502 2016-02-12T20:58:21  <Luke-Jr> docs say it's just QSettings
503 2016-02-12T20:58:21  <wumpus> I know most of the bitcoin core codebase in detail, though I sometimes get confused by the wallet and some of the mempool workings
504 2016-02-12T20:58:31  <Luke-Jr> also, apparently it's read-only on Blackberry, but I don't know that we care
505 2016-02-12T20:58:46  <wumpus> I doubt anyone cares about blackberry no :)
506 2016-02-12T20:59:39  <wumpus> there's not even an android bitcoin core release, let alone blackberry
507 2016-02-12T21:00:06  <Luke-Jr> wumpus: GreenBits apparently runs Bitcoin Core Daemon on Android these days
508 2016-02-12T21:00:38  <Luke-Jr> (optionally)
509 2016-02-12T21:00:45  <wumpus> nice. yeah it's certainly possible, I've heard people have done it before, though I don't think it's documented anywhere
510 2016-02-12T21:01:19  <wumpus> probably overheats most phone CPUs, as well as wears out the flash tho :-)
511 2016-02-12T21:24:55  *** Nuief has quit IRC
512 2016-02-12T21:28:37  *** Noice has joined #bitcoin-core-dev
513 2016-02-12T21:31:11  *** Guyver2 has quit IRC
514 2016-02-12T21:37:57  *** Guyver2 has joined #bitcoin-core-dev
515 2016-02-12T21:38:12  <warren> Luke-Jr: what?  full validation with pruning I'm guessig?
516 2016-02-12T21:41:27  *** paveljanik has quit IRC
517 2016-02-12T21:44:46  <morcos> So I've got a first pass at the feefilter idea coded up.  I was thinking I'd also write a BIP for it. But seems like there might be some discussion of the best way to implement the idea.
518 2016-02-12T21:45:03  <morcos> Any suggestions as to whether I should just write the BIP and then have discussion, or show the code first or what?
519 2016-02-12T21:45:05  *** larsk has joined #bitcoin-core-dev
520 2016-02-12T21:46:16  <Luke-Jr> warren: I assume
521 2016-02-12T21:46:28  <Luke-Jr> morcos: ?
522 2016-02-12T21:47:00  *** Chris_Stewart_5 has quit IRC
523 2016-02-12T21:47:21  <morcos> Luke-Jr: The idea is that nodes can optionally broadcast a feefilter p2p message to let their peers know that their mempool is currently limited and they are not accepting txs below a certain feerate
524 2016-02-12T21:48:11  <Luke-Jr> morcos: this idea that fees are the only relevant metric is troubling.
525 2016-02-12T21:48:14  <morcos> This would save considerable network traffic in both invs that are never requested b/c they were previously rejected or requesting of txs that would fail due to insufficient fee
526 2016-02-12T21:48:33  <Luke-Jr> "feerate" is not a well-defined term btw
527 2016-02-12T21:48:34  <morcos> Well the idea I came up with is to make it optional
528 2016-02-12T21:48:55  <Luke-Jr> Core uses a very subjective feerate that discounts part of the transaction, for example
529 2016-02-12T21:49:20  <Luke-Jr> (ModSize)
530 2016-02-12T21:49:23  <morcos> So that if you are a node that is implementing tx prioritization, then even if you have a limited mempool, you have to at least see the hash first b/c the feerate might get modified
531 2016-02-12T21:49:35  <morcos> Luke-Jr: No, thats only for priority.  FeeRate uses actual tx size
532 2016-02-12T21:49:43  <Luke-Jr> hm, it does?
533 2016-02-12T21:49:49  <Luke-Jr> I wonder if it should
534 2016-02-12T21:49:55  <morcos> It's a valid question
535 2016-02-12T21:50:07  <morcos> Partialy answered by segwit
536 2016-02-12T21:51:00  <Luke-Jr> anyway, it's something to consider in your idea
537 2016-02-12T21:51:17  <morcos> The way I was looking at the feature is that if you are just a relay node and you're not doing anything special with regards to priority (which is probably a significant % of the nodes) then this will help cut down on bandwidth significantly
538 2016-02-12T21:51:41  <morcos> If you are running different policy or are a miner and doing prioritization, then you just don't use it
539 2016-02-12T21:52:06  <Luke-Jr> it may bias the network toward a specific policy, which would be bad
540 2016-02-12T21:52:06  <morcos> If used properly it should basically have no effect other than cutting down on useless network traffic
541 2016-02-12T21:53:10  <morcos> I don't see why it would bias the network more than already is the case.
542 2016-02-12T21:53:19  <Luke-Jr> hm, that's a point
543 2016-02-12T21:53:25  <Luke-Jr> already there is lower bw use if you filter
544 2016-02-12T21:54:16  <Luke-Jr> anyway, might make sense to abstract it a little at least
545 2016-02-12T21:54:37  <Luke-Jr> eg, 1 byte for "feerate version" or smth
546 2016-02-12T21:54:44  <Luke-Jr> (maybe varint)
547 2016-02-12T21:55:17  <morcos> You mean have the p2p message be a bit more generic for future extension?
548 2016-02-12T21:55:20  <Luke-Jr> perhaps some way to say "trickle non-matching transactions"?
549 2016-02-12T21:55:21  <Luke-Jr> yes
550 2016-02-12T21:55:27  <morcos> Sure seems reasonable
551 2016-02-12T21:56:00  <morcos> Instead of FeeFilter 8byteFeeRate   It could be InvFilter 1byteType 8byteFeeRAte
552 2016-02-12T21:56:37  <Luke-Jr> varints might be nicer for both fields.
553 2016-02-12T21:57:01  <Luke-Jr> perhaps some way to say "trickle non-matching transactions"? <-- this would nicely fit in with rate-limited priority relaying
554 2016-02-12T21:58:04  <Luke-Jr> (but perhaps not worth the implementation effort)
555 2016-02-12T22:00:06  *** gevs has quit IRC
556 2016-02-12T22:01:39  <morcos> I'm not super familiar with the networking code, but seems like second data field type can depend on the content of the first data field.   But also its not clear that its worth the effort as opposed to just defining different message types for future filters
557 2016-02-12T22:02:03  <morcos> Anyway, sounds like from you comments that perhaps a BIP would be a good next step
558 2016-02-12T22:06:08  <Luke-Jr> morcos: well, I mean I expect the feerate to be small ;)
559 2016-02-12T22:06:36  <Luke-Jr> no need to waste 8 bytes for 100000 when 2 is sufficient
560 2016-02-12T22:06:47  <Luke-Jr> (or is it 3? not relevant)
561 2016-02-12T22:08:39  *** treehug88 has quit IRC
562 2016-02-12T22:13:10  *** gevs has joined #bitcoin-core-dev
563 2016-02-12T22:16:31  <cfields> wumpus: https://lists.ubuntu.com/archives/trusty-changes/2016-February/021179.html
564 2016-02-12T22:16:33  <cfields> got to be that
565 2016-02-12T22:40:12  *** skyraider_ has quit IRC
566 2016-02-12T23:01:16  *** Guyver2 has quit IRC
567 2016-02-12T23:03:17  *** frankenmint has joined #bitcoin-core-dev
568 2016-02-12T23:09:11  *** frankenmint has quit IRC
569 2016-02-12T23:24:08  <degriff> QUIT
570 2016-02-12T23:24:43  *** degriff has quit IRC
571 2016-02-12T23:33:42  *** adnn has quit IRC