1 2017-05-18T00:00:35  *** niska has quit IRC
  2 2017-05-18T00:00:51  *** abpa has quit IRC
  3 2017-05-18T00:03:28  *** Giszmo has quit IRC
  4 2017-05-18T00:04:23  *** Giszmo has joined #bitcoin-core-dev
  5 2017-05-18T00:05:30  *** niska has joined #bitcoin-core-dev
  6 2017-05-18T00:12:23  *** harrymm has joined #bitcoin-core-dev
  7 2017-05-18T00:12:56  *** harrymm has joined #bitcoin-core-dev
  8 2017-05-18T00:14:43  <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bee35299716c...e317c0d19201
  9 2017-05-18T00:14:44  <bitcoin-git> bitcoin/master 9f7341b Gregory Sanders: Add witness data output to TxInError messages
 10 2017-05-18T00:14:44  <bitcoin-git> bitcoin/master 6e9e026 Gregory Sanders: Expand signrawtransaction.py to cover error witness checking
 11 2017-05-18T00:14:45  <bitcoin-git> bitcoin/master e317c0d Pieter Wuille: Merge #8384: Add witness data output to TxInError messages...
 12 2017-05-18T00:23:08  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e317c0d19201...c33652576ce2
 13 2017-05-18T00:23:08  <bitcoin-git> bitcoin/master 1b936f5 practicalswift: Replace boost::function with std::function (C++11)
 14 2017-05-18T00:23:09  <bitcoin-git> bitcoin/master c336525 Pieter Wuille: Merge #10395: Replace boost::function with std::function (C++11)...
 15 2017-05-18T00:23:38  <bitcoin-git> [bitcoin] sipa closed pull request #10395: Replace boost::function with std::function (C++11) (master...replace-boost-function) https://github.com/bitcoin/bitcoin/pull/10395
 16 2017-05-18T00:28:11  *** goksinen has joined #bitcoin-core-dev
 17 2017-05-18T00:28:22  *** kadoban_ has joined #bitcoin-core-dev
 18 2017-05-18T00:28:29  *** kadoban has quit IRC
 19 2017-05-18T00:28:53  *** sipa has joined #bitcoin-core-dev
 20 2017-05-18T00:34:34  *** goksinen has quit IRC
 21 2017-05-18T00:36:53  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c33652576ce2...ae786098bc58
 22 2017-05-18T00:36:53  <bitcoin-git> bitcoin/master ad415bc Thomas Snider: [net] Added SetSocketNoDelay() utility function
 23 2017-05-18T00:36:54  <bitcoin-git> bitcoin/master ae78609 Pieter Wuille: Merge #10061: [net] Added SetSocketNoDelay() utility function...
 24 2017-05-18T00:37:15  <bitcoin-git> [bitcoin] sipa closed pull request #10061: [net] Added SetSocketNoDelay() utility function (master...tjps_nodelay) https://github.com/bitcoin/bitcoin/pull/10061
 25 2017-05-18T00:38:27  <bitcoin-git> [bitcoin] sipa closed pull request #8952: Add query options to listunspent RPC call (master...enhancement/improve-rpc-listunspent) https://github.com/bitcoin/bitcoin/pull/8952
 26 2017-05-18T00:41:15  *** Ylbam has quit IRC
 27 2017-05-18T00:44:32  *** Aaronvan_ has quit IRC
 28 2017-05-18T00:45:05  *** AaronvanW has joined #bitcoin-core-dev
 29 2017-05-18T00:47:26  *** Giszmo has quit IRC
 30 2017-05-18T00:47:56  *** zooko has joined #bitcoin-core-dev
 31 2017-05-18T00:48:09  *** justanotheruser has quit IRC
 32 2017-05-18T00:49:27  *** AaronvanW has quit IRC
 33 2017-05-18T00:51:10  *** justanotheruser has joined #bitcoin-core-dev
 34 2017-05-18T00:52:09  *** goksinen has joined #bitcoin-core-dev
 35 2017-05-18T00:56:27  *** goksinen has quit IRC
 36 2017-05-18T01:05:50  *** Giszmo has joined #bitcoin-core-dev
 37 2017-05-18T01:12:08  *** goksinen has joined #bitcoin-core-dev
 38 2017-05-18T01:17:47  *** AaronvanW has joined #bitcoin-core-dev
 39 2017-05-18T01:17:47  *** AaronvanW has joined #bitcoin-core-dev
 40 2017-05-18T01:22:08  *** AaronvanW has quit IRC
 41 2017-05-18T01:30:27  <bitcoin-git> [bitcoin] theuni closed pull request #10285: net: refactor the connection process. moving towards async connections. (master...connman-events6) https://github.com/bitcoin/bitcoin/pull/10285
 42 2017-05-18T01:34:55  *** zooko has quit IRC
 43 2017-05-18T01:37:22  *** Squidicuz has joined #bitcoin-core-dev
 44 2017-05-18T01:38:39  *** Squidicc has quit IRC
 45 2017-05-18T01:39:44  *** Squidicc has joined #bitcoin-core-dev
 46 2017-05-18T01:39:58  *** owowo has quit IRC
 47 2017-05-18T01:41:43  *** owowo has joined #bitcoin-core-dev
 48 2017-05-18T01:42:09  *** Squidicuz has quit IRC
 49 2017-05-18T01:42:27  *** Squidicuz has joined #bitcoin-core-dev
 50 2017-05-18T01:45:09  *** Squidicc has quit IRC
 51 2017-05-18T01:49:28  *** Squidicuz has quit IRC
 52 2017-05-18T01:50:26  *** Squidicuz has joined #bitcoin-core-dev
 53 2017-05-18T01:50:52  *** bitcoinreminder_ has joined #bitcoin-core-dev
 54 2017-05-18T01:50:59  *** Squidicuz has quit IRC
 55 2017-05-18T01:54:39  *** Dyaheon has quit IRC
 56 2017-05-18T01:57:38  *** Dyaheon has joined #bitcoin-core-dev
 57 2017-05-18T02:00:11  *** dermoth has quit IRC
 58 2017-05-18T02:01:04  *** dermoth has joined #bitcoin-core-dev
 59 2017-05-18T02:08:56  *** zooko has joined #bitcoin-core-dev
 60 2017-05-18T02:23:31  *** kadoban_ is now known as kadoban
 61 2017-05-18T02:32:14  *** cysm_ has quit IRC
 62 2017-05-18T02:34:13  *** goksinen has quit IRC
 63 2017-05-18T02:34:42  *** goksinen has joined #bitcoin-core-dev
 64 2017-05-18T02:37:23  *** cysm_ has joined #bitcoin-core-dev
 65 2017-05-18T03:09:09  *** spinza has quit IRC
 66 2017-05-18T03:16:11  *** zooko has quit IRC
 67 2017-05-18T03:18:11  *** zooko has joined #bitcoin-core-dev
 68 2017-05-18T03:36:44  *** dermoth has quit IRC
 69 2017-05-18T03:54:10  *** Victor_sueca has joined #bitcoin-core-dev
 70 2017-05-18T03:56:57  *** Victorsueca has quit IRC
 71 2017-05-18T03:57:11  *** zooko has quit IRC
 72 2017-05-18T04:05:39  *** spinza has joined #bitcoin-core-dev
 73 2017-05-18T04:17:13  *** bitcoinreminder_ has quit IRC
 74 2017-05-18T04:18:22  *** Giszmo has quit IRC
 75 2017-05-18T04:50:27  <bitcoin-git> [bitcoin] laanwj closed pull request #10417: BIP 148 support (master...master-BIP148) https://github.com/bitcoin/bitcoin/pull/10417
 76 2017-05-18T04:57:11  *** juscamarena_ has quit IRC
 77 2017-05-18T05:01:49  *** juscamarena_ has joined #bitcoin-core-dev
 78 2017-05-18T05:25:21  *** LeMiner has quit IRC
 79 2017-05-18T05:25:34  <paveljanik> ... the first night when my IRC log buffer doesn't show the whole night communication...
 80 2017-05-18T05:25:59  <paveljanik> and more over it even rolled out my TODOs 8)
 81 2017-05-18T05:28:19  *** LeMiner has joined #bitcoin-core-dev
 82 2017-05-18T05:37:48  *** Dyaheon has quit IRC
 83 2017-05-18T05:38:52  *** Dyaheon has joined #bitcoin-core-dev
 84 2017-05-18T05:44:36  * wumpus made some people really angry
 85 2017-05-18T05:46:47  *** cryptapus_afk has quit IRC
 86 2017-05-18T05:49:51  *** goksinen has joined #bitcoin-core-dev
 87 2017-05-18T05:50:52  *** goksinen has joined #bitcoin-core-dev
 88 2017-05-18T05:51:59  <jcorgan> it think we need CAPRs (Contributor Activated Pull Requests) :-)
 89 2017-05-18T05:54:18  <wumpus> heh
 90 2017-05-18T05:54:57  *** goksinen has quit IRC
 91 2017-05-18T06:27:59  *** justan0theruser has joined #bitcoin-core-dev
 92 2017-05-18T06:28:22  *** Ylbam has joined #bitcoin-core-dev
 93 2017-05-18T06:30:27  *** justanotheruser has quit IRC
 94 2017-05-18T06:51:40  *** paveljanik has quit IRC
 95 2017-05-18T06:54:20  *** BashCo has quit IRC
 96 2017-05-18T07:10:24  *** AaronvanW has joined #bitcoin-core-dev
 97 2017-05-18T07:10:28  *** AaronvanW has joined #bitcoin-core-dev
 98 2017-05-18T07:11:13  *** AaronvanW has quit IRC
 99 2017-05-18T07:11:48  *** AaronvanW has joined #bitcoin-core-dev
