1 2016-06-08T00:00:28  <gmaxwell> Funny that.
  2 2016-06-08T00:00:58  * gmaxwell checks to see if he created that article. no, surprising!
  3 2016-06-08T00:03:12  * luke-jr assigns it to sipa's next proposal. jk
  4 2016-06-08T00:45:52  *** hoihut has joined #bitcoin-core-dev
  5 2016-06-08T00:51:16  *** Ylbam has quit IRC
  6 2016-06-08T01:12:04  <adiabat> Hey, wondering if anyone is working on the idea of the "Bloom Filter Digest", like if there's a BIP in the works or anything
  7 2016-06-08T01:12:15  <adiabat> there was a post in the mailing list about a month ago
  8 2016-06-08T01:14:09  *** molly has joined #bitcoin-core-dev
  9 2016-06-08T01:17:09  *** molz has quit IRC
 10 2016-06-08T01:23:01  *** Alopex has quit IRC
 11 2016-06-08T01:24:07  *** Alopex has joined #bitcoin-core-dev
 12 2016-06-08T01:28:40  *** Chris_Stewart_5 has quit IRC
 13 2016-06-08T01:35:04  *** dermoth has quit IRC
 14 2016-06-08T01:35:50  *** dermoth has joined #bitcoin-core-dev
 15 2016-06-08T01:51:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 16 2016-06-08T01:58:18  <Chris_Stewart_5> If I specify a -datadir when launching an instnce of bitcoind, does my bitcoind instance look for a bitcoin.conf inside of my datadir, or ~/.bitcoin/bitcoin.conf?
 17 2016-06-08T02:01:17  *** molz has joined #bitcoin-core-dev
 18 2016-06-08T02:02:57  *** skyraider has joined #bitcoin-core-dev
 19 2016-06-08T02:03:44  <achow101> Chris_Stewart_5: it looks for it in your specified datadir
 20 2016-06-08T02:04:45  *** molly has quit IRC
 21 2016-06-08T02:07:53  <Chris_Stewart_5> achow101: Thanks
 22 2016-06-08T02:12:32  *** hoihut has quit IRC
 23 2016-06-08T02:36:47  *** justanot1eruser has joined #bitcoin-core-dev
 24 2016-06-08T02:36:58  *** justanotheruser has quit IRC
 25 2016-06-08T02:42:17  *** adiabat has quit IRC
 26 2016-06-08T02:46:47  <phantomcircuit> cfields_, travis appears to be borked
 27 2016-06-08T02:47:20  <cfields_> phantomcircuit: https://github.com/bitcoin/bitcoin/pull/8164 ?
 28 2016-06-08T02:47:22  <cfields_> or something else?
 29 2016-06-08T02:48:12  <cfields_> yea, same problem
 30 2016-06-08T02:48:24  <phantomcircuit> https://github.com/bitcoin/bitcoin/pull/8152
 31 2016-06-08T02:48:36  *** assgrass has joined #bitcoin-core-dev
 32 2016-06-08T02:48:50  <phantomcircuit> the no-wallet test fails and that pr is only touching wallet code
 33 2016-06-08T02:48:55  <phantomcircuit> so it's definitely a travis failure
 34 2016-06-08T02:49:33  <cfields_> phantomcircuit: see 8164. master's currently borked, so that will need to be fixed first
 35 2016-06-08T02:49:34  *** assgrass has quit IRC
 36 2016-06-08T02:49:43  <phantomcircuit> jonasschnelli, also i can swap the order of the commits in 8152 such that there's never a performance regression even within the pr
 37 2016-06-08T02:49:44  *** assgrass has joined #bitcoin-core-dev
 38 2016-06-08T02:50:04  <phantomcircuit> ah ok
 39 2016-06-08T02:50:35  *** assgrass has quit IRC
 40 2016-06-08T02:51:24  *** grassass has quit IRC
 41 2016-06-08T02:51:44  *** xiangfu has joined #bitcoin-core-dev
 42 2016-06-08T02:58:36  <cfields_> wumpus: for backlog, ^^ please check out 8164 when you're around if jonasschnelli doesn't beat you to it :)
 43 2016-06-08T02:58:52  *** Kexkey has joined #bitcoin-core-dev
 44 2016-06-08T03:08:45  *** Cory has quit IRC
 45 2016-06-08T03:11:17  *** Kexkey has quit IRC
 46 2016-06-08T03:13:18  *** Chris_Stewart_5 has quit IRC
 47 2016-06-08T03:16:52  *** supasonic has joined #bitcoin-core-dev
 48 2016-06-08T03:28:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 49 2016-06-08T03:32:47  *** achow101 has quit IRC
 50 2016-06-08T03:37:53  *** molly has joined #bitcoin-core-dev
 51 2016-06-08T03:41:00  *** molz has quit IRC
 52 2016-06-08T03:41:58  *** Cory has joined #bitcoin-core-dev
 53 2016-06-08T03:42:47  <GitHub141> [bitcoin] theuni opened pull request #8167: gitian: Ship debug tarballs/zips with debug symbols (master...split-debug) https://github.com/bitcoin/bitcoin/pull/8167
 54 2016-06-08T03:43:03  *** Chris_Stewart_5 has quit IRC
 55 2016-06-08T03:43:47  *** raedah has quit IRC
 56 2016-06-08T03:43:48  *** xiangfu has quit IRC
 57 2016-06-08T03:47:23  *** jiggalator has joined #bitcoin-core-dev
 58 2016-06-08T03:51:17  *** fengling has joined #bitcoin-core-dev
 59 2016-06-08T03:54:38  *** fengling has quit IRC
 60 2016-06-08T04:01:35  *** jiggalator has joined #bitcoin-core-dev
 61 2016-06-08T04:05:14  *** jiggalator has quit IRC
 62 2016-06-08T04:06:02  *** jiggalator has joined #bitcoin-core-dev
 63 2016-06-08T04:11:42  *** justanot1eruser is now known as justanotheruser
 64 2016-06-08T04:13:33  *** jiggalator has quit IRC
 65 2016-06-08T04:39:02  *** Alopex has quit IRC
 66 2016-06-08T04:40:07  *** Alopex has joined #bitcoin-core-dev
 67 2016-06-08T04:51:23  *** moli has joined #bitcoin-core-dev
 68 2016-06-08T04:53:21  *** molly has quit IRC
 69 2016-06-08T04:55:59  *** frankenmint has joined #bitcoin-core-dev
 70 2016-06-08T05:00:01  *** Alopex has quit IRC
 71 2016-06-08T05:01:06  *** Alopex has joined #bitcoin-core-dev
 72 2016-06-08T05:01:33  *** skyraider has quit IRC
 73 2016-06-08T05:04:40  *** jtimon has quit IRC
 74 2016-06-08T05:07:43  *** ghtdak has quit IRC
 75 2016-06-08T05:08:12  *** ghtdak has joined #bitcoin-core-dev
 76 2016-06-08T05:17:47  *** paveljanik has quit IRC
 77 2016-06-08T05:28:29  *** Giszmo has quit IRC
 78 2016-06-08T05:41:14  *** Squidicc has quit IRC
 79 2016-06-08T05:48:04  *** ozanyurt has quit IRC
 80 2016-06-08T05:57:13  *** ghtdak has quit IRC
 81 2016-06-08T06:00:07  *** ghtdak has joined #bitcoin-core-dev
 82 2016-06-08T06:04:48  *** Ylbam has joined #bitcoin-core-dev
 83 2016-06-08T06:26:50  *** blur3d has quit IRC
 84 2016-06-08T06:37:56  *** supasonic has quit IRC
 85 2016-06-08T07:17:33  *** xiangfu has joined #bitcoin-core-dev
 86 2016-06-08T07:18:43  *** ozanyurt has joined #bitcoin-core-dev
 87 2016-06-08T07:19:17  *** trippysa1mon has quit IRC
 88 2016-06-08T07:25:18  *** adiabat has joined #bitcoin-core-dev
 89 2016-06-08T07:46:14  *** adiabat has quit IRC
 90 2016-06-08T07:55:01  <jonasschnelli> wumpus: ParseInt does use int32_t and not uint32_t... isn't that a problem?
 91 2016-06-08T07:55:18  <wumpus> do you need the full range of uint32_t?
 92 2016-06-08T07:55:35  <jonasschnelli> nSequence is uint32_t i guess.
 93 2016-06-08T07:55:45  <wumpus> if so, we need a ParseUint32
 94 2016-06-08T07:56:11  <wumpus> I'll make one.
 95 2016-06-08T07:56:28  <jonasschnelli> Yes. I just saw that there are atoi in bitcoin-tx (before my change) and I just was "continue" that way. But I agree, re-using the ParseInt* stuff is better
 96 2016-06-08T07:56:36  <wumpus> do you need that atoi change in #8164 to 'unstuck' travis?
 97 2016-06-08T07:56:49  <jonasschnelli> yes.
 98 2016-06-08T07:57:00  <wumpus> ok
 99 2016-06-08T07:57:07  <wumpus> I'll just merge #8164 then
100 2016-06-08T07:57:10  <jonasschnelli> yes.
101 2016-06-08T07:57:17  <jonasschnelli> We can change it bitcoin-tx wide later
102 2016-06-08T07:57:32  <wumpus> but we should move away from using low-level number parsing functions and use the ones in util where available
103 2016-06-08T07:57:34  <wumpus> right
104 2016-06-08T07:57:47  <jonasschnelli> There are servals atoi
105 2016-06-08T07:57:54  <jonasschnelli> and even atoi64
106 2016-06-08T07:58:21  <wumpus> the problem is that those functions don't have any error reporting, or range checking, etc
107 2016-06-08T07:58:42  <wumpus> or if they do it's annoying to use
108 2016-06-08T07:58:47  <wumpus> or even OS dependent
109 2016-06-08T07:59:27  <GitHub30> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/79004d4ae671...0f24eaf253ab
110 2016-06-08T07:59:28  <GitHub30> bitcoin/master 86efa30 Jonas Schnelli: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue
111 2016-06-08T07:59:28  <GitHub30> bitcoin/master 0f24eaf Wladimir J. van der Laan: Merge #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue...
112 2016-06-08T07:59:37  <GitHub188> [bitcoin] laanwj closed pull request #8164: [Bitcoin-Tx] fix missing test fixtures, fix 32bit atoi issue (master...2016/04/rbf_base) https://github.com/bitcoin/bitcoin/pull/8164
113 2016-06-08T08:01:03  <jonasschnelli> Yes. And sorry for the travis breaker...
114 2016-06-08T08:01:36  <wumpus> I should have waited for travis before merging, I ran the test locally and assumed it'd be ok
115 2016-06-08T08:03:12  <jonasschnelli> Yes. Did the same. Haven't though about 32bit issues. But great that we have Travis!
116 2016-06-08T08:03:26  *** blur3d has joined #bitcoin-core-dev
117 2016-06-08T08:03:26  <jonasschnelli> A failing travis is always a success. :)
118 2016-06-08T08:03:48  <jonasschnelli> going to re-kick failed pulls
119 2016-06-08T08:19:25  *** kadoban has quit IRC
120 2016-06-08T08:27:02  <GitHub98> [bitcoin] laanwj opened pull request #8168: util: Add ParseUInt32 and ParseUInt64 (master...2016_06_parseuint) https://github.com/bitcoin/bitcoin/pull/8168
121 2016-06-08T08:27:13  <wumpus> let's see if this one passes travis, what surprises windows has in store for us...
122 2016-06-08T08:28:43  <gmaxwell> Great mysteries of the window--- who know what lies beyond it's curtain rimmed borders.
123 2016-06-08T08:30:13  <sipa> the Window kingdom has been in decline for years
124 2016-06-08T08:30:17  <wumpus> a perilous landscape full of traps and mines
125 2016-06-08T08:33:21  <wumpus> "In locales other than the 'C' locale, other strings may be accepted.  (For example, the thousands separator of the current locale may be supported.)" ... oh crap, I thought strto* avoided the locale madness, I was wrong
126 2016-06-08T08:34:18  <wumpus> why is it so difficult to have a number parsing function that does strict parsing and the set of inputs that it accepts is independent of geographical conditions
127 2016-06-08T08:35:53  <wumpus> it's almost easier to just write one from scratch than use the C-provided functions
128 2016-06-08T08:37:09  <wumpus> in any case using our own utility function makes it easier to swap it out later...
129 2016-06-08T08:37:16  <gmaxwell> yea, there are actually a bunch of file formats that are befuxored by this... internationalization was bolted onto the standard library... so there aren't even normal locale independant functions, and you can't change the locale without potentially screwing up other threads.. (well there is the locale_t stuff, but not really portable yet AFAIK)
130 2016-06-08T08:37:56  <wumpus> I can imagine - you need to be such a language lawyer to get these things rihgt
131 2016-06-08T08:38:32  <wumpus> and yes it was bolted on in retrospect
132 2016-06-08T08:39:59  <wumpus> I'm entirely for handling locales where it makes sense, but there's a place for simple deterministic parsing functions (network protocols, file formats) and a place for internationalized handling (such as GUIs), those don't really overlap
133 2016-06-08T08:41:09  <gmaxwell> My general principle is to avoid strings in network protocols and file formats. :) but really, textual file formats are often fairly handy.
134 2016-06-08T08:42:01  <wumpus> sure, but that's a completely orthogonal discussion, usually you don't get to choose
135 2016-06-08T08:43:52  <wumpus> though passing binary numbers on the command line would be interesting :-)
136 2016-06-08T08:45:21  <gmaxwell> just don't type anything with any zero bytes...
137 2016-06-08T08:45:50  <wumpus> well wouldn't be the first time, passing addresses and code is very popular when trying to get setuid'ed executables to do eh non-standard things
138 2016-06-08T08:46:23  <wumpus> yes, those are pesky
139 2016-06-08T08:47:40  <gmaxwell> you mean, to do especially awesome things. :)
140 2016-06-08T08:51:47  *** MarcoFalke has joined #bitcoin-core-dev
141 2016-06-08T08:52:02  <wumpus> exactly
142 2016-06-08T08:52:07  <sipa> wumpus: binary numbers... as in head -n 10011101 file
143 2016-06-08T08:56:20  *** ozanyurt has quit IRC
144 2016-06-08T08:56:32  <wumpus> binary, at the speed of one byte per bit!
145 2016-06-08T08:56:36  *** ozanyurt has joined #bitcoin-core-dev
146 2016-06-08T09:04:08  *** Guyver2 has joined #bitcoin-core-dev
147 2016-06-08T09:05:15  *** ozanyurt has quit IRC
148 2016-06-08T09:05:34  *** ozanyurt has joined #bitcoin-core-dev
149 2016-06-08T09:19:03  *** ghtdak has quit IRC
150 2016-06-08T09:23:19  *** ghtdak has joined #bitcoin-core-dev
151 2016-06-08T09:29:42  *** jannes has joined #bitcoin-core-dev
152 2016-06-08T09:45:03  *** Ginnarr has joined #bitcoin-core-dev
153 2016-06-08T09:47:40  *** laurentmt has joined #bitcoin-core-dev
154 2016-06-08T09:49:30  *** laurentmt has quit IRC
155 2016-06-08T10:01:21  *** xiangfu has quit IRC
156 2016-06-08T10:09:39  *** JackH has joined #bitcoin-core-dev
157 2016-06-08T10:14:23  *** xiangfu has joined #bitcoin-core-dev
158 2016-06-08T10:25:55  *** jl2012 has quit IRC
159 2016-06-08T10:26:20  *** xiangfu has quit IRC
160 2016-06-08T10:40:26  *** Ginnarr has quit IRC
161 2016-06-08T10:45:37  *** jl2012 has joined #bitcoin-core-dev
162 2016-06-08T10:57:13  <GitHub32> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/0f24eaf253ab...2156fa23b8ac
163 2016-06-08T10:57:14  <GitHub32> bitcoin/master beceac9 Peter Todd: Disable the mempool P2P command when bloom filters disabled...
164 2016-06-08T10:57:14  <GitHub32> bitcoin/master 3d3602f Jonas Schnelli: Add RPC test for the p2p mempool command in conjunction with disabled bloomfilters
165 2016-06-08T10:57:15  <GitHub32> bitcoin/master 2156fa2 Wladimir J. van der Laan: Merge #8078: Disable the mempool P2P command when bloom filters disabled...
166 2016-06-08T10:57:23  <GitHub78> [bitcoin] laanwj closed pull request #8078: Disable the mempool P2P command when bloom filters disabled (master...2016-05-mempool-p2p-and-bloom) https://github.com/bitcoin/bitcoin/pull/8078
167 2016-06-08T11:02:12  <GitHub130> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/2156fa23b8ac...67c91f8c4cf7
168 2016-06-08T11:02:13  <GitHub130> bitcoin/master c769c4a Gregory Maxwell: Avoid counting failed connect attempts when probably offline....
169 2016-06-08T11:02:13  <GitHub130> bitcoin/master 6182d10 Gregory Maxwell: Do not increment nAttempts by more than one for every Good connection....
170 2016-06-08T11:02:14  <GitHub130> bitcoin/master 67c91f8 Wladimir J. van der Laan: Merge #8065: Addrman offline attempts...
171 2016-06-08T11:02:22  <GitHub45> [bitcoin] laanwj closed pull request #8065: Addrman offline attempts (master...addrman_offline_attempts) https://github.com/bitcoin/bitcoin/pull/8065
172 2016-06-08T11:07:53  *** edward has joined #bitcoin-core-dev
173 2016-06-08T11:08:34  *** STAFFSCOINS_ has joined #bitcoin-core-dev
174 2016-06-08T11:09:58  <GitHub196> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67c91f8c4cf7...761cddb69029
175 2016-06-08T11:09:58  <GitHub196> bitcoin/master 2e49448 Wladimir J. van der Laan: tor: Change auth order to only use HASHEDPASSWORD if -torpassword...
176 2016-06-08T11:09:59  <GitHub196> bitcoin/master 761cddb Wladimir J. van der Laan: Merge #7703: tor: Change auth order to only use password auth if -torpassword...
177 2016-06-08T11:10:05  <GitHub18> [bitcoin] laanwj closed pull request #7703: tor: Change auth order to only use password auth if -torpassword (master...2016_03_auth_order) https://github.com/bitcoin/bitcoin/pull/7703
178 2016-06-08T11:13:40  *** ozanyurt has quit IRC
179 2016-06-08T11:17:16  <MarcoFalke> wumpus: I have cherry picked the backports for .12 back in April: https://github.com/bitcoin/bitcoin/pull/7938 Hope this is helpful
180 2016-06-08T11:17:30  <MarcoFalke> Also, I was wondering if we need any test framework backports
181 2016-06-08T11:17:41  <sipa> i would say yes
182 2016-06-08T11:17:47  <wumpus> MarcoFalke: thanks!
183 2016-06-08T11:17:57  <MarcoFalke> i.e. segwit backport will be different due to missing py3 in .12
184 2016-06-08T11:18:03  <sipa> i think 0
185 2016-06-08T11:18:13  <sipa> i think 0.12 should be uograded to py3 as well
186 2016-06-08T11:18:16  <wumpus> philosophy for the test framework should be: everything that can run against 0.12 should run against 0.12
187 2016-06-08T11:18:20  <wumpus> agree with sipa
188 2016-06-08T11:18:49  <sipa> of course, if a test requires an rpc that didn't exist in 0.12 yet
189 2016-06-08T11:18:55  <wumpus> there is no reason to be exceedingly careful for regressions with backports of test changes
190 2016-06-08T11:18:55  <sipa> then probably not
191 2016-06-08T11:18:56  <MarcoFalke> Ok, will have a look tonight. Will be quite a huge diff.
192 2016-06-08T11:19:06  <wumpus> yeah, no problem
193 2016-06-08T11:19:10  <sipa> backporting tests never risks breakjng anything :)
194 2016-06-08T11:19:20  <MarcoFalke> Will open a separate pull, just in case
195 2016-06-08T11:19:23  <sipa> ... on the contrary, it may catch bugs in backports
196 2016-06-08T11:20:31  <wumpus> agreed, better to do so in a separate PR, due to the difference in review density
197 2016-06-08T11:21:24  <MarcoFalke> sipa: The python 3 switch for the segwit test was a single commit: https://github.com/sipa/bitcoin/commit/a7eeee1c07b5283c0984fcdaac04faac2d93b2e3. So in case I choke at backporting, you may as well not include those in the backport.
198 2016-06-08T11:21:25  *** ozanyurt has joined #bitcoin-core-dev
199 2016-06-08T11:28:28  *** molz has joined #bitcoin-core-dev
200 2016-06-08T11:30:34  <GitHub9> [bitcoin] jonasschnelli opened pull request #8169: OSX diskimages need 0775 folder permissions (master...2016/06/fix_gitian_osx) https://github.com/bitcoin/bitcoin/pull/8169
201 2016-06-08T11:31:23  *** moli has quit IRC
202 2016-06-08T11:31:37  *** cryptapus has joined #bitcoin-core-dev
203 2016-06-08T12:01:38  <GitHub172> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/761cddb69029...a7c41f2de03c
204 2016-06-08T12:01:39  <GitHub172> bitcoin/master 1b9e6d3 Pieter Wuille: Add support for unique_ptr and shared_ptr to memusage
205 2016-06-08T12:01:39  <GitHub172> bitcoin/master 8d39d7a Pieter Wuille: Switch CTransaction storage in mempool to std::shared_ptr
206 2016-06-08T12:01:40  <GitHub172> bitcoin/master dbfb426 Pieter Wuille: Optimize the relay map to use shared_ptr's...
207 2016-06-08T12:01:48  <GitHub0> [bitcoin] laanwj closed pull request #8126: std::shared_ptr based CTransaction storage in mempool (master...sharedmempool) https://github.com/bitcoin/bitcoin/pull/8126
208 2016-06-08T12:02:33  <GitHub153> [bitcoin] laanwj closed pull request #7530: autogen.sh: check for libtool before automake fails to find it (master...libtool-check) https://github.com/bitcoin/bitcoin/pull/7530
209 2016-06-08T12:14:09  *** paveljanik has joined #bitcoin-core-dev
210 2016-06-08T12:15:17  <GitHub56> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7c41f2de03c...75ec320a0d53
211 2016-06-08T12:15:18  <GitHub56> bitcoin/master faf82e8 MarcoFalke: [rpc] fundrawtransaction: Fix help text and interface
212 2016-06-08T12:15:19  <GitHub56> bitcoin/master fa7f4f5 MarcoFalke: [rpc] fundrawtransaction feeRate: Use BTC/kB...
213 2016-06-08T12:15:19  <GitHub56> bitcoin/master 75ec320 Wladimir J. van der Laan: Merge #8153: [rpc] fundrawtransaction feeRate: Use BTC/kB...
214 2016-06-08T12:15:22  <GitHub172> [bitcoin] laanwj closed pull request #8144: [rpc] fundrawtransaction: Fix help text (master...Mf1606-rpcDoc) https://github.com/bitcoin/bitcoin/pull/8144
215 2016-06-08T12:15:27  <GitHub0> [bitcoin] laanwj closed pull request #8153:  [rpc] fundrawtransaction feeRate: Use BTC/kB  (master...Mf1606-univalAny) https://github.com/bitcoin/bitcoin/pull/8153
216 2016-06-08T12:21:58  *** moli has joined #bitcoin-core-dev
217 2016-06-08T12:24:15  *** molz has quit IRC
218 2016-06-08T12:25:59  <GitHub43> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/75ec320a0d53...6a034ed89891
219 2016-06-08T12:26:00  <GitHub43> bitcoin/master 2b2d52e fanquake: [depends] Freetype 2.6.3...
220 2016-06-08T12:26:01  <GitHub43> bitcoin/master 0385202 fanquake: [depends] ccache 3.2.5
221 2016-06-08T12:26:01  <GitHub43> bitcoin/master bd3cbd5 fanquake: [depends] ZeroMQ 4.1.4
222 2016-06-08T12:26:04  <GitHub64> [bitcoin] laanwj closed pull request #7993: [depends] Bump Freetype, ccache, ZeroMQ, miniupnpc, expat (master...depends-no-sourceforge) https://github.com/bitcoin/bitcoin/pull/7993
223 2016-06-08T12:28:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
224 2016-06-08T12:34:24  *** murch has joined #bitcoin-core-dev
225 2016-06-08T12:38:57  *** da2ce7_mobile has quit IRC
226 2016-06-08T12:40:07  *** dermoth_ has joined #bitcoin-core-dev
227 2016-06-08T12:40:35  *** dermoth has quit IRC
228 2016-06-08T12:40:37  *** dermoth_ is now known as dermoth
229 2016-06-08T12:44:11  *** da2ce7_mobile has joined #bitcoin-core-dev
230 2016-06-08T12:53:32  *** fengling has joined #bitcoin-core-dev
231 2016-06-08T12:55:07  <GitHub34> [bitcoin] sipa opened pull request #8170: Remove lookup-tx-by-utxo functionality (master...betternotxindex) https://github.com/bitcoin/bitcoin/pull/8170
232 2016-06-08T13:13:15  *** jarret has quit IRC
233 2016-06-08T13:14:45  <jonasschnelli> Hmm....
234 2016-06-08T13:15:19  <jonasschnelli> another cleanup required for one of my pulls..
235 2016-06-08T13:15:22  <jonasschnelli> *sight*
236 2016-06-08T13:16:07  <sipa> sight is good
237 2016-06-08T13:16:52  <jonasschnelli> *sigh* :-)
238 2016-06-08T13:17:09  <jonasschnelli> wumpus: can you extend your ParseUInt32 to univalue?
239 2016-06-08T13:17:38  <wumpus> why would univalue need to parse unsigned 32 bit integers?
240 2016-06-08T13:18:00  <jonasschnelli> createrawtransactions new sequence number input per vin does not support unsigned
241 2016-06-08T13:18:10  <wumpus> we treat all integers as 64 bit signed
242 2016-06-08T13:18:15  <jonasschnelli> So > 0x7FFFFFFF will be rejected.. :(
243 2016-06-08T13:18:26  <wumpus> which should be enough to support the full 32 bit unsigned range
244 2016-06-08T13:18:31  <jonasschnelli> It calls int UniValue::get_int() const
245 2016-06-08T13:18:40  <jonasschnelli> which does a `if (!ParseInt32(getValStr(), &retval))`
246 2016-06-08T13:18:52  <jonasschnelli> and throws > 0x7FFFFFFF
247 2016-06-08T13:18:52  <wumpus> oh, just use the 64-bit one then
248 2016-06-08T13:19:04  *** Chris_Stewart_5 has quit IRC
249 2016-06-08T13:19:14  <sipa> use get_int64(), and rangecheck the result
250 2016-06-08T13:19:16  <wumpus> I don't think we should be adding more types of integers to JSON, that just complicates things
251 2016-06-08T13:19:26  <jonasschnelli> Right... let me try
252 2016-06-08T13:19:39  <wumpus> our previous JSON parsing library didn't even have a 32-bit signed integer get
253 2016-06-08T13:25:26  *** jtimon has joined #bitcoin-core-dev
254 2016-06-08T13:25:49  <jonasschnelli> should we allow -1 as sequence numbers? Pretty convenient.
255 2016-06-08T13:28:17  <wumpus> wouldn't be very consistent if we do strict 32-bit unsigned int parsing for the -tx
256 2016-06-08T13:29:44  <jonasschnelli> yes. Let me do a <0 check
257 2016-06-08T13:30:32  <wumpus> I'd say sequence number is a positive value, and that should be enforced in the API; though -1 is convenient, negative numbers are slightly ambigious
258 2016-06-08T13:31:18  <wumpus> we also print sequence numbers as unsigned int I hope?
259 2016-06-08T13:32:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
260 2016-06-08T13:37:52  *** jcorgan has joined #bitcoin-core-dev
261 2016-06-08T13:38:56  <jonasschnelli> wumpus: at least decoderawtransaction does this correct.
262 2016-06-08T13:39:07  <wumpus> good, thanks for checking
263 2016-06-08T13:39:15  <jonasschnelli> heh: entry.push_back(Pair("sequence", (uint64_t)txin.nSequence));
264 2016-06-08T13:39:40  <jonasschnelli> I guess UniValues has no uint32 pair?
265 2016-06-08T13:40:10  <jonasschnelli> but (uint64_t)txin.nSequence is fine IMO
266 2016-06-08T13:40:17  <wumpus> yea, please just use 64 bit signed integeres with JSON
267 2016-06-08T13:41:41  <wumpus> there's no need to support other integer types - certainly not for output, for input a specific range checked get function could be mildly useful, but that probably belongs at the application (argument checking) side, not in univalue itself
268 2016-06-08T13:44:04  <GitHub34> [bitcoin] jonasschnelli opened pull request #8171: [RPC] Fix createrawtx sequence number unsigned int parsing (master...2016/06/fix_crt) https://github.com/bitcoin/bitcoin/pull/8171
269 2016-06-08T13:44:34  <GitHub123> [bitcoin] sipa pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/6a034ed89891...66ed450d771a
270 2016-06-08T13:44:35  <GitHub123> bitcoin/master d3df40e Luke Dashjr: Implement BIP 9 GBT changes...
271 2016-06-08T13:44:35  <GitHub123> bitcoin/master 72cd6b2 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
272 2016-06-08T13:44:36  <GitHub123> bitcoin/master 9879060 Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not
273 2016-06-08T13:44:39  <GitHub100> [bitcoin] sipa closed pull request #7935: Versionbits: GBT support (master...gbt_bip9) https://github.com/bitcoin/bitcoin/pull/7935
274 2016-06-08T13:45:06  *** Chris_Stewart_5 has quit IRC
275 2016-06-08T13:45:54  <GitHub68> [bitcoin] sipa opened pull request #8172: Fix two warnings for comparison between signed and unsigned (master...fixunsigned) https://github.com/bitcoin/bitcoin/pull/8172
276 2016-06-08T13:47:52  *** Giszmo has joined #bitcoin-core-dev
277 2016-06-08T13:48:49  *** jannes has quit IRC
278 2016-06-08T13:52:51  <GitHub73> [bitcoin] laanwj opened pull request #8173: test: Add more test vectors for siphash (master...2016_06_siphash_testing) https://github.com/bitcoin/bitcoin/pull/8173
279 2016-06-08T13:54:41  *** achow101 has joined #bitcoin-core-dev
280 2016-06-08T13:55:20  <GitHub7> [bitcoin] sipa closed pull request #8086: Use SipHash for node eviction (master...moresiphash) https://github.com/bitcoin/bitcoin/pull/8086
281 2016-06-08T14:02:08  *** Chris_Stewart_5 has joined #bitcoin-core-dev
282 2016-06-08T14:04:58  *** kadoban has joined #bitcoin-core-dev
283 2016-06-08T14:18:42  *** Chris_Stewart_5 has quit IRC
284 2016-06-08T14:25:38  *** _anthony_ has joined #bitcoin-core-dev
285 2016-06-08T14:26:20  <_anthony_> woohoo it's like I've built a time machine
286 2016-06-08T14:26:25  <_anthony_> hello all
287 2016-06-08T14:28:19  <_anthony_> BtcDrak said that I can be a core dev
288 2016-06-08T14:28:21  <sipa> hello
289 2016-06-08T14:28:26  <_anthony_> hi sipa
290 2016-06-08T14:33:55  <achow101> _anthony_: anyone can be a "core dev". You just need to submit PRs to Bitcoin Core
291 2016-06-08T14:34:17  <instagibbs> please don't forget review of PRs
292 2016-06-08T14:34:20  <_anthony_> OK. What PRs do you want me to work on?
293 2016-06-08T14:34:45  <_anthony_> Is there any internals documentation that needs to be worked on?
294 2016-06-08T14:36:43  <wumpus> generally all PRs and issues that are open are fair game, of course reviewing segwit or compact blocks etc may be the most urgent
295 2016-06-08T14:37:20  <instagibbs> when is freeze for 0.13
296 2016-06-08T14:37:53  <wumpus> segwit: https://github.com/bitcoin/bitcoin/pull/8149  compact blocks: https://github.com/bitcoin/bitcoin/pull/8068
297 2016-06-08T14:38:04  <wumpus> instagibbs: feature freeze is june 16
298 2016-06-08T14:38:27  <wumpus> release schedule for 0.13.0: https://github.com/bitcoin/bitcoin/issues/7679
299 2016-06-08T14:38:40  <instagibbs> I'll try and make time to review CB soon
300 2016-06-08T14:39:19  *** fengling has quit IRC
301 2016-06-08T14:39:21  <_anthony_> hmm I definitely need to get more familiar with the way the code is layed out...maybe while reviewing segwit I can do that
302 2016-06-08T14:39:45  <btcdrak> welcome  _anthony_
303 2016-06-08T14:40:06  <instagibbs> _anthony_, that's a bear of a first PR to review :)
304 2016-06-08T14:40:10  <_anthony_> thanks btcdrak
305 2016-06-08T14:40:17  <sipa> _anthony_: usually the best way to learn a codebase is by contributing yourself... find relatively simple improvements, and try to fix them
306 2016-06-08T14:40:41  <sipa> _anthony_: reviewing changes to a codebase that you're not familiar with is not so effective i think
307 2016-06-08T14:40:48  <_anthony_> I went through some of the open issues yesterday...it looks like some of them should be closed
308 2016-06-08T14:41:08  <instagibbs> Writing tests can be good practice too.
309 2016-06-08T14:41:10  <wumpus> _anthony_: that can certainly happen, feel free to let us know if that is the case
310 2016-06-08T14:41:31  <_anthony_> k I'll keep a list next time I come across one
311 2016-06-08T14:41:41  <wumpus> sometimes an issue is fixed but forgotten about, I tend to go over the full list at least monthly but some things slip through
312 2016-06-08T14:54:38  *** ozanyurt_ has joined #bitcoin-core-dev
313 2016-06-08T14:57:54  *** ozanyurt has quit IRC
314 2016-06-08T15:02:34  *** blur3d has quit IRC
315 2016-06-08T15:39:27  *** laurentmt has joined #bitcoin-core-dev
316 2016-06-08T15:40:03  *** laurentmt has quit IRC
317 2016-06-08T15:42:36  <GitHub12> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/66ed450d771a...cd0c5135ab22
318 2016-06-08T15:42:36  <GitHub12> bitcoin/master 2d83013 Jonas Schnelli: Add support for dnsseeds with option to filter by servicebits
319 2016-06-08T15:42:37  <GitHub12> bitcoin/master cd0c513 Pieter Wuille: Merge #8083: Add support for dnsseeds with option to filter by servicebits...
320 2016-06-08T15:42:46  <GitHub53> [bitcoin] sipa closed pull request #8083: Add support for dnsseeds with option to filter by servicebits (master...2016/05/dnsfilter) https://github.com/bitcoin/bitcoin/pull/8083
321 2016-06-08T15:44:22  <cfields_> jonasschnelli: great work on ^^
322 2016-06-08T15:44:35  <sipa> petertodd, luke-jr: subtle ping to update your dns seeds to support service bits filtering
323 2016-06-08T15:46:23  <jonasschnelli> cfields_: the bitcoin part was easy, the part on the bitcoin-seeder was more complex. :)
324 2016-06-08T15:46:33  <jonasschnelli> Also code i'm not use to play around with.
325 2016-06-08T15:47:11  <jonasschnelli> But as always, sipa made the important last changes/fixes. :)
326 2016-06-08T15:47:16  <cfields_> jonasschnelli: yea, i took a quick look. steep learning curve there
327 2016-06-08T15:50:26  <sipa> i wrote it in a week while i was ill
328 2016-06-08T15:50:43  <sipa> certainly not the best code i've written :)
329 2016-06-08T15:53:34  <cfields_> heh, well it's apparently pretty bullet-proof. can't argue with that :)
330 2016-06-08T16:08:24  <cfields_> ok, I was trying to avoid this because i know everyone's busy with a dozen other things, but I'll be away for a while after Friday, and I'm hoping to get as much net refactor stuff as possible knocked out first...
331 2016-06-08T16:08:34  <cfields_> so... review begs for #8128 and #8085
332 2016-06-08T16:09:34  *** aj has quit IRC
333 2016-06-08T16:09:43  <cfields_> (and taking requests for anything I should prioritize before leaving)
334 2016-06-08T16:10:25  *** aj has joined #bitcoin-core-dev
335 2016-06-08T16:25:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
336 2016-06-08T16:33:00  <GitHub88> [bitcoin] sipa pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/cd0c5135ab22...4286f4302514
337 2016-06-08T16:33:01  <GitHub88> bitcoin/master 053930f Patrick Strateman: Avoid recalculating vchKeyedNetGroup in eviction logic....
338 2016-06-08T16:33:02  <GitHub88> bitcoin/master 9bf156b Pieter Wuille: Support SipHash with arbitrary byte writes
339 2016-06-08T16:33:03  <GitHub88> bitcoin/master c31b24f Pieter Wuille: Use 64-bit SipHash of netgroups in eviction
340 2016-06-08T16:33:07  <GitHub140> [bitcoin] sipa closed pull request #8173: Use SipHash for node eviction (cont'd) (master...2016_06_siphash_testing) https://github.com/bitcoin/bitcoin/pull/8173
341 2016-06-08T16:54:48  <jonasschnelli> Is there a way within CWallet / CWalletTx to detect which of the tx.vout's is the change output if the wtx is a spend-to-myself?
342 2016-06-08T16:55:01  <jonasschnelli> AddressBook lookup?
343 2016-06-08T16:55:33  *** Chris_Stewart_5 has quit IRC
344 2016-06-08T16:57:02  <luke-jr> yes
345 2016-06-08T16:57:33  <jonasschnelli> So I need to solve the pubkey and check if its P2PKH (or different), get the CKeyID and do an addressbook lookup...
346 2016-06-08T16:57:40  <jonasschnelli> hmm... not good. :)
347 2016-06-08T16:58:20  <jonasschnelli> s/solve the pubkey/use the solver on the scriptPubKey to retrieve the address
348 2016-06-08T16:58:52  <sipa> jonasschnelli: no, you convert to a CTxDestination and then check whether that's in the address book
349 2016-06-08T16:59:18  <jonasschnelli> sipa: with ExtractDestination()?
350 2016-06-08T16:59:26  <sipa> yes
351 2016-06-08T16:59:46  <jonasschnelli> Okay.. that sounds feasible.
352 2016-06-08T17:02:40  <cfields_> sipa: wrt #7749, do we want to maybe filter the addresses we send in response to getaddr based on the current connection's common services? or maybe prioritize those somehow?
353 2016-06-08T17:07:15  *** jarret has joined #bitcoin-core-dev
354 2016-06-08T17:08:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
355 2016-06-08T17:10:40  *** ozanyurt_ has quit IRC
356 2016-06-08T17:13:49  <jl2012> is it possible to use signrawtransaction to sign a multisig tx with flags other than SIGHASH_ALL?
357 2016-06-08T17:15:07  <gmaxwell> Yes.
358 2016-06-08T17:15:18  <gmaxwell> it takes an argument to set the flags it will sign with.
359 2016-06-08T17:20:22  *** Squidicuz has joined #bitcoin-core-dev
360 2016-06-08T17:22:22  <NicolasDorier> sipa: long story short bytespersigop enforced in AcceptToMempool broke some use case on upper layer (https://github.com/bitcoin/bitcoin/issues/8079) we have a simple way to fix it, but it would require to count signatures for a transaction a second time accuratly.  Do you think it would be a problem performance wise ? I don't think so but maybe I am missing
361 2016-06-08T17:22:22  <NicolasDorier> something.
362 2016-06-08T17:24:31  <jl2012> gmaxwell: the sighash flag is the 4th argument. 1st argument is the unsigned tx. However, when I use [] [] as the 2nd and 3rd arguments, it fails to sign
363 2016-06-08T17:25:23  <jl2012> without any optional arguments, it signs normally
364 2016-06-08T17:25:58  <jl2012> btw i'm signing a P2SH-P2WSH
365 2016-06-08T17:45:48  <NicolasDorier> oh whatever, I'm pretty sure it can't be a perf problem, as the second count is done only on a very specific case. nevermind
366 2016-06-08T17:46:42  <sipa> NicolasDorier: i don't understand the solution you suggest
367 2016-06-08T17:47:49  <NicolasDorier> sipa: Well basically bytespersig use GetLegacySigCount which overshoot multisig real signature count. Because of that, it broke an upper layer protocol (counteryparty)
368 2016-06-08T17:47:52  <NicolasDorier> the solution
369 2016-06-08T17:48:37  <NicolasDorier> would be "if(nSigOps > MAX_STANDARD_TX_SIGOPS)", then you count signature again accurately, and use such count for calculating if bytespersigop is reached or not
370 2016-06-08T17:48:44  <sipa> heh, does counterparty still e ist
371 2016-06-08T17:48:53  <sipa> i see
372 2016-06-08T17:48:56  <sipa> that would work
373 2016-06-08T17:49:00  <NicolasDorier> well, I'm not using it, but yeah it seems very much alive
374 2016-06-08T17:49:08  <sipa> :(
375 2016-06-08T17:49:14  <sipa> anyway, sounds like a good solution
376 2016-06-08T17:49:20  <NicolasDorier> ok cool
377 2016-06-08T17:53:07  <rubensayshi> counterparty uses it as fallback when > 80 bytes, which is 0.0x% or something
378 2016-06-08T17:56:15  <gmaxwell> People involved with counterparty have told me they intend for counterparty to replace the bitcoin currency because the distribution of bitcoins is "unfair" and counterparty is "more equitable"-- I don't think it's accurate to describe it as an "upper layer" system, it's a system that explicitly is in competition with the bitcoin currency.
379 2016-06-08T18:02:12  <sipa> NicolasDorier: your solution does not work, because it reintroduces the problem that the original PR was intended to fix
380 2016-06-08T18:02:53  <sipa> NicolasDorier: the consensus rules count those as 20 sigops; if for mining purposes do not count it as 20, the attack reappears
381 2016-06-08T18:04:07  <sdaftuar> sipa: doesn't the code as merged still allow for an attack, as you could fill up 400kb of block space with 20k sigops?
382 2016-06-08T18:04:51  <sipa> sdaftuar: hmm?
383 2016-06-08T18:05:18  <sipa> 20k sigops should be counted as 1 MB, no?
384 2016-06-08T18:05:37  <sdaftuar> sorry i think i phrased poorly.  at 20bytes/sigop, you could hit the 20k sigops limit with only 400kb of transactions
385 2016-06-08T18:05:51  <sipa> it should be 50 bytes/sigop
386 2016-06-08T18:05:53  <sdaftuar> yes
387 2016-06-08T18:06:03  <sdaftuar> unless there are valid use cases which we'd preclude, that is?
388 2016-06-08T18:06:17  <sdaftuar> but regardless we should have had this discussion when that PR was merged.  i have no idea where 20 comes from
389 2016-06-08T18:06:34  <sdaftuar> or what the valid use cases are...
390 2016-06-08T18:06:43  <sipa> i think i assumed that number was the correct translation factor when it was merged
391 2016-06-08T18:07:29  <sipa> but dropping transactions that go over the limit is wrong, i think
392 2016-06-08T18:07:30  *** Squidicuz has quit IRC
393 2016-06-08T18:07:44  *** Squidicuz has joined #bitcoin-core-dev
394 2016-06-08T18:07:54  <sipa> we should just count them as if they were the correspondig size
395 2016-06-08T18:07:58  *** Squidicc has joined #bitcoin-core-dev
396 2016-06-08T18:08:08  <sdaftuar> you mean for feerate purposes?
397 2016-06-08T18:10:35  <gmaxwell> thats what I argued for forever but there was some reason people didn't like it... convert each limit to a feerate, and take the worst... under the approximation that whatever is worst will be the limiting factor.
398 2016-06-08T18:10:58  <sdaftuar> that approximation doesn't hold in CreateNewBlock, most of the time, i'd think
399 2016-06-08T18:11:14  <sdaftuar> most of the time you're nowhere near the sigops limit
400 2016-06-08T18:11:24  <gmaxwell> it doesn't, but the size is the worst most of the time, so it doesn't matter except for excpetional transactions.
401 2016-06-08T18:11:30  <sipa> yes, this is the nonlinear optimization problem again
402 2016-06-08T18:11:44  <paveljanik> sipa, thanks for fixing the warnings!
403 2016-06-08T18:11:54  <sipa> but if you use the same count for mining and for relay/priority, there is no problem i think
404 2016-06-08T18:12:37  <sipa> at least you wouldn't lose money over it as a miner
405 2016-06-08T18:12:48  <sdaftuar> well miners woulnd't be doing the optimal thing?
406 2016-06-08T18:13:39  <helo> they'll intend to do the optimal thing, at least
407 2016-06-08T18:13:54  *** bsm1175321 has quit IRC
408 2016-06-08T18:15:12  <sipa> sdaftuar: right, suboptimal, but not susceptible to losing a majority of yiur available block space
409 2016-06-08T18:16:37  <gmaxwell> Suboptimal though only in the presence of transactions whos sigops cost would dominate their size cost.
410 2016-06-08T18:16:42  <sdaftuar> yeah maybe that's good enough, and better than the status quo
411 2016-06-08T18:19:06  <gmaxwell> It's my belief (and hope) that the other limits are set so high that they should never come into effect in practice.
412 2016-06-08T18:19:25  <gmaxwell> (though this isn't true if people use bare multisig, but they mostly don't)
413 2016-06-08T18:20:56  <sipa> the fact that this problem only got detected so many months after 0.12 shows that probably not many people use bare multisig...
414 2016-06-08T18:23:10  <GitHub47> [bitcoin] laanwj opened pull request #8175: gitian: Add --disable-bench to config flags for windows (master...2016_06_disable_bench_windows) https://github.com/bitcoin/bitcoin/pull/8175
415 2016-06-08T18:31:35  <rubensayshi> offtopic; gmaxwell, I've never heard any1 say counterparty competes with bitcoin, it's focus is tokens (and soon EVM), it would be insane to think it could compete with bitcoin (considering the reduced efficiency)
416 2016-06-08T18:32:21  <rubensayshi> sipa, I wouldn't find it odd if you guys would decide to block bare multisig from isstandard, but this check wasn't intended that way and the result did
417 2016-06-08T18:32:53  <rubensayshi> though there might be people still  using it, and I don't see it being isstandard as such a big problem
418 2016-06-08T18:33:29  <sipa> rubensayshi: agree, i think there are good reasons to make it nonstandard, but it should happen intentionally and after communication, not as an unintended side effect
419 2016-06-08T18:34:24  <rubensayshi> the consensus rules count bare multisig as 20 sigops, and considering it's part of consensus should continue to do so
420 2016-06-08T18:34:44  <rubensayshi> I guess the reason why we don't properly count the sigops to begin with is because it's been part of consensus since day 1
421 2016-06-08T18:35:17  <gmaxwell> it wasn't a part of consensus since day 1, </pedantic>
422 2016-06-08T18:35:27  <rubensayshi> oh?
423 2016-06-08T18:36:50  <sipa> i assume it was introeuced somewhere in 2010
424 2016-06-08T18:37:34  <sipa> whether they were part of the consensus rules on day 1 is also irrelevant; what matters if they are part of consensus now :)
425 2016-06-08T18:39:53  <rubensayshi> ok, but changing the `bytespersigop` check in AcceptToMempool to use `fAccurate=True` shouldn't be a problem right?
426 2016-06-08T18:40:24  <gmaxwell> that would defeat the fix against the bloat attack.
427 2016-06-08T18:40:33  <gmaxwell> The counting has to work exactly as the consensus rule does.
428 2016-06-08T18:42:57  *** MarcoFalke has left #bitcoin-core-dev
429 2016-06-08T18:45:30  <rubensayshi> hmm, the consensus prevents a block being larger than 1mb or 20k sigops, so you don't want to accept any txs that would tip over the balance to reaching the 20k sigops before you'd reach 1mb?
430 2016-06-08T18:46:03  <rubensayshi> as in; to optimize fees?
431 2016-06-08T18:46:38  <gmaxwell> rubensayshi: thats right.. there was some attacker a while back flooding the network with transactions that used huge amounts of sigops, which would cause miners to needlessly produce small blocks.
432 2016-06-08T18:47:05  <gmaxwell> there are multiple ways to address that.
433 2016-06-08T18:47:11  <rubensayshi> ok so I guess I get sipa's point, because we rely on fee/size and not on sigops/size when that's higher
434 2016-06-08T18:48:53  *** adiabat has joined #bitcoin-core-dev
435 2016-06-08T18:57:18  <rubensayshi> so there's no way to bring back bare multisig other than miners choosing to run with a lower `bytespersigop` (but you just said the default should be 50, not the current 20 to begin with) or changing the consensus rule where bare multisig is counted as 20 sigops?
436 2016-06-08T18:57:29  *** Chris_Stewart_5 has quit IRC
437 2016-06-08T18:58:23  <gmaxwell> the broken counting was a softfork added in sept 2010, in ~0.3.12.
438 2016-06-08T18:59:54  <rubensayshi> so the only valid option would be to improve selecting TXs for blocks in a way that it won't use TXs with high sigops/bytes if it would result in not having a full block so that the check doesn't have to be in the mempool policy
439 2016-06-08T19:00:04  <rubensayshi> which is ...
440 2016-06-08T19:00:16  <rubensayshi> way to much complexity and too big of a task
441 2016-06-08T19:02:29  *** molz has joined #bitcoin-core-dev
442 2016-06-08T19:04:22  <gmaxwell> 20 is more permissive than 50, fwiw.
443 2016-06-08T19:04:28  *** moli has quit IRC
444 2016-06-08T19:04:51  <gmaxwell> there was a discussion on IRC about setting it, and 20 seemsed to be the lowest that it could be set without outright enabling that attack.
445 2016-06-08T19:05:46  <sdaftuar> gmaxwell: pointer to the IRC conversation?  i looked and never found any discussion
446 2016-06-08T19:05:57  <gmaxwell> rubensayshi: right, and generally we consider bare multisig undesirable for unrelated reasons too, and there is longstanding discussion toward moving to make it non-standard... so doesn't really justify a bunch of complexity to try to work around it.
447 2016-06-08T19:06:15  <rubensayshi> I guess it should just be made non standard then
448 2016-06-08T19:06:28  <rubensayshi> which it essentially is now
449 2016-06-08T19:07:28  <rubensayshi> how about some extra bytes for opreturn then :P ?
450 2016-06-08T19:09:32  *** moli has joined #bitcoin-core-dev
451 2016-06-08T19:10:19  <gmaxwell> sdaftuar: turns out searching for the number 20 is really hard.
452 2016-06-08T19:10:39  <btcdrak> maybe sigop?
453 2016-06-08T19:11:32  <btcdrak> gmaxwell: how about this? https://botbot.me/freenode/bitcoin-core-dev/2015-10-22/?msg=52464204&page=1
454 2016-06-08T19:12:00  *** molz has quit IRC
455 2016-06-08T19:12:26  *** TomMc has joined #bitcoin-core-dev
456 2016-06-08T19:13:15  <btcdrak> another conversation starts here https://botbot.me/freenode/bitcoin-core-dev/2015-11-04/?msg=53446658&page=2
457 2016-06-08T19:13:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
458 2016-06-08T19:14:08  <luke-jr> regardless of what we do to fix bytespersigop, I think we should disable bare multisig by default; with that in mind, *which* solution we go with seems less important
459 2016-06-08T19:15:23  <luke-jr> (but IMO the better fix is to simply count CHECKMULTISIG correctly for this purpose, since the goal is spam prevention, and higher fees don't matter in that case)
460 2016-06-08T19:15:57  <GitHub83> [bitcoin] luke-jr opened pull request #8176: [0.12.x]: Versionbits: GBT support (0.12...gbt_bip9-0.12.x) https://github.com/bitcoin/bitcoin/pull/8176
461 2016-06-08T19:17:06  <luke-jr> rubensayshi: what happened to OP_RETURN counterparty?
462 2016-06-08T19:17:14  <gmaxwell> it isn't about charging more fees, the whole attack was causing miners to produce needlessly small blocks because they thought sigopbloat txn were more attractive to produce than they were.
463 2016-06-08T19:17:39  <gmaxwell> if an attacker had to pay as much to 'fill' a block that way as they would with ordinary transactions, then it's no longer an interesting attack vector.
464 2016-06-08T19:17:43  <rubensayshi> luke-jr, literally 99.988% of CP txs are opreturn
465 2016-06-08T19:18:07  <btcdrak> luke-jr: they use OP_RETURN for messages < 80 bytes which is most of them.
466 2016-06-08T19:18:11  <luke-jr> rubensayshi: why not 100%?
467 2016-06-08T19:18:47  <luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
468 2016-06-08T19:19:12  <rubensayshi> is there a reason not to change isstandard to allow opreturn with more data?
469 2016-06-08T19:19:17  *** ozanyurt has joined #bitcoin-core-dev
470 2016-06-08T19:19:27  <rubensayshi> they dont polute utxo set and are prunable
471 2016-06-08T19:19:31  <rubensayshi> and fee is paid for them
472 2016-06-08T19:19:47  <gmaxwell> rubensayshi: Bitcoin is a currency not a public shared database.
473 2016-06-08T19:19:55  <sipa> you're storing data on my disk, without benefitting me or the bitcoin ecosystem
474 2016-06-08T19:20:19  *** grubles_ has joined #bitcoin-core-dev
475 2016-06-08T19:20:27  <btcdrak> gmaxwell: what concerns me is if systems resort to bloating the UTXO with unspendable transactions as a way to encode >80 bytes.
476 2016-06-08T19:20:44  <gmaxwell> btcdrak: they're not unspendable AFAIK.
477 2016-06-08T19:20:47  <luke-jr> btcdrak: it seems they currently use spendable CHECKMULTISIGs
478 2016-06-08T19:20:50  *** ozanyurt_ has joined #bitcoin-core-dev
479 2016-06-08T19:20:55  <rubensayshi> the bare multisig are spendable btw
480 2016-06-08T19:20:58  <luke-jr> 1-of-2 with the 2nd key up to 500 or so bytes
481 2016-06-08T19:21:07  <gmaxwell> though if they were we should simply filter them out generally.
482 2016-06-08T19:21:07  <rubensayshi> that's the reason to use bare multisig, they're 1-of-3 and the 3rd key is a real key
483 2016-06-08T19:21:34  <rubensayshi> the last resort is pubkeyhash encoding ...
484 2016-06-08T19:21:47  <luke-jr> we could probably enforce a pubkey format for bare multisig even when they're enabled, but nobody afaik is legitimately using it, so might as well just disable it by default
485 2016-06-08T19:22:05  <btcdrak> gmaxwell: pubkeyhash encoding is unspendable afaik
486 2016-06-08T19:22:22  <luke-jr> pubkeyhash encoding can't do >80 bytes anyway?
487 2016-06-08T19:22:27  <rubensayshi> yea
488 2016-06-08T19:22:31  <rubensayshi> 100s of outputs ...
489 2016-06-08T19:22:33  <luke-jr> -.-
490 2016-06-08T19:22:35  <rubensayshi> all unspendable
491 2016-06-08T19:22:55  <luke-jr> sigh, maybe we really do need p2sh^2 sooner rather than later
492 2016-06-08T19:23:05  <rubensayshi> the bare multisig was perfect tbh, because we could clean the outputs
493 2016-06-08T19:23:17  <btcdrak> it really is about the lesser of the evils. I would say a slightly larger OP_RETURN is preferable than unspendable junk
494 2016-06-08T19:23:24  <rubensayshi> as a fallback to opreturn that is
495 2016-06-08T19:23:29  <luke-jr> [19:18:46] <luke-jr> rubensayshi: is there a good way we could teach Core to identify CP OP_RETURN separate from spam OP_RETURN, so we can allow longer lengths for CP only?
496 2016-06-08T19:23:30  <gmaxwell> rubensayshi: you should have your own network, and stop storing data unrelated to bitcoin in the bitcoin network.
497 2016-06-08T19:23:47  *** ozanyurt has quit IRC
498 2016-06-08T19:23:48  <gmaxwell> The OP_RETURN as standard facility was intended to store _commitments_ not data.
499 2016-06-08T19:23:58  <rubensayshi> luke-jr, is there a way you won't change that to drop all of them the next release xD?
500 2016-06-08T19:24:23  <rubensayshi> gmaxwell, I'm just a script kiddie who dropped by a project that needed some work and sounded fun to do
501 2016-06-08T19:24:37  <rubensayshi> I didn't come up with this stuff xD
502 2016-06-08T19:24:39  <gmaxwell> rubensayshi: :)
503 2016-06-08T19:24:43  <btcdrak> :D
504 2016-06-08T19:24:43  <rubensayshi> I just get the bug reports
505 2016-06-08T19:24:46  <gmaxwell> rubensayshi: but you could help rescue it. :)
506 2016-06-08T19:24:53  <gmaxwell> Dare to dream.
507 2016-06-08T19:25:01  <btcdrak> sidechains...
508 2016-06-08T19:25:21  <rubensayshi> hehe
509 2016-06-08T19:25:40  <gmaxwell> it's not even a 'sidechain'-- it's a seperate currency/asset tracking network. :)
510 2016-06-08T19:25:45  *** mkarrer has joined #bitcoin-core-dev
511 2016-06-08T19:25:53  <luke-jr> rubensayshi: believe it or not, the 0.12 thing was an accident in affecting CP
512 2016-06-08T19:26:21  <gmaxwell> indeed, that wasn't intended. if we had intended to block CP then it would be blocked completely.
513 2016-06-08T19:26:25  <rubensayshi> I gave you the benefit of doubt luke-jr, but not having any tests for it makes it look funky (I'll write some tests 2morrow for it!)
514 2016-06-08T19:26:41  <adiabat> is there a recommended / reliable way to put this data in the witness stack?
515 2016-06-08T19:26:56  <adiabat> it'd be nicer to have it there instead of in an OP_RETURN
516 2016-06-08T19:26:57  <rubensayshi> would that be better?
517 2016-06-08T19:27:17  <luke-jr> adiabat: it's probably better in OP_RETURN tbh
518 2016-06-08T19:27:21  <gmaxwell> adiabat: it's not under a signature there, so it can be stripped in relay, unfortunately.
519 2016-06-08T19:27:28  <adiabat> yeah...
520 2016-06-08T19:27:36  <gmaxwell> There is no good place to store arbritary data, unfortunately.
521 2016-06-08T19:27:48  <adiabat> you'd have to put like a hash of it in the output script, then put your 520 byte preimage in the witness
522 2016-06-08T19:27:50  <rubensayshi> op_drop?
523 2016-06-08T19:27:55  <luke-jr> gmaxwell: Factom! :P
524 2016-06-08T19:27:58  *** Chris_Stewart_5 has quit IRC
525 2016-06-08T19:27:58  <adiabat> heh
526 2016-06-08T19:28:05  <gmaxwell> except via a _commitment_ in op_return and the data elsewhere, which was already whas op_return as standard was supposted to be.
527 2016-06-08T19:28:08  <adiabat> op_2drop is even more efficient :)
528 2016-06-08T19:28:41  <rubensayshi> if all my addresses would be P2SH I could put it in the scriptSig with an op_drop no?
529 2016-06-08T19:28:43  *** grubles_ is now known as grubles
530 2016-06-08T19:28:53  <gmaxwell> The problem with op_return is that the data still ends up in prued-nowit-sync and in SPV scans.  The problem with putting it in the witness is that it's not signed.
531 2016-06-08T19:29:08  <gmaxwell> rubensayshi: sure you can, but any joker can strip it out of the transactions as they go past.
532 2016-06-08T19:29:09  <adiabat> at some point someone should make like a p2pool backed merkle-branch-service
533 2016-06-08T19:29:23  <rubensayshi> ah right
534 2016-06-08T19:30:05  <adiabat> ~most of the data on the segnet4 blockchain is op_2drop witness items
535 2016-06-08T19:30:12  <adiabat> nobody modified any of them :)
536 2016-06-08T19:30:58  <gmaxwell> I think we should add some 'notes' facility, where people can publish data into a DHT(spit) with access rate limited by ownership of stationary txouts.  Then if they want commitments in op-returns great. We'd hoped people would build this for themselves, but building complex infrastructure isn't something many people do when there is a speculative asset they could be pumping instead.
537 2016-06-08T19:31:15  <gmaxwell> adiabat: thats been done, it was called chronobit.
538 2016-06-08T19:31:37  <gmaxwell> adiabat: yea, sure lots of things work for a while. :)
539 2016-06-08T19:31:43  <adiabat> huh!  look at that.  and people use op_return instead...
540 2016-06-08T19:31:48  <luke-jr> gmaxwell: the hard part there is proving ownership
541 2016-06-08T19:32:13  <gmaxwell> luke-jr: you just write a non-minable transaction to perform your insert.
542 2016-06-08T19:32:28  <luke-jr> gmaxwell: that involves key reuse :<
543 2016-06-08T19:32:41  <gmaxwell> adiabat: utter refusal to use anything except the simplest possible thing. "This is why we can't have nice things".
544 2016-06-08T19:32:47  <gmaxwell> luke-jr: so? not in a way that matters.
545 2016-06-08T19:33:05  <gmaxwell> Key reuse isn't inherently bad. Reusing in dumb ways is.
546 2016-06-08T19:33:34  <gmaxwell> If your alternative was to transact; then signmessaging is stricly superior.
547 2016-06-08T19:33:35  *** ozanyurt_ has quit IRC
548 2016-06-08T19:33:40  <adiabat> oh, semi-unrelated but, gmaxwell: remember the "bloom filter digest" post about a month ago on the mailing list
549 2016-06-08T19:33:42  <luke-jr> there is zero risk of QC ever?
550 2016-06-08T19:33:53  <adiabat> and you said, since you're not updating, there's better structures than bloom filters
551 2016-06-08T19:34:03  <gmaxwell> luke-jr: it doesn't change anything wrt QC when your alternative was just transacting!
552 2016-06-08T19:34:25  <luke-jr> transacting doesn't leave coins on the key ;)
553 2016-06-08T19:34:28  <gmaxwell> adiabat: yes.
554 2016-06-08T19:34:53  <adiabat> gmaxwell: Do you know if anyone's working on that, or a BIP or anything?  It looked like it was from a troll account...
555 2016-06-08T19:35:09  <gmaxwell> I don't think anyone is working on it right now.
556 2016-06-08T19:35:12  <adiabat> I don't really want to commit to like "I'll work on that" because I might not have time but...
557 2016-06-08T19:35:27  <adiabat> it seems so much nicer than the current merkle block stuff
558 2016-06-08T19:35:37  <gmaxwell> adiabat: well would be good for you to, and if other people show up I can point them at you.
559 2016-06-08T19:35:47  *** ozanyurt has joined #bitcoin-core-dev
560 2016-06-08T19:35:49  <luke-jr> a better way IMO would be to use sign-to-contract to commit to another key, and use that key to sign the DHT publication
561 2016-06-08T19:35:59  <gmaxwell> TBH, I'm a bit afraid to work on technology that I really like right now, because it'll just get attacked because I like it. :(
562 2016-06-08T19:36:27  <AaronvanW> "Do you guys know what the the latest up to date spec for stealth addresses is?" (asking for someone... who is asking for me.)
563 2016-06-08T19:36:31  <gmaxwell> luke-jr: but then access to publish is people who don't have bitcoins anymore which would be kinda odd. :)
564 2016-06-08T19:36:41  <adiabat> gmaxwell: heh yeah... do you have any links to the more efficient filters, like the binomial codec you linked to?
565 2016-06-08T19:37:04  <luke-jr> gmaxwell: contracthash then? :P
566 2016-06-08T19:37:53  *** grubles is now known as dingus
567 2016-06-08T19:38:06  <gmaxwell> adiabat: well the more efficient filter is just like a bloom but with a single hash function and large number of candidate positions, and then you compress the result, using your choice of optimal compressor for cases where the probablity of a 1 is very low
568 2016-06-08T19:38:18  <gmaxwell> luke-jr: doesn't achieve your goal.
569 2016-06-08T19:38:34  <luke-jr> hm
570 2016-06-08T19:39:17  <gmaxwell> I wish I never pointed out that the use of hashed keys might harden a little against QC, it's vastly overestimated in performance. If we think that is at all a threat we need to be urgently migrating to secure schemes.
571 2016-06-08T19:39:21  <luke-jr> MAST with a branch for payment vs message vs DHT-message :P
572 2016-06-08T19:40:13  <gmaxwell> adiabat: So, for example, a simple range coder would work. rice coding might be reasonably efficient, or things like the binomial codec I linked to.
573 2016-06-08T19:40:29  <gmaxwell> luke-jr: cute.
574 2016-06-08T19:40:33  <adiabat> gmaxwell: so maybe start with the current murmur hash, and look at different compression encodings?
575 2016-06-08T19:40:35  <luke-jr> gmaxwell: I consider it a useful property in that it doesn't cause QCs to take all old coins not being spent immediately. It does that, at least, no?
576 2016-06-08T19:40:58  <gmaxwell> adiabat: or siphash 1-3.     Yes, thats possible.
577 2016-06-08T19:41:46  <gmaxwell> adiabat: another newly trendy kind of data structure for this is a cuckoo filter, though for ideal use here you'd also need to compress it, though the compression could be simpler.
578 2016-06-08T19:42:05  <gmaxwell> it might work better simply because it will be smaller in memory when matching.
579 2016-06-08T19:42:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
580 2016-06-08T19:42:18  <adiabat> gmaxwell: OK thanks, will look into it.  Probably can't work on it much, but it doesn't *feel* that hard... in fact feels simpler than the current merkle-blocks and then send txs stuff
581 2016-06-08T19:42:45  <gmaxwell> Yes, it's simpler. I think fully elaborated out you could go very deep down a rabbit hole, but the basic idea is simple.
582 2016-06-08T19:43:32  <adiabat> gmaxwell: the main design tradeoff seems to be the size of the block digest.  Too small and lots of false positives and people have to download lots of blocks.  Too big and you're spending a lot of space on the digest.
583 2016-06-08T19:43:36  <gmaxwell> A cool thing about it is that it could be used before being commited, so people could try many different designs and explore the solution space pretty far.
584 2016-06-08T19:44:05  <adiabat> yeah, could implement it on the p2p layer without any consensus changes
585 2016-06-08T19:44:22  <gmaxwell> well you can also do things like multiple tiers, like a digest covering groups of 8 blocks, and a digest covering single blocks.. even digests covering parts of blocks.
586 2016-06-08T19:44:23  <adiabat> and the node could lie to you, but they can do that right now with bloom filters anyway
587 2016-06-08T19:45:18  <adiabat> also feels like maybe a perverse incentive would be that you'd not want to make as many new addresses, as your false positive rate would go up and you'd have to download more...
588 2016-06-08T19:45:50  <gmaxwell> the current system has that issue, these commited schemes have less of it.
589 2016-06-08T19:46:18  <adiabat> yeah, basically nothing about it seems any *worse* than the current filter system
590 2016-06-08T19:47:05  <gmaxwell> There are other totally different alternatives though, like PIR scan services, which I think we almost have enough in bitcoin core to support as a purely external add on.
591 2016-06-08T19:48:01  <adiabat> PIR scans would be better but also seems more complex...
592 2016-06-08T19:48:39  <gmaxwell> much more complex, though a lot of the heavy lifting has been done by other people (percy++)
593 2016-06-08T19:48:46  <adiabat> not that people shouldn't do it, but I feel like I could reasonably get a block digest to work, but getting a PIR system seems more .. innovative :)
594 2016-06-08T19:49:06  <gmaxwell> hah
595 2016-06-08T19:49:19  <gmaxwell> I only bring it up in the hope that someone will be foolish enough to think it easy.
596 2016-06-08T19:49:48  <gmaxwell> Though actually I think they're more similar in difficulty than you think... in both cases the details are what get you.
597 2016-06-08T19:50:20  <adiabat> yeah, I guess with the digest, you can get something working even if the details are wrong and it works sub-optimally
598 2016-06-08T19:50:43  <adiabat> with PIR, well... I guess you wouldn't really know if it was horribly broken and revealed everything that you were requesting
599 2016-06-08T19:51:51  <gmaxwell> PIR is straight forward: there is existing software that lets you have a {key, value} database and query it privately.  Take the existing utxo set, order by address, for every txout for each address, generate a txout proof (gettxoutproof rpc), for it. ... now thats your database.  People query it with each of there addresses, and import the results into the wallet after verifying the proofs. Tad
600 2016-06-08T19:51:57  <gmaxwell> a.
601 2016-06-08T19:52:19  <gmaxwell> The reality is less simple, because different addresses have (vastly) different numbers of txouts connected with them.. so you have to have some way of handling it.
602 2016-06-08T19:53:09  <gmaxwell> Probably the thing to do is take all the txouts for each address and make the keys  key, key_2, key_3, key_4... for each of them.  and have the first key tell you how many txouts there are in total.
603 2016-06-08T19:53:44  <gmaxwell> Though that still will have some inefficiency since the txoutproof has the whole transaction paying you in it, so they'd all need to be padded up to a constant (large size).
604 2016-06-08T19:54:03  <gmaxwell> and maybe the inefficiency of all that makes it unreasonable to use.
605 2016-06-08T19:55:06  <adiabat> yeah... also percy++ looks a little scary to work with in that I don't think there's a lot of real world implementations using it right now
606 2016-06-08T19:56:25  <adiabat> wheras the block digest idea just jumps out as like "Oh yeah that'll work!"
607 2016-06-08T19:56:27  <gmaxwell> Right.  Well most people have no desire,  "keep user data private? but then how will we sell it?" :)  a positive point is that the academics working on it are actually competent programmers too (not always the case)... so I think it's likely to not be a software engineering disaster (and it's always worked right when I've messed around with it)
608 2016-06-08T19:56:38  *** cryptapus has quit IRC
609 2016-06-08T19:57:10  <adiabat> yeah I looked at percy++ a year or two ago and it does seem to be well made
610 2016-06-08T19:57:18  <gmaxwell> adiabat: indeed, it will, though less private!  it's also not exclusive with using PIR.. a simpler way to use PIR would be to use it to fetch the whole blocks you're going to fetch.
611 2016-06-08T19:58:27  <adiabat> I guess I'm also not just looking at it from a privacy perspective, though that's a big part of it
612 2016-06-08T19:58:41  <gmaxwell> ::nods::
613 2016-06-08T19:58:46  <adiabat> with LN channels, a false negative can be a big problem
614 2016-06-08T19:58:51  <gmaxwell> the existing bloom stuff is just broken on a bunch of levels.
615 2016-06-08T19:59:29  <adiabat> yeah, if the node you're asking to filter for you omits the tx where someone closes a channel incorrectly, you might not know and lose coins
616 2016-06-08T19:59:41  <gmaxwell> it's vulnerable to attack both from data hiding and from denial of service, its resource intensive, .. strongly discourages  single use addresses.. quite non-private...
617 2016-06-08T19:59:58  <adiabat> oh and the merkle-block data structure is... weird...
618 2016-06-08T20:00:07  <adiabat> and then it sends the txs, unrequested
619 2016-06-08T20:00:57  <_anthony_> bitcoin satellites are definitely the way to go
620 2016-06-08T20:01:08  <gmaxwell> yea, a side effect of the bitcoin protocol having no mechensim to just fetch txn already in blocks, which has a good reason for it (among other things, it helps keep the network from being abused as a file trading DHT)
621 2016-06-08T20:01:39  <gmaxwell> BIP152 actually adds a sutiable mechenism-- getblocktxn that fetches txn in a block by index, that only works for recent blocks.
622 2016-06-08T20:05:11  *** molz has joined #bitcoin-core-dev
623 2016-06-08T20:07:18  *** moli has quit IRC
624 2016-06-08T20:08:12  *** Squidicc has quit IRC
625 2016-06-08T20:11:32  <sipa> my train internet connection is too weak to actually visit github.com, but can someone see if https://github.com/sipa/bitcoin/commits/dogcgit renerders nicely?
626 2016-06-08T20:15:23  <gmaxwell> sipa: 404.
627 2016-06-08T20:15:41  <paveljanik> sipa, yes, looks nice - https://github.com/bitcoin/bitcoin/compare/master...sipa:docgit
628 2016-06-08T20:15:58  <gmaxwell> https://github.com/sipa/bitcoin/commits/docgit maybe
629 2016-06-08T20:20:29  <sipa> yes indeed; thanks!
630 2016-06-08T20:21:46  <GitHub146> [bitcoin] kazcw opened pull request #8177: developer notes: deprecate C-style casts (master...no-c-casts) https://github.com/bitcoin/bitcoin/pull/8177
631 2016-06-08T20:35:42  *** moli has joined #bitcoin-core-dev
632 2016-06-08T20:38:20  *** molz has quit IRC
633 2016-06-08T21:02:45  *** adiabat has quit IRC
634 2016-06-08T21:16:25  *** cryptapus has joined #bitcoin-core-dev
635 2016-06-08T21:23:15  *** cryptapus has quit IRC
636 2016-06-08T21:26:49  *** JackH has quit IRC
637 2016-06-08T21:40:38  *** supasonic has joined #bitcoin-core-dev
638 2016-06-08T21:42:03  <luke-jr> can someone reopen https://github.com/bitcoin/bitcoin/pull/5872 so I can push to it (addressing unreviewability concerns)?
639 2016-06-08T22:31:29  *** xiangfu has joined #bitcoin-core-dev
640 2016-06-08T22:32:01  <frankenmint> heh, rusty russel also invented modprobe
641 2016-06-08T22:32:20  *** Guyver2 has quit IRC
642 2016-06-08T22:32:35  <gmaxwell> Someday we'll forgive him.
643 2016-06-08T22:41:28  <luke-jr> XD
644 2016-06-08T22:41:31  <sipa> and if not, we'll xkcd538 him with a 5 AUD rusty wrench
645 2016-06-08T22:41:45  <luke-jr> sipa: ^ 1 hr ago
646 2016-06-08T22:42:34  <GitHub126> [bitcoin] sipa reopened pull request #5872: configure: BITCOIN_SUBDIR_TO_INCLUDE: Improve compatibility with paths including space and multiline cpp output (master...subdir_incl_compat) https://github.com/bitcoin/bitcoin/pull/5872
647 2016-06-08T22:42:37  <luke-jr> thx
648 2016-06-08T22:44:58  <luke-jr> hopefully that's finally reviewable
649 2016-06-08T22:48:30  *** mkarrer has quit IRC
650 2016-06-08T22:50:06  *** mkarrer has joined #bitcoin-core-dev
651 2016-06-08T22:51:55  <sipa> luke-jr: i'm not sure i understand the problem it os trying to address
652 2016-06-08T22:51:59  <sipa> you say it is biggy
653 2016-06-08T22:52:04  *** supasonic has quit IRC
654 2016-06-08T22:52:08  <sipa> how does that manifest?
655 2016-06-08T22:53:57  <luke-jr> sipa: I think mostly paths with spaces failing
656 2016-06-08T22:54:24  <sipa> ah
657 2016-06-08T23:06:49  <GitHub106> [bitcoin] sipa opened pull request #8178: Add git and github tips and tricks to developer notes (master...docgit) https://github.com/bitcoin/bitcoin/pull/8178
658 2016-06-08T23:09:33  *** xiangfu has quit IRC
659 2016-06-08T23:16:41  <btcdrak> sipa: more gitfu please
660 2016-06-08T23:17:55  *** xiangfu has joined #bitcoin-core-dev