100 2017-05-18T07:11:48  *** AaronvanW has joined #bitcoin-core-dev
101 2017-05-18T07:16:35  *** BashCo has joined #bitcoin-core-dev
102 2017-05-18T07:23:57  *** tripleslash has quit IRC
103 2017-05-18T07:26:05  *** jtimon has quit IRC
104 2017-05-18T07:27:29  *** tripleslash has joined #bitcoin-core-dev
105 2017-05-18T07:38:07  *** cryptapus_afk has joined #bitcoin-core-dev
106 2017-05-18T07:45:09  *** cryptapus_afk has quit IRC
107 2017-05-18T07:52:18  *** Victor_sueca is now known as Victorsueca
108 2017-05-18T07:53:00  <bitcoin-git> [bitcoin] practicalswift opened pull request #10419: [trivial] Fix two recently introduced typos (master...typos-201705) https://github.com/bitcoin/bitcoin/pull/10419
109 2017-05-18T07:56:43  *** tripleslash has quit IRC
110 2017-05-18T07:58:11  *** tripleslash has joined #bitcoin-core-dev
111 2017-05-18T08:09:42  *** jannes has joined #bitcoin-core-dev
112 2017-05-18T08:09:55  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/ae786098bc58...2acface32aba
113 2017-05-18T08:09:56  <bitcoin-git> bitcoin/master 64aa36e ロハン ダル: param variables made const
114 2017-05-18T08:09:56  <bitcoin-git> bitcoin/master d60d54d ロハン ダル: merge with bitcoin core
115 2017-05-18T08:09:57  <bitcoin-git> bitcoin/master 2acface Wladimir J. van der Laan: Merge #9750: Bloomfilter: parameter variables made constant...
116 2017-05-18T08:10:10  <bitcoin-git> [bitcoin] laanwj closed pull request #9750: Bloomfilter: parameter variables made constant (master...bloomVar) https://github.com/bitcoin/bitcoin/pull/9750
117 2017-05-18T08:10:29  *** fanquake has joined #bitcoin-core-dev
118 2017-05-18T08:13:40  <fanquake> What we really need is a bot that picks out every typo, spurious include and incorrect space from every new PR, and embarrassingly notifies the contributor of their transgression
119 2017-05-18T08:13:53  <fanquake>  /s
120 2017-05-18T08:14:17  <wumpus> in triplicate, of course
121 2017-05-18T08:15:38  <wumpus> for typos in translation strings it could even be useful
122 2017-05-18T08:15:43  <wumpus> but in comments, bleh
123 2017-05-18T08:16:16  <wumpus> especially if the gist of the word is clear anyway
124 2017-05-18T08:29:25  *** lichtamberg_ has joined #bitcoin-core-dev
125 2017-05-18T08:29:39  *** Dyaheon has quit IRC
126 2017-05-18T08:29:43  *** bitcoinreminder_ has joined #bitcoin-core-dev
127 2017-05-18T08:30:17  *** Dyaheon has joined #bitcoin-core-dev
128 2017-05-18T08:35:14  *** timothy has joined #bitcoin-core-dev
129 2017-05-18T09:18:53  <bitcoin-git> [bitcoin] jonasschnelli pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/2acface32aba...962cd3f0587e
130 2017-05-18T09:18:54  <bitcoin-git> bitcoin/master fbf385c Jonas Schnelli: [Qt] simple fee bumper with user verification
131 2017-05-18T09:18:54  <bitcoin-git> bitcoin/master 2ec911f Jonas Schnelli: Add cs_wallet lock assertion to SignTransaction()
132 2017-05-18T09:18:55  <bitcoin-git> bitcoin/master 2678d3d Jonas Schnelli: Show old-fee, increase a new-fee in Qt fee bumper confirmation dialog
133 2017-05-18T09:19:13  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #9697: [Qt] simple fee bumper with user verification (master...2017/02/qt_bumpfee) https://github.com/bitcoin/bitcoin/pull/9697
134 2017-05-18T09:20:19  <jonasschnelli> Added https://github.com/bitcoin/bitcoin/pull/10240 to the "High-priority for review" project
135 2017-05-18T09:26:40  *** lichtamberg_ has quit IRC
136 2017-05-18T09:35:54  *** harrymm has quit IRC
137 2017-05-18T09:36:55  *** lichtamberg_ has joined #bitcoin-core-dev
138 2017-05-18T09:39:18  <timothy> hi, is there a max size for rev*.dat files?
139 2017-05-18T09:40:23  *** Guyver2 has joined #bitcoin-core-dev
140 2017-05-18T09:40:34  <wumpus> timothy: afaik no, the size of the rev depends on what is in the blk*.dat which is size-limited though
141 2017-05-18T09:40:50  <timothy> yes, max size of blk is 128 MiB
142 2017-05-18T09:41:18  <wumpus> I suppose the rev will always be smaller than the blk
143 2017-05-18T09:41:44  <gmaxwell> wumpus: it could be larger if you did something absurd.
144 2017-05-18T09:41:58  <timothy> gmaxwell: absurd like what?
145 2017-05-18T09:42:15  <gmaxwell> wumpus: e.g. say early blocks make zillions of 9999 byte outputs, spendable with OP_TRUE.  then later blocks spend them and do nothing else.
146 2017-05-18T09:42:27  <gmaxwell> That will make the rev data larger than the related blocks.
147 2017-05-18T09:43:01  <timothy> right
148 2017-05-18T09:43:18  <gmaxwell> you could get them up to a ratio of perhaps 230 times larger.
149 2017-05-18T09:44:14  <timothy> still less than 4GB (max file size of FAT32)
150 2017-05-18T09:44:16  <gmaxwell> of course none of these txn would pass standardness tests and what not... not likely to see it in mainnet, but it's possible.
151 2017-05-18T09:44:32  <timothy> uhm no, more than that
152 2017-05-18T09:44:47  <timothy> 30 GB
153 2017-05-18T09:46:36  <wumpus> oh wow that's pretty bad
154 2017-05-18T09:47:25  <wumpus> so I guess ideally the logic should be: if *either* the rev or dat reaches 128MB, roll to the next file
155 2017-05-18T09:51:27  *** JackH has quit IRC
156 2017-05-18T09:52:01  <timothy> is there any reason to use 128 MiB instead of other values?
157 2017-05-18T09:52:36  <gmaxwell> it should be relatively small because it preallocates to reduce fragmentation. (or otherwise windows users cry)
158 2017-05-18T09:52:56  <timothy> NTFS doesn't support fallocate or similar?
159 2017-05-18T09:52:59  <gmaxwell> but not so small that its making a kazillion files and causing poor file system performance.
160 2017-05-18T09:53:18  <timothy> I mean, preallocation without really writing the bytes
161 2017-05-18T09:53:45  <gmaxwell> I long since forgot what the tradeoff surface was on windows.
162 2017-05-18T09:53:56  <gmaxwell> But I didn't think NTFS did sparse files.
163 2017-05-18T09:54:08  <wumpus> I guess it could harmlessly be changed to 256, but I expect there to be no performance gain
164 2017-05-18T09:54:25  <gmaxwell> wumpus: 60 GB rev files! :P
165 2017-05-18T09:54:38  <wumpus> gmaxwell: yeah after rev files capped ofcourse
166 2017-05-18T09:59:02  <wumpus> with a blow-up of 230, at least one block's undo data would fit into that :-)
167 2017-05-18T10:00:32  <gmaxwell> sipa might have more accurate figures on the worst case, but it's something around that much.
168 2017-05-18T10:02:58  <wumpus> "Most modern file systems support sparse files, including most Unix variants and NTFS, but notably not Apple's HFS+. Sparse files are commonly used for disk images, database snapshots, log files and in scientific applications."
169 2017-05-18T10:03:08  <wumpus> so MacOS is the problem here, not windows
170 2017-05-18T10:07:23  *** cryptapus_afk has joined #bitcoin-core-dev
171 2017-05-18T10:10:14  <gmaxwell> The extra question though is if they prevent fragmentation.
172 2017-05-18T10:12:13  <wumpus> I don't know, is there such a guarantee for UNIX filesystems?
173 2017-05-18T10:14:41  <wumpus> oh I was confused, this isn't about sparse files at all but posix_fallocate
174 2017-05-18T10:15:14  <wumpus> in which case the disk space is reserved explicitly
175 2017-05-18T10:15:50  *** Aaronvan_ has joined #bitcoin-core-dev
176 2017-05-18T10:17:30  <gmaxwell> sorry, confusion I caused, late here.
177 2017-05-18T10:17:56  *** AaronvanW has quit IRC
178 2017-05-18T10:18:38  *** chjj has quit IRC
179 2017-05-18T10:19:22  <wumpus> we apparently do have an implementation of AllocateFileRange for windows, but as I understand from MSDN it might create a sparse file (SetEndOfFile sets the file size,but not the "allocation size"), so this confusion is more general :)
180 2017-05-18T10:22:43  <wumpus> the documentation is confusing though so I'm not sure
181 2017-05-18T10:23:45  *** chjj has joined #bitcoin-core-dev
182 2017-05-18T10:23:58  *** mol has joined #bitcoin-core-dev
183 2017-05-18T10:27:04  *** molz_ has quit IRC
184 2017-05-18T10:29:17  *** riemann has joined #bitcoin-core-dev
185 2017-05-18T10:39:33  *** bitcoinreminder_ has quit IRC
186 2017-05-18T10:40:34  *** laurentmt has joined #bitcoin-core-dev
187 2017-05-18T10:44:07  *** laurentmt has quit IRC
188 2017-05-18T11:00:52  *** lichtamberg_ has left #bitcoin-core-dev
189 2017-05-18T11:18:38  *** BashCo has quit IRC
190 2017-05-18T11:19:50  *** BashCo has joined #bitcoin-core-dev
191 2017-05-18T11:22:21  *** laurentmt has joined #bitcoin-core-dev
192 2017-05-18T11:31:11  *** laurentmt has quit IRC
193 2017-05-18T12:16:40  *** jtimon has joined #bitcoin-core-dev
194 2017-05-18T12:35:20  *** str4d has joined #bitcoin-core-dev
195 2017-05-18T12:56:52  *** harrymm has joined #bitcoin-core-dev
196 2017-05-18T12:58:49  *** rgod has joined #bitcoin-core-dev
197 2017-05-18T12:59:49  <bitcoin-git> [bitcoin] fanquake closed pull request #9427: Use compact blocks for blocks that have equal work to our active tip (master...UseCmpctBlockForCompetingBlocks) https://github.com/bitcoin/bitcoin/pull/9427
198 2017-05-18T13:04:17  *** JackH has joined #bitcoin-core-dev
199 2017-05-18T13:58:04  *** paveljanik has joined #bitcoin-core-dev
200 2017-05-18T14:05:35  *** mol has quit IRC
201 2017-05-18T14:06:09  *** moli_ has joined #bitcoin-core-dev
202 2017-05-18T14:08:34  *** str4d has quit IRC
203 2017-05-18T14:14:18  *** goksinen has joined #bitcoin-core-dev
204 2017-05-18T14:15:12  *** fanquake has quit IRC
205 2017-05-18T14:24:05  *** goksinen has quit IRC
206 2017-05-18T14:26:48  *** goksinen has joined #bitcoin-core-dev
207 2017-05-18T14:30:02  <bitcoin-git> [bitcoin] ryanofsky opened pull request #10420: Add Qt tests for wallet spends & bumpfee (master...pr/btest) https://github.com/bitcoin/bitcoin/pull/10420
208 2017-05-18T14:30:54  *** Giszmo has joined #bitcoin-core-dev
209 2017-05-18T14:42:44  *** timothy has quit IRC
210 2017-05-18T14:58:06  *** riemann has quit IRC
211 2017-05-18T15:24:03  *** BartokIT has joined #bitcoin-core-dev
212 2017-05-18T15:24:54  *** zooko has joined #bitcoin-core-dev
213 2017-05-18T15:25:01  *** BartokIT has joined #bitcoin-core-dev
214 2017-05-18T15:27:15  <BartokIT> I want a clarification about the BIP32, is this the correct group
215 2017-05-18T15:31:54  *** mol has joined #bitcoin-core-dev
216 2017-05-18T15:32:55  <BartokIT> The BIP32 allow to audit sharing the master public key
217 2017-05-18T15:33:17  <BartokIT> This is mentioned in the mediawiki
218 2017-05-18T15:35:17  *** moli_ has quit IRC
219 2017-05-18T15:35:37  <BartokIT> But if we use the hardened key this is impossible? Is this wrong?
220 2017-05-18T15:39:48  *** BartokIT has quit IRC
221 2017-05-18T15:46:56  *** abpa has joined #bitcoin-core-dev
222 2017-05-18T15:54:31  *** zooko has quit IRC
223 2017-05-18T15:57:13  *** zooko has joined #bitcoin-core-dev
224 2017-05-18T16:03:31  *** goksinen has quit IRC
225 2017-05-18T16:17:28  *** zooko has quit IRC
226 2017-05-18T16:18:41  *** BashCo has quit IRC
227 2017-05-18T16:19:34  *** zooko has joined #bitcoin-core-dev
228 2017-05-18T16:36:57  <bitcoin-git> [bitcoin] practicalswift opened pull request #10421: [qt] Remove excess logic (master...if-expr-return-true-else-return-false) https://github.com/bitcoin/bitcoin/pull/10421
229 2017-05-18T16:38:38  *** annanay25 has quit IRC
230 2017-05-18T16:38:46  *** annanay25 has joined #bitcoin-core-dev
231 2017-05-18T16:39:44  <bitcoin-git> [bitcoin] morcos opened pull request #10422: Fix timestamp in fee estimate debug message (master...fixtimeunits) https://github.com/bitcoin/bitcoin/pull/10422
232 2017-05-18T16:39:46  *** harrymm has quit IRC
233 2017-05-18T16:40:39  *** BashCo has joined #bitcoin-core-dev
234 2017-05-18T16:42:22  *** harrymm has joined #bitcoin-core-dev
235 2017-05-18T16:51:28  <sipa> wumpus, gmaxwell: the 128 MiB is a tradeoff between fragmentation overhead and granularity for pruning
236 2017-05-18T16:51:49  <sipa> the very first versions of the patch that introduced it (ultraprune) just used a single file per block
237 2017-05-18T16:51:57  <sipa> but that was very slow
238 2017-05-18T16:54:31  <luke-jr> sipa: I wonder if pruning ought to perhaps consider punching sparse holes?
239 2017-05-18T16:54:53  *** SopaXorzTaker has quit IRC
240 2017-05-18T16:55:08  <sipa> luke-jr: i think we can also just reduce that 128MiB number significantly
241 2017-05-18T16:55:25  <morcos> i think 128 works fine for now doesn't it?
242 2017-05-18T16:55:34  <luke-jr> maybe. but some filesystems perform differently than others..
243 2017-05-18T16:55:40  <morcos> perhaps if we properly introduce sharding, then we need to rethink the design
244 2017-05-18T16:55:47  <luke-jr> btrfs is annoyingly slow, I've found.
245 2017-05-18T16:56:04  *** SopaXorzTaker has joined #bitcoin-core-dev
246 2017-05-18T17:03:15  <wumpus> sipa: yes, it seems a good compromise
247 2017-05-18T17:03:55  <wumpus> AFAIK monero stores all blocks in a single lmdb
248 2017-05-18T17:04:09  <wumpus> why reduce the 128? agree with morcosthat it works fine
249 2017-05-18T17:06:36  *** rgod_ has joined #bitcoin-core-dev
250 2017-05-18T17:06:38  <wumpus> for pruning granularity it's also good enough, given how much space the utxo database takes a variance of 128mb+~16mb (usual rev files) doesn't seem to bad
251 2017-05-18T17:07:24  *** rgod has quit IRC
252 2017-05-18T17:14:31  *** laurentmt has joined #bitcoin-core-dev
253 2017-05-18T17:19:31  <wumpus> although it could be worse than that in some cases depending on how blocks are distributed over the files
254 2017-05-18T17:21:38  *** rgod_ has quit IRC
255 2017-05-18T17:27:25  *** laurentmt has quit IRC
256 2017-05-18T17:31:53  <sipa> wumpus: ok
257 2017-05-18T17:49:39  <wumpus> and 128mb is at most 128 blocks, less than a day of blocks, even less than that w/ witness data, it's not that much
258 2017-05-18T17:49:48  *** goksinen has joined #bitcoin-core-dev
259 2017-05-18T17:51:01  *** zooko has quit IRC
260 2017-05-18T17:59:57  <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/962cd3f0587e...28c6e8d71b3a
261 2017-05-18T17:59:58  <bitcoin-git> bitcoin/master d8e03c0 Jack Grigg: torcontrol: Improve comments
262 2017-05-18T17:59:59  <bitcoin-git> bitcoin/master 29f3c20 Jack Grigg: torcontrol: Add unit tests for Tor reply parsers
263 2017-05-18T17:59:59  <bitcoin-git> bitcoin/master d63677b Jack Grigg: torcontrol: Fix ParseTorReplyMapping...
264 2017-05-18T18:00:31  <bitcoin-git> [bitcoin] laanwj closed pull request #10408: Net: Improvements to Tor control port parser (master...torcontrol-parser-patches) https://github.com/bitcoin/bitcoin/pull/10408
265 2017-05-18T18:13:33  <luke-jr> wumpus: it's much more than 128 blocks early in the chain?
266 2017-05-18T18:13:40  <sipa> yes
267 2017-05-18T18:13:57  <wumpus> luke-jr: of course, but it blasts past that anyway
268 2017-05-18T18:14:09  <wumpus> most pruning nodes will be - more or less - up to date
269 2017-05-18T18:20:38  <wumpus> but yes it's easy to forget that once, blocks were that far from full
270 2017-05-18T18:27:08  *** Sprh has joined #bitcoin-core-dev
271 2017-05-18T18:39:36  *** d_t has quit IRC
272 2017-05-18T18:41:45  *** zooko has joined #bitcoin-core-dev
273 2017-05-18T18:51:35  *** MrHodl has joined #bitcoin-core-dev
274 2017-05-18T18:51:36  *** MrHodl has left #bitcoin-core-dev
275 2017-05-18T18:51:41  <bitcoin-git> [bitcoin] instagibbs closed pull request #9102: Really don't validate genesis block (master...dontvalidategenesis) https://github.com/bitcoin/bitcoin/pull/9102
276 2017-05-18T18:55:19  *** SopaXorzTaker has quit IRC
277 2017-05-18T19:01:19  *** Dyaheon has quit IRC
278 2017-05-18T19:01:20  <luke-jr> meeting?
279 2017-05-18T19:01:24  <jonasschnelli> jup
280 2017-05-18T19:01:33  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
281 2017-05-18T19:01:37  <sdaftuar> hello
282 2017-05-18T19:01:41  <instagibbs> here
283 2017-05-18T19:01:41  <CodeShark> hi
284 2017-05-18T19:01:43  <wumpus> #startmeeting
285 2017-05-18T19:01:43  <lightningbot> Meeting started Thu May 18 19:01:43 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
286 2017-05-18T19:01:43  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
287 2017-05-18T19:02:10  <kanzure> hi.
288 2017-05-18T19:02:17  <sipa> yow
289 2017-05-18T19:02:24  *** Dyaheon has joined #bitcoin-core-dev
290 2017-05-18T19:02:26  <cfields> hi
291 2017-05-18T19:02:26  <CodeShark> I just have one topic for today, but I'll let others suggest theirs
292 2017-05-18T19:02:34  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/28c6e8d71b3a...ea6fde3f1d26
293 2017-05-18T19:02:34  <bitcoin-git> bitcoin/master 618d07f Jorge Timón: MOVEONLY: tx functions to consensus/tx_verify.o...
294 2017-05-18T19:02:35  <bitcoin-git> bitcoin/master ea6fde3 Wladimir J. van der Laan: Merge #8329: Consensus: MOVEONLY: Move functions for tx verification...
295 2017-05-18T19:02:39  <wumpus> topics?
296 2017-05-18T19:02:49  <CodeShark> #topic clientside filtering
297 2017-05-18T19:02:55  <jonasschnelli> ack
298 2017-05-18T19:03:26  <luke-jr> BIP148
299 2017-05-18T19:03:33  <luke-jr> (after clientside filtering etc)
300 2017-05-18T19:03:50  <wumpus> I don't think that works CodeShark, I think only the chair can set the topic
301 2017-05-18T19:03:55  <wumpus> #topic clientside filtering
302 2017-05-18T19:03:58  <CodeShark> :)
303 2017-05-18T19:04:19  <CodeShark> so there are several filtering options with different performance tradeoffs
304 2017-05-18T19:04:40  <CodeShark> bloom filters have been typically considered - but there are some other ideas that might be worth considering
305 2017-05-18T19:04:56  <jonasschnelli> Filter for BDF, read gmaxwell's reply: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012637.html
306 2017-05-18T19:05:00  <CodeShark> roasbeef has worked on an idea based on golomb coded sets
307 2017-05-18T19:05:27  <jonasschnelli> «he most efficient data structure is similar to a bloom filter, but you use more bits and only one hash function. The result will be mostly zero bits. Then you entropy code it using RLE+Rice coding or an optimal binomial packer (e.g. https://people.xiph.org/~greg/binomial_codec.c).»
308 2017-05-18T19:05:55  <sipa> yes?
309 2017-05-18T19:05:56  <CodeShark> gcs sacrifices CPU for space
310 2017-05-18T19:06:14  <jonasschnelli> I think what we would need is data about the filter size for the last 100000 blocks...
311 2017-05-18T19:06:16  <CodeShark> filters are smaller, but queries are more computationally expensive
312 2017-05-18T19:06:19  <gmaxwell> CodeShark: CPU for who when is always the question.
313 2017-05-18T19:06:24  <roasbeef> jonasschnelli: I have that
314 2017-05-18T19:06:32  <jonasschnelli> roasbeef: Oo... share?
315 2017-05-18T19:06:33  <CodeShark> hey, roasbeef! :)
316 2017-05-18T19:07:01  <gmaxwell> what BIP37 does is very cpu expensive for the serving party, which is why it leads to dos attacks.
317 2017-05-18T19:07:17  <gmaxwell> with any of the map based proposals that goes away and the cost to construct is not very relevant.
318 2017-05-18T19:07:24  <CodeShark> constructing a gcs isn't very computationally expensive
319 2017-05-18T19:07:38  <sipa> more so than bip37
320 2017-05-18T19:07:43  <gmaxwell> Similarly, cost to lookup is not very relevant, the reciever will decode one per block.
321 2017-05-18T19:07:48  <CodeShark> the queries are a little more computationally expensive than bloom filters, but that is done on client
322 2017-05-18T19:07:51  <roasbeef> jonasschnelli: i have a csv file of stats for the entire chain, can easily get the last 100k out of it, the csv file itself is 14MB
323 2017-05-18T19:07:57  <gmaxwell> sipa: maybe the lots of hash functions make it more expensive than you might guess.
324 2017-05-18T19:08:06  <jonasschnelli> roasbeef: I take the complete one,. thanks. :)
325 2017-05-18T19:08:14  <CodeShark> but gcs only needs to be computed once per block
326 2017-05-18T19:08:29  <sipa> CodeShark: do you suggest this as something that blocks commit to?
327 2017-05-18T19:08:36  <sipa> or something that a full node would precompute and store?
328 2017-05-18T19:08:42  <roasbeef> with bloom filters, there are several hash functions, with the gcs based approach, there's a single hash function. but the set itself is compressed, so you need to decompress as you query
329 2017-05-18T19:08:43  <CodeShark> the latter for starters
330 2017-05-18T19:08:44  <sipa> i suppose the last
331 2017-05-18T19:08:46  <jonasschnelli> precomp and store
332 2017-05-18T19:08:50  <roasbeef> sipe: something a node would precompute and store, to start
333 2017-05-18T19:08:58  <sipa> okay
334 2017-05-18T19:09:19  <sipa> what would be stored in the set?
335 2017-05-18T19:09:23  <gmaxwell> I'm dubious that we'd get state of the art performance from golomb coding, but interested to see.
336 2017-05-18T19:09:26  <jonasschnelli> Can be done after the block has been connected
337 2017-05-18T19:10:04  <gmaxwell> sipa: I believe the discussion is the 'bloom map' proposal.
338 2017-05-18T19:10:13  <CodeShark> roasbeef was suggesting two filters - one for super lightweight clients, another for clients that require more sophisticated queries
339 2017-05-18T19:10:40  <jonasschnelli> What are the differences? The tx template types?
340 2017-05-18T19:10:46  <CodeShark> the former would only encode UTXOs, the latter would also encode witness data
341 2017-05-18T19:10:56  <gmaxwell> encode witness data?!
342 2017-05-18T19:11:16  <CodeShark> well, if you want to query for whether a particular execution path has been taken - necessary for things like lightning
343 2017-05-18T19:11:32  <roasbeef> basic has: outpoints, script data pushes. extended has: witness stack, sig script data pushes, txids
344 2017-05-18T19:11:46  <sipa> but do you need to _search_ based on witness data?
345 2017-05-18T19:11:51  <sipa> i understand you may want to see it
346 2017-05-18T19:12:01  <sipa> but you know what UTXOs to query for, no?
347 2017-05-18T19:12:35  <CodeShark> I'm guessing revocation enforcement might be outsourced to nodes that cannot know the exact transaction format - only some key
348 2017-05-18T19:12:50  <CodeShark> roasbeef, wanna comment?
349 2017-05-18T19:12:53  <gmaxwell> Yes, requesting it is fine, searching on it?  Be careful: it has serious long term implications if you expect that data will even be readily available.  I am doubtful five years from now most nodes will have any witness data from more than a year back.
350 2017-05-18T19:13:22  <gmaxwell> (witness data also means non-utxo transaction data in that above comment)
351 2017-05-18T19:13:54  <gmaxwell> aside, I'm glad to hear this discussion has moved past just replicating the BIP37 mechenism.
352 2017-05-18T19:13:58  <roasbeef> rationale to include witness data was to allow light cleitns to efficielty scan for things like reusable addresses (stealth addresses), i think my model of how folks do that on-chain these days is dated thoughu, i guess they stuff a notification on Op_returns?
353 2017-05-18T19:14:19  <sipa> i'm not sure that is worth the cost
354 2017-05-18T19:14:30  <sipa> also, individual scriptPubKey pushes?
355 2017-05-18T19:14:46  <sipa> if anything, my preference would just be outpoints and full scriptPubKeys
356 2017-05-18T19:14:50  <roasbeef> they do make the extended filters quite a bit bigger (i have testnet data also)
357 2017-05-18T19:14:54  <gmaxwell> well no one does those things in practice, and everyone who previously has implemented them that I'm aware of performed all scanning via a centeralized server, even though they could have matched on the OP_RETURN.
358 2017-05-18T19:15:23  <CodeShark> we can always start with the simplest minimal filter and then add more if we find use cases
359 2017-05-18T19:15:24  <roasbeef> gmaxwell: well the intention was to allow the new light client mode to actually make using them pratcical without delegating to a central server
360 2017-05-18T19:15:41  <gmaxwell> roasbeef: that was already possible with BIP37 and the prior design.
361 2017-05-18T19:15:47  <jonasschnelli> Can we start with adding the same elements that bip37 does?
362 2017-05-18T19:15:48  <roasbeef> sipa: so including the op-codes?
363 2017-05-18T19:16:02  <gmaxwell> Usuabilty of SPV clients that scan using BIP37 is really poor though, thus the rise of electrum.
364 2017-05-18T19:16:04  <sipa> roasbeef: bah, and 1) further encourage op_returns and 2) make them even more expensive for full nodes?
365 2017-05-18T19:16:26  <gmaxwell> jonasschnelli: the things BIP37 added largely turned out to be a mistake that really degraded BIP37 so I hope a new proposal would do less.
366 2017-05-18T19:16:40  <sipa> well the degradation problem doesn't exist here
367 2017-05-18T19:16:47  <sipa> as the filter is not cumulative
368 2017-05-18T19:17:02  <luke-jr> sipa: is there a way to do it without OP_RETURN?
369 2017-05-18T19:17:05  <gmaxwell> yes, but you still need a bigger filter for same FP ratio. It's just less awful. :)
370 2017-05-18T19:17:14  <sipa> luke-jr: sure, payment protocol like systems
371 2017-05-18T19:17:27  <luke-jr> well, true, but then you don't need the crypto stuff for it
372 2017-05-18T19:17:42  <sipa> i think that's a separate discussion and probably not one for here
373 2017-05-18T19:17:48  <luke-jr> k
374 2017-05-18T19:17:58  <CodeShark> for starters we should look at the most basic use cases
375 2017-05-18T19:18:00  <gmaxwell> Yea, we should have a subcommittee. :P
376 2017-05-18T19:18:07  <sipa> jonasschnelli, CodeShark, roasbeef: is there a use case for individual pushes in scriptPubKeys?
377 2017-05-18T19:18:13  <jonasschnelli> the action is probably define a set of filter and create a spec that leaves room for future filter types
378 2017-05-18T19:18:22  <CodeShark> jonasschnelli: indeed
379 2017-05-18T19:18:30  <sipa> especially in a world where everything is P2PKH/P2SH/P2WPKH/P2WSH
380 2017-05-18T19:18:38  <CodeShark> once we have the framework for adding new filters, it should be easy to do
381 2017-05-18T19:18:40  *** ajd_ has joined #bitcoin-core-dev
382 2017-05-18T19:18:43  <gmaxwell> jonasschnelli: multiple filter types can result in n-fold overhead, which will be a significant pressure against defining many.
383 2017-05-18T19:18:47  <roasbeef> sipa: sure, the filter is smaller if one doesn't include the op-code as well
384 2017-05-18T19:19:00  <sipa> roasbeef: eh?
385 2017-05-18T19:19:26  <sipa> i must be misunderstanding something then
386 2017-05-18T19:19:27  <roasbeef> oh you mean insert the _entire_ thing
387 2017-05-18T19:19:36  <sipa> yes, just the whole scriptPubKey
388 2017-05-18T19:19:41  <sipa> 1 element per output
389 2017-05-18T19:19:59  <sipa> well, and another one for the outpoint
390 2017-05-18T19:20:08  <roasbeef> mhmm, only advtange to data pushes in that case is in a world where mbare multi-sig is actually used
391 2017-05-18T19:20:16  <gmaxwell> sipa: wait why?
392 2017-05-18T19:20:23  <sipa> gmaxwell: why what?
393 2017-05-18T19:20:27  <gmaxwell> roasbeef: yes, which we don't expect that world to exist.
394 2017-05-18T19:20:51  <sipa> roasbeef: yes, the reason it's in BIP37 is for bare multisig support... but i don't think that's very interesting now
395 2017-05-18T19:20:52  <gmaxwell> sipa: I expect one insert per output. The scriptpubkey. Why would you insert anything else (for normal functionality)
396 2017-05-18T19:21:01  *** justan0theruser is now known as justanotheruser
397 2017-05-18T19:21:06  <gmaxwell> s/now/ever/ but hindsight is 20/20
398 2017-05-18T19:21:18  <gmaxwell> blockchain isn't a message bus. :P
399 2017-05-18T19:21:19  <sipa> i guess if you want to look for an outpoint, you can always search for its scriptPubKey
400 2017-05-18T19:21:26  <gmaxwell> sipa: right.
401 2017-05-18T19:21:27  <gmaxwell> okay.
402 2017-05-18T19:21:58  <sipa> in BIP37 there was a reason to separate it, as it would be less bandwidth if you wanted a specific coutpoint, despite there being many scriptPubKeys with it
403 2017-05-18T19:22:08  <sipa> but here, that reason doesn't really matter i think?
404 2017-05-18T19:22:30  <sipa> roasbeef: what do you think? just a filter with scriptPubKeys?
405 2017-05-18T19:22:33  <gmaxwell> sipa: the privacy leak from correlated data still exists in map proposals, based on what blocks you choose to scan further, though much less severe than BIP37. Keep that in mind.
406 2017-05-18T19:22:58  <roasbeef> if it's just spk's, then how does one query the filters to see if an outoint has been spent?
407 2017-05-18T19:23:35  <sipa> roasbeef: by querying for the scriptPubKey that outpoint created
408 2017-05-18T19:23:41  <sipa> roasbeef: which you will always know, i think?
409 2017-05-18T19:23:55  <gmaxwell> roasbeef: by looking for its spk.
410 2017-05-18T19:24:09  <roasbeef> sipa: which would require adding parts of the witness/sigScript though?
411 2017-05-18T19:24:14  <sipa> ?
412 2017-05-18T19:24:26  <sipa> i'm confused
413 2017-05-18T19:24:31  <roasbeef> me too :)
414 2017-05-18T19:24:38  <CodeShark> txhash:txindex -> scriptPubKey
415 2017-05-18T19:24:38  <sipa> maybe we should do this outside of the meeting
416 2017-05-18T19:24:39  <gmaxwell> roasbeef: has nothing to do with the witness. You validate the transaction, you know the content of the outpoint.
417 2017-05-18T19:24:51  <sipa> it seems we're doing protocol design here now
418 2017-05-18T19:25:03  <gmaxwell> 12:17 < gmaxwell> Yea, we should have a subcommittee. :P
419 2017-05-18T19:25:17  <CodeShark> anyhow, we don't need to decide the specifics of what goes in the filter right now
420 2017-05-18T19:25:22  <sipa> agree
421 2017-05-18T19:25:27  <roasbeef> ok, sure, to summarize: we have working code for the construction, have nearly finished integrating it into lnd, have a BIP draft that should be ready by next week-ish (will also integrate feedback from thjis discussion)
422 2017-05-18T19:25:31  <CodeShark> I like the idea of creating a framework that allows us to arbitrarily define filters later on
423 2017-05-18T19:25:32  <sipa> i think it's an interesting thing to research further
424 2017-05-18T19:25:41  <sipa> not sure what else needs to be discussed here
425 2017-05-18T19:25:41  <gmaxwell> well we aren't deciding anything right now... :)
426 2017-05-18T19:25:43  <gmaxwell> CodeShark: I do not.
427 2017-05-18T19:26:00  <jonasschnelli> BTW: kallewoof has an draft impl. on serving filters over the p2p (though bloom): https://github.com/kallewoof/bitcoin/pull/1/files (in case someone wants to drive this further)
428 2017-05-18T19:26:05  <gmaxwell> CodeShark: there is an n-fold cost to additional filters. It is unlikely to me that nodes would be willing to carry arbritarily many in the future.
429 2017-05-18T19:26:14  <gmaxwell> CodeShark: there might be a reasonable case for more than one, sure.
430 2017-05-18T19:26:56  <gmaxwell> In any case, I think this is good to open up more discussion and participation.
431 2017-05-18T19:27:09  <gmaxwell> I'm quite happy to hear that there is activity in this area and I'd like to help.
432 2017-05-18T19:27:10  <jonasschnelli> gmaxwell: I see this point but I don't think it would hurt if the specs would allow new filter types
433 2017-05-18T19:27:13  <CodeShark> gmaxwell: point is the code complexity to support adding arbitrary filters isn't that great and it avoids the bikeshed in writing up the initial BIP ;)
434 2017-05-18T19:27:30  <gmaxwell> jonasschnelli: yea sure, whatever, but thats just a type paramter.
435 2017-05-18T19:27:40  <jonasschnelli> gmaxwell: right.
436 2017-05-18T19:28:12  <sipa> end of topic?
437 2017-05-18T19:28:13  * roasbeef now uunderstands what sipa was referring to 
438 2017-05-18T19:28:31  <wumpus> I don't think any other have been proposed?
439 2017-05-18T19:28:47  <gmaxwell> you're gonna regret saying that.. :P
440 2017-05-18T19:29:07  <gmaxwell> quick: high priority PRs.
441 2017-05-18T19:29:09  <wumpus> nearly halfway time
442 2017-05-18T19:29:14  <jonasschnelli> kallewoof had also an approch that peers could serve digests of filters to check the integrity among different peers
443 2017-05-18T19:29:15  <wumpus> #topic high priority PRs
444 2017-05-18T19:29:33  <sipa> small topic for later: bytes_serialized
445 2017-05-18T19:29:34  <gmaxwell> Congrats Morcos on the merge of the new fee estimator stuff.
446 2017-05-18T19:29:43  <jonasschnelli> \o/
447 2017-05-18T19:29:45  <sipa> it will need cleanups, but that's fine
448 2017-05-18T19:29:56  <morcos> thanks, quick PSA..  if you run master now it'll blow away your old fee estimates, you might want to make a copy
449 2017-05-18T19:30:01  <wumpus> quite a few high priority PRs were merged this week, so there's place for new ones, please speak up if there's any that block further work for you
450 2017-05-18T19:30:04  <gmaxwell> "micros" not withstanding.
451 2017-05-18T19:30:17  <morcos> i'm hoping to get an improvment which makes the transition more seamless before 0.15
452 2017-05-18T19:30:46  <sdaftuar> sipa: i'm basically done reviewing per-txout (#10195), looks awesome! running some benchmarks now.
453 2017-05-18T19:30:50  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
454 2017-05-18T19:30:57  <sipa> sdaftuar: thank you so much
455 2017-05-18T19:31:15  <gmaxwell> I've been testing per-txout. Survived a few crashes so far.
456 2017-05-18T19:31:31  <wumpus> I've been testing #10195 for a while, haven't run into any problems
457 2017-05-18T19:31:35  <gribble> https://github.com/bitcoin/bitcoin/issues/10195 | Switch chainstate db and cache to per-txout model by sipa · Pull Request #10195 · bitcoin/bitcoin · GitHub
458 2017-05-18T19:31:35  <instagibbs> morcos, dont look now but it's being used in anger on multiple large wallet services :)
459 2017-05-18T19:31:46  <sipa> instagibbs: "in anger" ?
460 2017-05-18T19:31:55  <instagibbs> "doing it live"
461 2017-05-18T19:32:02  <gmaxwell> "hold my beer"
462 2017-05-18T19:32:30  <morcos> heh.. fools, the whole reason to merge it into master was to get it some more testing
463 2017-05-18T19:32:35  <gmaxwell> luke-jr: have you done the multiwallet rebasing?
464 2017-05-18T19:32:44  <jtimon> there's not many explicit acks on https://github.com/bitcoin/bitcoin/pull/10339
465 2017-05-18T19:32:48  <luke-jr> I didn't realise jtimon's PR was merged?
466 2017-05-18T19:32:49  <instagibbs> morcos, well, other services were doing crazy things.. (ok enough off-topic)
467 2017-05-18T19:33:03  <jtimon> luke-jr: which one?
468 2017-05-18T19:33:05  <wumpus> so, ok, any new ones?
469 2017-05-18T19:33:17  <luke-jr> jtimon: args refactor
470 2017-05-18T19:33:17  <ryanofsky> i'd like more review on #10295, it is blocking my ipc prs
471 2017-05-18T19:33:19  <gribble> https://github.com/bitcoin/bitcoin/issues/10295 | [qt] Move some WalletModel functions into CWallet by ryanofsky · Pull Request #10295 · bitcoin/bitcoin · GitHub
472 2017-05-18T19:33:27  <sipa> ryanofsky: ack, i started reviewing that
473 2017-05-18T19:33:32  <jonasschnelli> I have added #10240 today
474 2017-05-18T19:33:34  <gribble> https://github.com/bitcoin/bitcoin/issues/10240 | Add HD wallet auto-restore functionality by jonasschnelli · Pull Request #10240 · bitcoin/bitcoin · GitHub
475 2017-05-18T19:33:38  <sipa> jonasschnelli: sgtm
476 2017-05-18T19:33:44  <jtimon> luke-jr: I see #9494
477 2017-05-18T19:33:45  <gribble> https://github.com/bitcoin/bitcoin/issues/9494 | Introduce an ArgsManager class encapsulating cs_args, mapArgs and mapMultiArgs by jtimon · Pull Request #9494 · bitcoin/bitcoin · GitHub
478 2017-05-18T19:33:50  <luke-jr> ok, looks like 4 days ago it was; I'll rebase multiwallet then
479 2017-05-18T19:33:55  <sipa> luke-jr: thank you
480 2017-05-18T19:34:02  <jonasschnelli> luke-jr: great. I promise to test
481 2017-05-18T19:34:05  <gmaxwell> luke-jr: thank you!
482 2017-05-18T19:35:02  <jonasschnelli> ryanofsky: will do the 10295 review. Thanks for the info
483 2017-05-18T19:35:07  <sipa> short point: wrt the pruned-node-serving, see http://bitcoin.sipa.be/depths.png
484 2017-05-18T19:35:11  <wumpus> added 10295  and 10339
485 2017-05-18T19:35:21  *** stickcuck has joined #bitcoin-core-dev
486 2017-05-18T19:35:22  <wumpus> #topic pruned-node serving
487 2017-05-18T19:35:31  <sipa> see that graph, the title is wrong
488 2017-05-18T19:35:33  <jonasschnelli> Currently overhauling the BIP
489 2017-05-18T19:35:47  <sipa> it shows the relative depth of each block downloaded from my node _excluding_ compact blocks
490 2017-05-18T19:36:10  <sipa> gmaxwell did some statistical analysis on it
491 2017-05-18T19:36:30  *** BMRelayBot has joined #bitcoin-core-dev
492 2017-05-18T19:36:38  <gmaxwell> Sipa's data is interesting. 144 is to small for sure.  1008 is fine.  I'm of the view that we don't need more than a dozen or so blocks of headroom.  I think the BIP should be written based on what you should keep.  How you decide where to fetch depends on exactly what you're doing.
493 2017-05-18T19:37:05  <stickcuck> hm
494 2017-05-18T19:37:27  <gmaxwell> I found no really evidence of a real preference for N weeks in sipas data, but rather, advantages for doing 1-day 2-day 3-day ...  etc. But 'day' is a lot more than 144 blocks, because of hashrate increases.
495 2017-05-18T19:38:04  <gmaxwell> You can process the data to roughly remove IBDing peers and the fall off is pretty stark.
496 2017-05-18T19:38:18  <gmaxwell> note sipas graph ignores depth 0.
497 2017-05-18T19:38:33  <sipa> it'd be a hockeystick if it included 0
498 2017-05-18T19:38:44  <jonasschnelli> What would you recommend for "day" instead 144, calc in the historical hashrate increase?
499 2017-05-18T19:38:53  <gmaxwell> also 0 data is inaccurate because it excludes compact blocks
500 2017-05-18T19:39:08  *** zooko has quit IRC
501 2017-05-18T19:39:18  <sipa> gmaxwell: didn't you suggest 288?
502 2017-05-18T19:39:20  <gmaxwell> jonasschnelli: I think we should make the first threshold 288. It's more than enough to cover a 'day' in practice.
503 2017-05-18T19:39:39  <jonasschnelli> 288 and 1008...
504 2017-05-18T19:39:59  <jonasschnelli> But then the current minimum (prune=550) would not allow to signal the LOW mode?
505 2017-05-18T19:40:08  <morcos> the current minimum is 288
506 2017-05-18T19:40:11  <gmaxwell> and then peers should estimate what they need (based on time, or headers if they have them) and choose where to connect. The estimate should be conservative but it doesn't need to be a 100 block headroom, a dozen blocks should be fine. If you get headers and find that you need more, you'll disconnect and go elsewhere.
507 2017-05-18T19:40:13  <jonasschnelli> Or is 288 including headroom?
508 2017-05-18T19:40:24  <morcos> the 550 is just so you don't set a prune limit which you have no hope of respecting
509 2017-05-18T19:40:26  <gmaxwell> the minimum is 288 blocks.
510 2017-05-18T19:40:30  <morcos> its out of date with segwit
511 2017-05-18T19:40:44  <gmaxwell> and we'll blow over the prune setting to preserve 288 blocks.
512 2017-05-18T19:40:55  <morcos> i think the calculation is presented in the code comments
513 2017-05-18T19:41:03  <jonasschnelli> Yes. 288 is the minimum. So we should remove the BIP headroom/buffer from the BIP
514 2017-05-18T19:41:22  <gmaxwell> I think eventually we should be changing the prune setting to be enum-like but thats another matter.
515 2017-05-18T19:41:58  <gmaxwell> jonasschnelli: I think the BIP shouldn't have any buffer.  "You store X from your tip" "You store Y from your tip"  it can then make advice to users on how to choose connections. but the requirement is just what you promise to store.
516 2017-05-18T19:42:13  <jonasschnelli> gmaxwell: ack
517 2017-05-18T19:43:12  <gmaxwell> The advice can say to use the best info you have available (time or headers if you have them) to figure out what you need, and then give enough headroom maybe 6 or 12 blocks that you can fetch parents.  The cost of connecting to someone that doesn't have what you need is not that great. You'll request headers from them, learn you need blocks they don't have and you'll disconnect them and connect
518 2017-05-18T19:43:18  <gmaxwell>  to someone else.
519 2017-05-18T19:44:01  <jonasschnelli> For the 1008 I guess the BIP can no longer state blocks for 1 week. Now the question is to use 2016 or say it 3.5 days..
520 2017-05-18T19:44:17  <sipa> ?
521 2017-05-18T19:44:35  <sipa> i think it should just say 1008 or 2016 blocks or so, and not make any connection with time
522 2017-05-18T19:44:44  <jonasschnelli> From what I understood is that 144 is to little for a day regarding the increasing hash-rate
523 2017-05-18T19:44:54  <gmaxwell> jonasschnelli: I'll catch up with you later today, I don't have my processed results in front of me. But I think I found that after elimiating IBDs there were very few fetches in sipas data past 1000 blocks deep.    And indeed, it shouldn't mention time.
524 2017-05-18T19:45:37  <jonasschnelli> But light client implementations are really looking for "days" rather the blocks.. but, sure, they can do their homework... but would have been nice to mention day values in the BIP.
525 2017-05-18T19:45:43  <jonasschnelli> But maybe they are to inaccurate
526 2017-05-18T19:45:47  <gmaxwell> The bit(s) should just be defined as "I claim I will keep at least X blocks deep from my tip, maybe I keep more, maybe not."
527 2017-05-18T19:45:54  <sipa> jonasschnelli: light clients know how many blocks they are behind after header sync
528 2017-05-18T19:45:58  <gmaxwell> jonasschnelli: anyone using these bits will fetch headers.
529 2017-05-18T19:46:15  <jonasschnelli> Indeed.... okay. Got it.
530 2017-05-18T19:46:46  <gmaxwell> now, before you connect you won't have headers and you'll need to make a time based guess. If you guess wrong you'll need to disconnect and go elsewhere. Not the end of the world.
531 2017-05-18T19:47:16  <jonasschnelli> Yes. I agree on that. Re-connecting should be hard.
532 2017-05-18T19:47:37  <jonasschnelli> Maybe even an additional dns query may be involved (in case you filter)
533 2017-05-18T19:48:10  <sipa> even if it happens, it'll happen just once
534 2017-05-18T19:48:31  <jonasschnelli> Yeah,... shouldn't be a problem for clients
535 2017-05-18T19:48:34  <sipa> because even if you connect to a peer that does not have enough blocks, they'll have the headers to teach you how many blocks you are behind
536 2017-05-18T19:48:39  <sipa> so i don't think it's such a big issue
537 2017-05-18T19:49:03  <sipa> done topic?
538 2017-05-18T19:49:08  <gmaxwell> I think I mentioned it on the list, but it should be clear that these bits should still mean that you can serve headers for the whole chain.
539 2017-05-18T19:49:33  <wumpus> #topic bytes_serialized (sipa)
540 2017-05-18T19:49:38  <sipa> thanks
541 2017-05-18T19:49:42  <gmaxwell> Kill with fire (sorry wumpus)
542 2017-05-18T19:49:43  <jonasschnelli> gmaxwell: seems obvious.. but I'll mention it
543 2017-05-18T19:49:43  <gmaxwell> :P
544 2017-05-18T19:49:54  <sipa> so currently gettxoutsetinfo has a field called bytes_serialized
545 2017-05-18T19:50:03  <sipa> which is based on some theoretical serialization of the utxo set data
546 2017-05-18T19:50:09  <wumpus> I think there's something to be said for a neutral way of representing the utxo size, that doesn't represent on estimates of a specific database format
547 2017-05-18T19:50:17  <sipa> wumpus: agree with that
548 2017-05-18T19:50:20  <gmaxwell> what I said to sipa the other day was that if we list the total bytes in values and the txout counts, that lets you come up with whatever kind of seralized size estimate you want.
549 2017-05-18T19:50:45  <sipa> but would you be fine with it just being the size of keys+values in a neutral format, _not_ accounting for the leveldb prefix compression?
550 2017-05-18T19:50:51  <wumpus> sipa: yes
551 2017-05-18T19:50:52  <gmaxwell> If you want you could multiply that count by 36 and add the values and that gives you the size for the dumbest seralization that hopefully no one would use.
552 2017-05-18T19:50:52  <luke-jr> values counted as 8 bytes, or compressed?
553 2017-05-18T19:51:08  <wumpus> sipa: that's be fine really, and the format change provides oppertunity to change the definition
554 2017-05-18T19:51:14  <sipa> wumpus: agree
555 2017-05-18T19:51:22  <gmaxwell> okay if wumpus and sipa agree I'll shutup.
556 2017-05-18T19:51:31  <sipa> luke-jr: no strong opinion. do you?
557 2017-05-18T19:51:42  <luke-jr> sipa: I don't think the compression should be exposed, ideally.
558 2017-05-18T19:51:48  <sipa> luke-jr: seems fair
559 2017-05-18T19:51:49  <gmaxwell> wumpus: the only concern I had with a really neutral figure is that it's misleading.
560 2017-05-18T19:51:51  <luke-jr> not a strong opinion though
561 2017-05-18T19:51:51  <wumpus> luke-jr: just a fixed size seems ok to me
562 2017-05-18T19:52:01  <wumpus> luke-jr: that's more future proof likely
563 2017-05-18T19:52:07  <wumpus> luke-jr: so we can have a statistic to compare over time
564 2017-05-18T19:52:11  <morcos> can't we output more than one thing?
565 2017-05-18T19:52:27  <luke-jr> wumpus: indeed
566 2017-05-18T19:52:42  <gmaxwell> e.g. a naieve seralization would have 32 bytes for txid, but the reality is probably under 16 due to sharing.  But as long as it doesn't require scanning that data I guess I don't care.
567 2017-05-18T19:52:47  <sipa> morcos: so #10396 reports the actual disk usage
568 2017-05-18T19:52:48  <gribble> https://github.com/bitcoin/bitcoin/issues/10396 | Report LevelDB estimate for chainstate size in gettxoutsetinfo by sipa · Pull Request #10396 · bitcoin/bitcoin · GitHub
569 2017-05-18T19:52:53  <sipa> morcos: and the total number of utxos is also reported
570 2017-05-18T19:53:15  <wumpus> we should definitely report the actual disk usage too!
571 2017-05-18T19:53:23  <morcos> yeah i'm sorry if i'm behind, but i think actual disk usage is useful, even if we want this .. ok, that's all i was saying
572 2017-05-18T19:53:30  <luke-jr> agreed
573 2017-05-18T19:53:30  <sipa> yes yes, absolutely
574 2017-05-18T19:53:44  <sipa> the point is that the current bytes_serialized tries to mimick disk usage, but fails
575 2017-05-18T19:53:45  <gmaxwell> the leveldb usage is a noisy thing that goes up and down based on the mood of the table compacting gods.
576 2017-05-18T19:53:47  <luke-jr> (although I guess users can just du the directory?)
577 2017-05-18T19:53:50  <sipa> and will fail even more post per-txout
578 2017-05-18T19:54:17  <sipa> so if we drop the requirement that bytes_serialized has anything to do with disk usage, all is good
579 2017-05-18T19:54:25  <wumpus> gmaxwell: yep, it's less useful for reporting as statistics
580 2017-05-18T19:54:34  <wumpus> sipa: indeed; I never assumed it did really
581 2017-05-18T19:54:58  <wumpus> to me it was just 'serialization size of utxo in an arbitrary, but constant, format'
582 2017-05-18T19:55:00  <phantomcircuit> huh what im here
583 2017-05-18T19:55:19  <wumpus> sipa: would make sense to rename the field too
584 2017-05-18T19:55:21  <sipa> wumpus: ok, so 10195 removes bytes_serialized - i'll create a separate PR afterwards to add a (new) bytes_serialized again
585 2017-05-18T19:55:25  <sipa> wumpus: agree
586 2017-05-18T19:55:32  <gmaxwell> wumpus: it will be odd if the serialized size is larger than the database but not that odd.
587 2017-05-18T19:55:47  <sipa> gmaxwell: at least it will be obvious that it has nothing to do with it then!
588 2017-05-18T19:55:49  <wumpus> (after all we don't want people to report weird jumps in statistics, renaming the field is ag ood hint)
589 2017-05-18T19:56:07  <luke-jr> sipa: maybe it should be renamed?
590 2017-05-18T19:56:13  <sipa> luke-jr: yes, it should be
591 2017-05-18T19:56:17  <wumpus> "bogosize"
592 2017-05-18T19:56:21  <gmaxwell> bogosize++
593 2017-05-18T19:56:22  <sipa> hash_serialized is renamed too
594 2017-05-18T19:56:28  <sipa> hahaha bogosize
595 2017-05-18T19:56:34  <sipa> ok, deal
596 2017-05-18T19:56:39  <gmaxwell> should be in nibbles.
597 2017-05-18T19:56:42  <gmaxwell> :P
598 2017-05-18T19:56:43  <luke-jr> lol
599 2017-05-18T19:56:44  <wumpus> :D
600 2017-05-18T19:56:46  <sipa> in nepers
601 2017-05-18T19:56:49  <instagibbs> buy one get one size?
602 2017-05-18T19:56:55  <gmaxwell> ehats the base e entropy unit?
603 2017-05-18T19:56:58  <sipa> gmaxwell: yes
604 2017-05-18T19:57:27  <luke-jr> can I add an OP_CHECKBOGOSIZE? *hides*
605 2017-05-18T19:57:28  <gmaxwell> Good. (that was supposted to be a "Whats?" but seems you were a step ahead of me)
606 2017-05-18T19:57:39  <sipa> ah, no, nats
607 2017-05-18T19:57:47  <sipa> nepers are just for ratios, like db
608 2017-05-18T19:57:53  <sipa> </offtopic>
609 2017-05-18T19:58:02  <wumpus> time to close the meeting I think
610 2017-05-18T19:58:02  <instagibbs> 2 minutes
611 2017-05-18T19:58:04  <instagibbs> review begging?
612 2017-05-18T19:58:09  <instagibbs> :P
613 2017-05-18T19:58:11  <wumpus> we already did that one
614 2017-05-18T19:58:13  <instagibbs> ah k
615 2017-05-18T19:58:17  <luke-jr> defer BIP148 to next week?
616 2017-05-18T19:58:22  <wumpus> (though if you have any proposals just say so)
617 2017-05-18T19:58:24  <instagibbs> https://github.com/bitcoin/bitcoin/pull/10333 <-- my beg
618 2017-05-18T19:58:33  <wumpus> luke-jr: oh forgot about that one
619 2017-05-18T19:58:43  <luke-jr> it's okay, a week might be good anyway
620 2017-05-18T19:58:50  <gmaxwell> I'm sure you can discuss it in one minute.
621 2017-05-18T19:59:00  <gmaxwell> :P
622 2017-05-18T19:59:03  <kanzure> we need a meeting extension block
623 2017-05-18T19:59:04  * morcos refrains
624 2017-05-18T19:59:09  <wumpus> #endmeeting
625 2017-05-18T19:59:09  <lightningbot> Meeting ended Thu May 18 19:59:09 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
626 2017-05-18T19:59:09  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.html
627 2017-05-18T19:59:09  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.txt
628 2017-05-18T19:59:09  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-18-19.01.log.html
629 2017-05-18T19:59:15  <luke-jr> gmaxwell: well, to be fair, we've never had a formal time limit for meetings..
630 2017-05-18T19:59:27  <luke-jr> :p
631 2017-05-18T19:59:35  <instagibbs> it's a standardness rule...
632 2017-05-18T19:59:40  <kanzure> it was to prevent spam
633 2017-05-18T19:59:45  <gmaxwell> I like that they're limited. even though I always spend another half hour in resulting discussions.
634 2017-05-18T19:59:54  <gmaxwell> kanzure: that limit was temporary!
635 2017-05-18T20:00:00  <instagibbs> I think it's good to focus and respect people's time
636 2017-05-18T20:00:06  <wumpus> agree
637 2017-05-18T20:00:14  <sipa> we should revert to the original limit of 24 hours
638 2017-05-18T20:00:21  <luke-jr> >_<
639 2017-05-18T20:00:24  <gmaxwell> esp considering timezones don't put this meeting at good times of day for many.
640 2017-05-18T20:00:39  <wumpus> so make sure that you have topics ready at the beginning, that makes it easier to schedule time for topics
641 2017-05-18T20:00:41  <sipa> it's especially annoying for people in asia
642 2017-05-18T20:00:49  <luke-jr> sipa: IMO the original limit was 5 hours
643 2017-05-18T20:00:56  <sipa> i wonder if we should have the meeting alternate between two times
644 2017-05-18T20:00:56  <luke-jr> sipa: since that's how long until the day changes in UTC
645 2017-05-18T20:01:12  <gmaxwell> luke-jr: That isn't consistent with Craig Wright^W^WSatoshi's vision!
646 2017-05-18T20:01:25  <luke-jr> gmaxwell: it's consistent with tonal though
647 2017-05-18T20:01:33  <cfields> sipa: nah, let's just use an accounting trick and have meetings on a plane zooming through timezones.
648 2017-05-18T20:01:49  <luke-jr> anyway, my parents showed up, so going to say hi and then get back to multiwallet
649 2017-05-18T20:01:50  <kanzure> yes if you navigate the plane correctly, you can actually not spend any time at all in the meeting if you hop between timezones just right.
650 2017-05-18T20:01:58  <cfields> I'm pretty sure we can cram 2 days into 1 that way :p
651 2017-05-18T20:02:08  <luke-jr> cfields: rofl
652 2017-05-18T20:02:09  <gmaxwell> too bad they stopped flying the concord.
653 2017-05-18T20:02:24  <sipa> you just need a plane circeling the arctic
654 2017-05-18T20:02:35  <kanzure> sounds like bip148 discussion is slightly blocked by luke-jr parental units
655 2017-05-18T20:03:16  <wumpus> sipa: if there's interest from people from asia joining we should certainly do that; in practice I never had any concerete complains about the current meeting time though
656 2017-05-18T20:03:45  <sipa> wumpus: we did, a long time ago
657 2017-05-18T20:04:04  <gmaxwell> wumpus: jl2012 has lamented, and I believe kallewoof too.
658 2017-05-18T20:04:07  <cfields> iirc it's prohibitive for jl2012, at least
659 2017-05-18T20:04:16  <instagibbs> oh yeah, kalle too
660 2017-05-18T20:04:35  <wumpus> ok good to know
661 2017-05-18T20:04:55  <wumpus> maybe fanquake too (australia)
662 2017-05-18T20:05:03  <instagibbs> he's a kiwi I thought
663 2017-05-18T20:05:05  <jtimon> luke-jr: aug2017 seems to soon to me, I have no problems with bip149 on the other hand
664 2017-05-18T20:05:18  <gmaxwell> we could also just look at the log data, determine a time when when most of us are already here that the asian people can meet, and maybe just setup a hour to talk to them when they know people will be around.
665 2017-05-18T20:05:25  <sipa> 7am europe, 10pm westcoast, 1pm hongkong, 2pm japan?
666 2017-05-18T20:05:39  <sipa> maybe too early in europe
667 2017-05-18T20:05:43  <instagibbs> 1am East coast US, hmmm
668 2017-05-18T20:05:49  <sipa> instagibbs: oops
669 2017-05-18T20:05:57  <wumpus> I'm usualy up very early so that'd be ok with me
670 2017-05-18T20:05:59  <gmaxwell> I think there is no time everyone can meet. But thats okay.
671 2017-05-18T20:06:01  <gmaxwell> wumpus is up that early.
672 2017-05-18T20:06:04  <gmaxwell> oh oops.
673 2017-05-18T20:06:04  <wumpus> better than late at night
674 2017-05-18T20:06:17  <instagibbs> I'll survive once a week if that works
675 2017-05-18T20:06:43  <instagibbs> oh right Chaincode...
676 2017-05-18T20:06:47  <instagibbs> :)
677 2017-05-18T20:07:11  <sipa> damn timezones
678 2017-05-18T20:07:14  <achow101> I'd rather not be up at 1 am
679 2017-05-18T20:07:27  <sipa> achow101: you'll be on the west coast soon :)
680 2017-05-18T20:07:33  <instagibbs> Maybe figuring a way to reliably rotate or something. I dunno.
681 2017-05-18T20:08:02  <achow101> sipa: thinking ahead a bit past the summer :)
682 2017-05-18T20:08:22  <gmaxwell> instagibbs: well Above I just suggested we have a second meeting at another time.  It may be the case that the activity level in the meetings with asia are low enough that rotating wouldn't make sense.
683 2017-05-18T20:08:40  <sipa> otherwise 4pm europe, 7am westcoast, 10am eastcoast, 10pm hongkong, 11pm japan?
684 2017-05-18T20:08:43  <gmaxwell> instagibbs: if we pick at time when 'enough' people are here anyways, then it's not like setting aside the slot has a huge cost.
685 2017-05-18T20:08:45  <instagibbs> hm yeah that makes more sense
686 2017-05-18T20:08:58  <luke-jr> jtimon: well, it's already happening Aug 1 with BIP148..
687 2017-05-18T20:09:44  <jtimon> luke-jr: right, I mean that seems too soon
688 2017-05-18T20:10:00  <jtimon> so I don't think I will run bip148 myself
689 2017-05-18T20:10:06  <gmaxwell> sipa: so there is like 3 hours between japan and auckland, so that might actually fail to get everyone in that part of the globe.
690 2017-05-18T20:10:24  <luke-jr> jtimon: oh well. :<
691 2017-05-18T20:11:38  <sipa> gmaxwell: yes, we need a slower earth rotation
692 2017-05-18T20:11:53  <instagibbs> don't give kanzure any ideas
693 2017-05-18T20:14:10  <gmaxwell> instagibbs: kanzure wants to destroy the moon I thought, that would reduce the slowing a lot.
694 2017-05-18T20:14:15  *** vicenteH` has joined #bitcoin-core-dev
695 2017-05-18T20:14:17  <gmaxwell> sipa: thats already happening, just wait a while.
696 2017-05-18T20:14:57  *** BMRelayBot has quit IRC
697 2017-05-18T20:15:13  <sipa> gmaxwell: 2ms per century isn't very much
698 2017-05-18T20:15:45  <kanzure> yeah i have some plans but it's sort of off-topic
699 2017-05-18T20:16:02  *** vicenteH has quit IRC
700 2017-05-18T20:16:03  *** jtimon has quit IRC
701 2017-05-18T20:16:21  *** jtimon has joined #bitcoin-core-dev
702 2017-05-18T20:21:03  *** BMRelayBot has joined #bitcoin-core-dev
703 2017-05-18T20:25:29  <stickcuck> ok
704 2017-05-18T20:30:19  *** zooko has joined #bitcoin-core-dev
705 2017-05-18T20:30:25  *** BartokIT has joined #bitcoin-core-dev
706 2017-05-18T20:31:45  *** BMRelayBot has quit IRC
707 2017-05-18T20:34:58  *** BMRelayBot has joined #bitcoin-core-dev
708 2017-05-18T20:38:01  *** BartokIT has joined #bitcoin-core-dev
709 2017-05-18T20:41:09  <bitcoin-git> [bitcoin] jnewbery opened pull request #10423: [tests] skipped tests should clean up after themselves (master...cleanup_skipped) https://github.com/bitcoin/bitcoin/pull/10423
710 2017-05-18T20:45:29  *** zooko has quit IRC
711 2017-05-18T20:55:36  *** BartokIT has quit IRC
712 2017-05-18T21:01:12  *** d_t has joined #bitcoin-core-dev
713 2017-05-18T21:04:31  <bitcoin-git> [bitcoin] morcos opened pull request #10424: Populate services in GetLocalAddress (master...notnodenone) https://github.com/bitcoin/bitcoin/pull/10424
714 2017-05-18T21:10:28  *** freqry has joined #bitcoin-core-dev
715 2017-05-18T21:18:49  *** fengling has quit IRC
716 2017-05-18T21:18:50  *** [Author] has quit IRC
717 2017-05-18T21:18:51  *** Magma has quit IRC
718 2017-05-18T21:19:06  *** Sprh has quit IRC
719 2017-05-18T21:56:20  <jtimon> travis tests seem to be stuck for https://github.com/bitcoin/bitcoin/pull/9176
720 2017-05-18T22:06:52  *** freqry has quit IRC
721 2017-05-18T22:11:25  *** jannes has quit IRC
722 2017-05-18T22:12:18  *** kadoban has quit IRC
723 2017-05-18T22:12:28  *** kadoban has joined #bitcoin-core-dev
724 2017-05-18T22:12:56  *** Guyver2 has quit IRC
725 2017-05-18T22:15:52  *** cryptapus_afk has quit IRC
726 2017-05-18T22:16:14  *** cryptapus_afk has joined #bitcoin-core-dev
727 2017-05-18T22:27:37  <kallewoof> Being able to participate in a meeting occasionally would be spiffy for sure.
728 2017-05-18T22:36:36  *** zooko has joined #bitcoin-core-dev
729 2017-05-18T22:52:07  *** vicenteH` has quit IRC
730 2017-05-18T22:53:31  *** spinza has quit IRC
731 2017-05-18T22:55:09  *** tripleslash has quit IRC
732 2017-05-18T22:55:37  <bitcoin-git> [bitcoin] earonesty opened pull request #10425: 0.14 (0.14...0.14) https://github.com/bitcoin/bitcoin/pull/10425
733 2017-05-18T22:59:20  *** spinza has joined #bitcoin-core-dev
734 2017-05-18T23:16:04  *** goksinen has quit IRC
735 2017-05-18T23:20:15  *** goksinen has joined #bitcoin-core-dev
736 2017-05-18T23:23:51  *** goksinen has quit IRC
737 2017-05-18T23:25:15  *** shockoo has joined #bitcoin-core-dev
738 2017-05-18T23:44:54  <bitcoin-git> [bitcoin] sipa opened pull request #10426: Replace bytes_serialized with bogosize (master...bogosize) https://github.com/bitcoin/bitcoin/pull/10426
739 2017-05-18T23:47:03  *** Aaronvan_ has quit IRC
740 2017-05-18T23:47:14  *** goksinen has joined #bitcoin-core-dev
741 2017-05-18T23:49:56  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10241: Allow tests to pass even when stderr got populated (master...2017/04/test_stderr) https://github.com/bitcoin/bitcoin/pull/10241
742 2017-05-18T23:52:08  *** goksinen has quit IRC
743 2017-05-18T23:58:15  *** fanquake has joined #bitcoin-core-dev
744 2017-05-18T23:59:13  *** fanquake has left #bitcoin-core-dev