1 2017-08-10T00:00:11  *** promag has quit IRC
  2 2017-08-10T00:00:53  *** Aaronvan_ has joined #bitcoin-core-dev
  3 2017-08-10T00:04:06  *** AaronvanW has quit IRC
  4 2017-08-10T00:08:01  *** owowo has quit IRC
  5 2017-08-10T00:12:19  *** promag has joined #bitcoin-core-dev
  6 2017-08-10T00:12:35  *** promag has quit IRC
  7 2017-08-10T00:12:55  *** owowo has joined #bitcoin-core-dev
  8 2017-08-10T00:12:55  *** owowo has joined #bitcoin-core-dev
  9 2017-08-10T00:15:43  *** Aaronvan_ has quit IRC
 10 2017-08-10T00:16:18  *** AaronvanW has joined #bitcoin-core-dev
 11 2017-08-10T00:20:49  *** AaronvanW has quit IRC
 12 2017-08-10T00:25:06  *** promag has joined #bitcoin-core-dev
 13 2017-08-10T00:38:00  *** promag has quit IRC
 14 2017-08-10T01:03:09  *** LampTreadStone07 has quit IRC
 15 2017-08-10T01:05:05  *** dcousens has joined #bitcoin-core-dev
 16 2017-08-10T01:21:17  *** d_t has quit IRC
 17 2017-08-10T01:27:42  *** promag has joined #bitcoin-core-dev
 18 2017-08-10T01:38:07  *** d_t has joined #bitcoin-core-dev
 19 2017-08-10T01:52:52  *** dabura667_ has joined #bitcoin-core-dev
 20 2017-08-10T01:53:01  *** dabura667_ has quit IRC
 21 2017-08-10T01:56:41  *** promag has quit IRC
 22 2017-08-10T02:25:55  *** neha has quit IRC
 23 2017-08-10T02:26:16  *** neha has joined #bitcoin-core-dev
 24 2017-08-10T02:26:23  *** moctos has joined #bitcoin-core-dev
 25 2017-08-10T02:51:27  *** d_t has quit IRC
 26 2017-08-10T02:52:49  *** chjj has quit IRC
 27 2017-08-10T03:12:49  *** jimpo has joined #bitcoin-core-dev
 28 2017-08-10T03:13:31  <jimpo> What does fOneShot mean in the net code? Seems to be set for connections to seed nodes?
 29 2017-08-10T03:22:21  <jimpo> Ah, is the idea that we only use seed nodes to get addresses then disconnect?
 30 2017-08-10T04:11:30  *** Cory has quit IRC
 31 2017-08-10T04:18:28  *** Cory has joined #bitcoin-core-dev
 32 2017-08-10T04:18:50  <venzen> The fact SegWit activation comes with a 4x blocksize limit increase is reason for concern
 33 2017-08-10T04:19:33  <venzen> My bad for not comprehending this sooner - I was somehow understanding "effective" block size limit increase from BIP141 and related explanations
 34 2017-08-10T04:20:14  <sipa> venzen: it does not come with a 4x validation cost increase, however
 35 2017-08-10T04:20:23  <venzen> since there is no longer a "big block" contingent to appease, would a 2x increase perhaps be more appropriate and safe?
 36 2017-08-10T04:20:24  <sipa> nor a 4x utxo growth
 37 2017-08-10T04:21:17  <venzen> sipa: true, i have read aantonop's explanation of the incentive to reduce UTXO set growth and your BIP makes that clear
 38 2017-08-10T04:21:23  <gmaxwell> venzen: segwit eliminates the block size limit, replaces it with a block weight limit. Weight is designed to better reflect the cost of transactions to the network.
 39 2017-08-10T04:21:56  <gmaxwell> because weight is limited instead of size, the maximum amount of size is variable depending on the content.
 40 2017-08-10T04:22:16  <venzen> gmaxwell: sipa: apologies for my confusion but I am receiving mixed messages - some are saying that real 4MB blocks are possible, is this true?
 41 2017-08-10T04:22:25  <gmaxwell> Similar to how the number of 1 bits in a block varry.
 42 2017-08-10T04:22:33  <venzen> ok
 43 2017-08-10T04:22:41  <sipa> venzen: in theory, yes
 44 2017-08-10T04:22:50  <gmaxwell> venzen: sure, if you construct transactions that have low weight you can put more of them in a block.
 45 2017-08-10T04:23:45  <venzen> gmaxwell: sipa: are there substantive reasons why it should be 4MB and not a more concervative 2MB limit?
 46 2017-08-10T04:23:48  <gmaxwell> Similar to how normally a block has only about 500,000 1 bits, but you could construct a block with nearly 1,000,000 one bits, if you constructed the transactions right.. because (pre segwit) the system limits the size not the number of 1 bits.
 47 2017-08-10T04:24:02  <sipa> venzen: the size of blocks is not that relevant
 48 2017-08-10T04:24:10  <sipa> their validation cost is
 49 2017-08-10T04:24:38  <venzen> sipa: validation as in CPU resources across the network?
 50 2017-08-10T04:24:38  <gmaxwell> venzen: because limiting weight increases capacity and dampens attacks. Size of some particular serialization is not a good measure of the resource usage of a block.
 51 2017-08-10T04:25:44  <venzen> gmaxwell: sipa: ok, i guess i'm stil stuck in the induced demand paradigm, let me do some reading and thinking - thanks for your explanations
 52 2017-08-10T04:26:29  <gmaxwell> venzen: you are making a reasoning error in privledging size.
 53 2017-08-10T04:27:31  <gmaxwell> Size doesn't necessairly have a strong relationship to anything that matters... blocks are sent a the tip with compact blocks.
 54 2017-08-10T04:28:01  <gmaxwell> In the future historical blocks may be sent with compact seralization (which is 25%) smaller and compression, or not sent at all.
 55 2017-08-10T04:28:48  <gmaxwell> Size ignores the impact on the UTXO set.. so as time goes on size increasingly has little to do with anything that matters.
 56 2017-08-10T04:33:12  *** jimpo has quit IRC
 57 2017-08-10T04:35:49  <venzen> gmaxwell: ok, i will process the information, i'm obviously failing to grasp a fundamental concept and will find it
 58 2017-08-10T04:37:21  <venzen> if the devs unanimously agree that a 4MB blocksize limit is ok with a block weight decider then I believe that
 59 2017-08-10T04:38:19  <sipa> venzen: see it this way, segwit does not at all increase the maximum number of outputs or inputs can have
 60 2017-08-10T04:38:25  <sipa> *a block
 61 2017-08-10T04:39:35  <sipa> yes, the number of bytes on disk may increase faster but 1) since compact blocks, latency is no longer impacted by the number of bytes in a block 2) with pruning, storage of old blocks doesn't matter
 62 2017-08-10T04:40:31  <sipa> so the only real increase is the cost of transaction relay, which is in the order of kilobytes/sec
 63 2017-08-10T04:43:34  <venzen> sipa: i'm assuming that the primary consideration is at the UTXO level, so number of txns per block is the wrong way to think about this? Even so, we can expect an increase in the number of "traditional" P2PKH txns per block after activation?
 64 2017-08-10T04:47:22  *** miknotauro has joined #bitcoin-core-dev
 65 2017-08-10T04:58:01  *** miknotauro has quit IRC
 66 2017-08-10T05:05:44  <venzen> sipa: i assume you're not responding because the answers are already contained in your and gmaxwell 's responses above. I will meditate upon those. Thank you very much for taking the time to explain to a layman - you guys are international treasures and history will acknowledge you.
 67 2017-08-10T05:10:12  *** chjj has joined #bitcoin-core-dev
 68 2017-08-10T05:24:02  <sipa> venzen: number of transactions never matters... inputs and outputs do, the conplexity of their scripts, database growth, ...
 69 2017-08-10T05:24:30  <sipa> but many transactions with few in/out, or few transactions with many in/out can be equivalent
 70 2017-08-10T05:48:34  <bitcoin-git> [bitcoin] kallewoof opened pull request #11019: [wallet] Abandon transactions that fail to go into the mempool (master...abandon-longchain-failed-tx) https://github.com/bitcoin/bitcoin/pull/11019
 71 2017-08-10T06:16:56  *** Victorsueca has quit IRC
 72 2017-08-10T06:18:05  *** Victorsueca has joined #bitcoin-core-dev
 73 2017-08-10T06:46:42  *** BashCo has quit IRC
 74 2017-08-10T07:05:30  <wumpus> aj: sorry but bad time to ask now, I don't have much time to look at features, trying to focus on the 0.15 branch-off and 0.15.0rc1 release
 75 2017-08-10T07:06:06  *** BashCo has joined #bitcoin-core-dev
 76 2017-08-10T07:06:39  <wumpus> aj: the includeconf stuff looks good at a high level but haven't looked in detail, eg. whether it doesn't make the initialization and config reading code even less understandable
 77 2017-08-10T07:32:59  *** d_t has joined #bitcoin-core-dev
 78 2017-08-10T07:36:58  <aj> wumpus: yup figured, no worries
 79 2017-08-10T07:39:01  <wumpus> aj: I promise to look at it as one of the first things after the branch
 80 2017-08-10T07:40:15  <aj> wumpus: post celebratory beverage or similar i trust!
 81 2017-08-10T07:42:11  <wumpus> aj: the thing I'm most worried with regard to risk of changes in that area of the code is that a) the qt/bitcoind initialization sequences start to diverge or b) the precedence of options between commandline/configuration file/qt settings becomes different. There's a lot that can go wrong there and we don't have tests for that :(
 82 2017-08-10T07:45:54  *** timothy has joined #bitcoin-core-dev
 83 2017-08-10T07:45:57  <kallewoof> Why would includeconf PR cause divergence with QT? It feels like QT-side could have the same feature. (If not, I can look into that.) Maybe I misunderstand the point.
 84 2017-08-10T07:47:50  <jonasschnelli> BIP151 encryption question: the current definition says, that encryption negotiation has to be done before the version handshake (I guess it makes sense to have the enc.negotiation first). But how should a peer know if the other peer supports BIP151. Try and reconnect? Service bit fetch-able via relay, seeds (meh!)?
 85 2017-08-10T07:48:22  <aj> wumpus: yeah, i was a bit surprised to see the init code was duplicated there, rather than just a common function of some sort
 86 2017-08-10T07:49:05  <aj> wumpus: (the error reporting makes that not a trivial fix though)
 87 2017-08-10T07:49:06  <wumpus> kallewoof: yes, the qt-side should have the same feature, that's exactly "why", but it might conflict with other things there as there's an extra settings source
 88 2017-08-10T07:49:31  <wumpus> aj: yes, error reporting as well as qsettings, translations handling, etc makes that different and hard to unify
 89 2017-08-10T07:49:47  <wumpus> aj: the qt setup sequence is much more complex
 90 2017-08-10T07:49:55  <wumpus> aj: ideally we'd have tests, that'd be much more reassuring
 91 2017-08-10T07:50:33  <wumpus> pretty much a preconditioning for refactoring there
 92 2017-08-10T07:52:24  <aj> wumpus: hmm, can travis start qt/bitcoin, or would local-only tests be sufficient at least to start?
 93 2017-08-10T07:54:11  <wumpus>  if the test is not interested in windowed output w/ QT_QPA_PLATFORM=minimal you can avoid the X dependency, this is what the bitcoin-qt unit-tests in src/qt/test do
 94 2017-08-10T07:54:56  <wumpus> also in principle you can run all the functional tests with bitcoin-qt instead of bitcoind (but that's not useful for travis :-)
 95 2017-08-10T07:55:33  <wumpus> in any case even locla-only tests are an improvement to having nothing
 96 2017-08-10T07:55:51  <wumpus> travis/build support can be sorted out later
 97 2017-08-10T08:07:06  <bitcoin-git> [bitcoin] kallewoof opened pull request #11020: [wallet] getbalance: Add option to include non-mempool UTXOs (master...unspendable-utxo-handling) https://github.com/bitcoin/bitcoin/pull/11020
 98 2017-08-10T08:10:47  *** d_t has quit IRC
 99 2017-08-10T08:14:54  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442
100 2017-08-10T08:17:04  *** BashCo_ has joined #bitcoin-core-dev
101 2017-08-10T08:19:05  *** BashCo has quit IRC
102 2017-08-10T08:27:06  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10532: -bip148 option (master...bip148) https://github.com/bitcoin/bitcoin/pull/10532
103 2017-08-10T08:33:32  *** BashCo_ has quit IRC
104 2017-08-10T08:41:30  *** SopaXorzTaker has joined #bitcoin-core-dev
105 2017-08-10T09:15:14  *** Yogaqueef has joined #bitcoin-core-dev
106 2017-08-10T09:41:55  <bitcoin-git> [bitcoin] AkioNak opened pull request #11021: fix getchaintxstats() (master...fix_getchaintxstats) https://github.com/bitcoin/bitcoin/pull/11021
107 2017-08-10T09:56:51  *** Guyver2 has joined #bitcoin-core-dev
108 2017-08-10T09:57:05  *** elkalamar has quit IRC
109 2017-08-10T10:04:48  *** BashCo has joined #bitcoin-core-dev
110 2017-08-10T10:56:20  *** timothy has quit IRC
111 2017-08-10T10:57:46  *** JackH has joined #bitcoin-core-dev
112 2017-08-10T11:01:30  *** AaronvanW has joined #bitcoin-core-dev
113 2017-08-10T12:30:14  *** timothy has joined #bitcoin-core-dev
114 2017-08-10T12:38:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
115 2017-08-10T12:43:34  *** Chris_Stewart_5 has quit IRC
116 2017-08-10T12:47:04  *** Mattie161 has joined #bitcoin-core-dev
117 2017-08-10T12:49:49  *** sam_c has quit IRC
118 2017-08-10T12:51:52  *** sam_c has joined #bitcoin-core-dev
119 2017-08-10T12:59:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
120 2017-08-10T13:26:17  <venzen> sipa: gmaxwell: thanks, i'm processing, your explanations helped a great deal
121 2017-08-10T13:36:27  *** rgrant has joined #bitcoin-core-dev
122 2017-08-10T13:54:51  <sdaftuar> jtimon: this is incorrect - https://twitter.com/timoncc/status/895559780231593984
123 2017-08-10T13:55:05  *** moctos has quit IRC
124 2017-08-10T13:55:10  <sdaftuar> 0.14.2 certainly can sign segwit transactions
125 2017-08-10T13:56:08  <sdaftuar> the wallet doesn't use segwit by default though, and only lets you (easily) create p2sh-wrapped segwit addresses after segwit activates.
126 2017-08-10T14:00:57  *** dcousens has quit IRC
127 2017-08-10T14:03:01  *** dcousens has joined #bitcoin-core-dev
128 2017-08-10T14:05:27  *** justan0theruser has quit IRC
129 2017-08-10T14:16:08  *** rockhouse has joined #bitcoin-core-dev
130 2017-08-10T14:18:39  *** Guyver2 has quit IRC
131 2017-08-10T14:26:10  <bitcoin-git> [bitcoin] jnewbery opened pull request #11022: Basic keypool topup (master...basic_keypool_topup) https://github.com/bitcoin/bitcoin/pull/11022
132 2017-08-10T14:28:41  *** goldstar has joined #bitcoin-core-dev
133 2017-08-10T14:47:48  *** goldstar has quit IRC
134 2017-08-10T14:58:04  *** rgrant has left #bitcoin-core-dev
135 2017-08-10T15:03:03  *** Aaronva__ has joined #bitcoin-core-dev
136 2017-08-10T15:06:05  *** AaronvanW has quit IRC
137 2017-08-10T15:10:07  *** alreadylate has joined #bitcoin-core-dev
138 2017-08-10T15:12:19  *** Murch has joined #bitcoin-core-dev
139 2017-08-10T15:14:08  *** dcousens has quit IRC
140 2017-08-10T15:20:33  *** dgenr8 has joined #bitcoin-core-dev
141 2017-08-10T15:40:49  *** Aaronva__ is now known as AaronvanW
142 2017-08-10T15:44:42  *** alreadylate has quit IRC
143 2017-08-10T16:05:31  *** elkalamar has joined #bitcoin-core-dev
144 2017-08-10T16:21:14  *** smill has joined #bitcoin-core-dev
145 2017-08-10T16:33:54  *** BashCo has quit IRC
146 2017-08-10T16:34:46  *** BashCo has joined #bitcoin-core-dev
147 2017-08-10T16:38:57  *** BashCo has quit IRC
148 2017-08-10T16:46:48  *** timothy has quit IRC
149 2017-08-10T16:53:24  <bitcoin-git> [bitcoin] jnewbery opened pull request #11023: [tests] Add option to attach a python debugger if functional test fails (master...func_test_pdb) https://github.com/bitcoin/bitcoin/pull/11023
150 2017-08-10T16:57:00  *** sanada` has joined #bitcoin-core-dev
151 2017-08-10T16:58:28  *** sanada has quit IRC
152 2017-08-10T17:02:37  *** abpa has joined #bitcoin-core-dev
153 2017-08-10T17:08:49  *** chjj has quit IRC
154 2017-08-10T17:09:56  *** jimpo has joined #bitcoin-core-dev
155 2017-08-10T17:10:13  <bitcoin-git> [bitcoin] practicalswift opened pull request #11024: tests: Free the OpenSSL error queue as part of the wallet_crypto/OldDecrypt test cleanup (master...OldDecrypt-cleanup) https://github.com/bitcoin/bitcoin/pull/11024
156 2017-08-10T17:10:46  *** BashCo has joined #bitcoin-core-dev
157 2017-08-10T17:16:38  *** RoyceX has joined #bitcoin-core-dev
158 2017-08-10T17:21:36  *** miknotauro has joined #bitcoin-core-dev
159 2017-08-10T17:29:11  *** amosbird has quit IRC
160 2017-08-10T17:32:47  *** amosbird has joined #bitcoin-core-dev
161 2017-08-10T17:38:50  *** d_t has joined #bitcoin-core-dev
162 2017-08-10T17:49:23  *** THoVer has joined #bitcoin-core-dev
163 2017-08-10T17:54:49  *** chjj has joined #bitcoin-core-dev
164 2017-08-10T17:57:58  *** THoVer has quit IRC
165 2017-08-10T18:03:14  <earlz> I'm trying to setup a new Gitian VM and I can't remember what I did to fix this error "failed to mound /dev/shm" using LXC
166 2017-08-10T18:26:02  <wumpus> no google hits either?
167 2017-08-10T18:26:11  *** corinrose_ has joined #bitcoin-core-dev
168 2017-08-10T18:27:43  <wumpus> it sounds like a common lxc/vm issue, not specific to gitian
169 2017-08-10T18:28:50  <earlz> Everything I've tried has been nothing so far
170 2017-08-10T18:29:02  <earlz> just following exact directions as in the gitian-building.md doc
171 2017-08-10T18:29:14  <earlz> lxc-execute: Mount of 'shm' onto '/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/shm' was onto a symlink!
172 2017-08-10T18:29:17  <earlz> lxc-execute: File exists - failed to mount 'shm' on '/usr/lib/x86_64-linux-gnu/lxc/rootfs/dev/shm'
173 2017-08-10T18:29:42  <wumpus> might be that some steps code-rotted, due to debian version drift
174 2017-08-10T18:30:19  <wumpus> ideally someone would try to follow it every so often, from scratch, and make corrections where needed
175 2017-08-10T18:30:26  <earlz> I did this same process a week ago and ran into 2 completely different problems, 1 where I just needed to reboot, and 1 where I ahd to do something to make network connections work
176 2017-08-10T18:30:46  <achow101> earlz: that should have been fixed by https://github.com/devrandom/gitian-builder/pull/150
177 2017-08-10T18:31:11  <achow101> did you pull in the latest version of gitian-builder?
178 2017-08-10T18:32:31  <earlz> I just cloned it today, so yes. I'm using debian 8.5 as used in the walkthrough also, so I don't think it's the same issue
179 2017-08-10T18:33:42  <earlz> Might try rolling back that commit and seeing what happens
180 2017-08-10T18:35:00  <earlz> yep, rolling back the bit for shm fixed the initial problem at least. I'll report a bug there
181 2017-08-10T18:35:37  <wumpus> so another source of drift would be gitian-builder updates :)
182 2017-08-10T18:40:56  *** Dizzle has joined #bitcoin-core-dev
183 2017-08-10T18:42:05  *** arowser has quit IRC
184 2017-08-10T18:51:18  *** laurentmt has joined #bitcoin-core-dev
185 2017-08-10T18:53:18  *** laurentmt has quit IRC
186 2017-08-10T18:54:04  *** frogstar has joined #bitcoin-core-dev
187 2017-08-10T18:55:06  *** arowser has joined #bitcoin-core-dev
188 2017-08-10T18:56:19  *** clarkmoody has joined #bitcoin-core-dev
189 2017-08-10T18:58:08  <frogstar> clarkmoody!
190 2017-08-10T18:58:13  <frogstar> I love your charts!
191 2017-08-10T18:58:52  <kanzure> wrong channel
192 2017-08-10T18:59:06  *** alreadylate has joined #bitcoin-core-dev
193 2017-08-10T19:00:10  <achow101> meeting?
194 2017-08-10T19:00:16  <wumpus> #startmeeting
195 2017-08-10T19:00:16  <lightningbot> Meeting started Thu Aug 10 19:00:16 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
196 2017-08-10T19:00:16  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
197 2017-08-10T19:00:20  <jonasschnelli> hi
198 2017-08-10T19:00:22  <achow101> hi
199 2017-08-10T19:00:24  <Chris_Stewart_5> ello
200 2017-08-10T19:00:26  <sdaftuar> hey
201 2017-08-10T19:00:45  <instagibbs> hi
202 2017-08-10T19:00:59  <wumpus> any topics?
203 2017-08-10T19:01:18  <jnewbery> #10882 please
204 2017-08-10T19:01:22  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Stop advancing best block and shutdown node if keypool drops below critical threshold by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
205 2017-08-10T19:01:42  <wumpus> good idea
206 2017-08-10T19:01:43  <wumpus> #topic Stop advancing best block and shutdown node if keypool drops below critical threshold
207 2017-08-10T19:02:08  <cfields> hi
208 2017-08-10T19:02:20  <jonasschnelli> jnewbery: is that the alternative for keypool topup for 0.15?
209 2017-08-10T19:02:23  <kanzure> hi.
210 2017-08-10T19:02:27  <wumpus> that replaced #11022 for 015.0?
211 2017-08-10T19:02:29  <gribble> https://github.com/bitcoin/bitcoin/issues/11022 | Basic keypool topup by jnewbery · Pull Request #11022 · bitcoin/bitcoin · GitHub
212 2017-08-10T19:02:55  <jonasschnelli> What was/is wrong with 11022?
213 2017-08-10T19:03:11  <achow101> jonasschnelli: 11022 is part of 10882 split into a separate pr
214 2017-08-10T19:03:16  <luke-jr> if the node shuts down, how can users recover? O.o
215 2017-08-10T19:03:18  <wumpus> it was getting too large IIRC
216 2017-08-10T19:03:29  <jnewbery> #10882 is the same as it has been for the last few days (mark-used if later key from keypool used, try to topup, stop node if can't, etc)
217 2017-08-10T19:03:32  <gribble> https://github.com/bitcoin/bitcoin/issues/10882 | Stop advancing best block and shutdown node if keypool drops below critical threshold by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
218 2017-08-10T19:03:41  <jonasschnelli> Ah. Same problem I had with my original PR. :/
219 2017-08-10T19:03:48  <jnewbery> I split #11022 off as the (hopefully) uncontroversial changes
220 2017-08-10T19:03:50  <gribble> https://github.com/bitcoin/bitcoin/issues/11022 | Basic keypool topup by jnewbery · Pull Request #11022 · bitcoin/bitcoin · GitHub
221 2017-08-10T19:04:12  <jnewbery> it just marks keys as used and tops up the keypool. No stop node/don't advance best block
222 2017-08-10T19:04:20  <gmaxwell> I was making the recommendation that we split out the part that marks used and refills the pool and get that merged. It is a strict improvement with no downsides or extra considerations.
223 2017-08-10T19:04:29  <gmaxwell> that one!
224 2017-08-10T19:04:42  <kanzure> (nick ping)
225 2017-08-10T19:04:55  <cfields> gmaxwell: can you do your hilite reminder? almost missed this
226 2017-08-10T19:04:58  <cfields> yes, that :)
227 2017-08-10T19:05:35  <wumpus> sounds like a good idea to factor out the critical, lower-risk changes so that it can still make 0.15.0rc1
228 2017-08-10T19:05:52  *** andytoshi has joined #bitcoin-core-dev
229 2017-08-10T19:05:53  <wumpus> though this does mean it needs a new review round
230 2017-08-10T19:06:00  <gmaxwell> I believe all the shutdown ones have unanswered questions.
231 2017-08-10T19:06:07  <wumpus> #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 jl2012 achow101
232 2017-08-10T19:06:21  <gmaxwell> cfields: mine seems to be broken. Thanks wumpus.
233 2017-08-10T19:06:25  <cfields> thanks
234 2017-08-10T19:06:31  <sipa> present
235 2017-08-10T19:06:36  <CodeShark> hello all
236 2017-08-10T19:06:42  <paveljanik> here
237 2017-08-10T19:06:55  <luke-jr> the startmeeting command should do it <.<
238 2017-08-10T19:06:58  <Murch> hullo
239 2017-08-10T19:07:04  <sipa> wumpus: the initial commits are the same
240 2017-08-10T19:07:06  <jnewbery> I thought we were very close with 10882, with ACKs from several people. Greg - could you ask your unanswered questions in the PR? Your comments have mostly been in IRC and it's difficult to keep track of what your current concerns are
241 2017-08-10T19:07:33  <wumpus> sipa: yes
242 2017-08-10T19:09:09  <wumpus> 10882 was kind of a miscommunication, I almost merged than when it turned out that there were still critical concerns with it
243 2017-08-10T19:09:21  *** sanada` has quit IRC
244 2017-08-10T19:09:40  <gmaxwell> jnewbery: it's not with your implementation specifically, but the correct behavior.  Shutting down on never-behind wallets who just drained their keypools (or never had a big keypool) is undesirable, but it doesn't appear to be possible to detect if a wallet had potentially been behind or not. (e.g. the only during rescan hurestic will fail in some places where the node and the wallet were both
245 2017-08-10T19:09:46  <gmaxwell> behind; as a simple example: backup your whole .bitcoin directory and later restor the backup)
246 2017-08-10T19:10:07  *** arowser has quit IRC
247 2017-08-10T19:10:18  <MarcoFalke> so 11022 is for 0.15 and 10882 should be removed from the milestone?
248 2017-08-10T19:10:20  <gmaxwell> restore*
249 2017-08-10T19:11:03  <wumpus> MarcoFalke: huh
250 2017-08-10T19:11:19  <luke-jr> IMO the correct behaviour would be an interface for pruning locks in general (usable by external wallets too), and track the best chain independently from where the UTXO set is. but this is way too complicated IMO. :/
251 2017-08-10T19:11:21  <wumpus> wasn't it the other way around?
252 2017-08-10T19:11:27  *** arowser has joined #bitcoin-core-dev
253 2017-08-10T19:11:39  <gmaxwell> MarcoFalke: that was my suggestion: merge the part we know is done. I don't think we can make a 10882 right now that won't result in strange behavior in some corner cases.
254 2017-08-10T19:11:40  <sipa> luke-jr: yes, that's the eventual goal - agree, but we don't have to go there in one step
255 2017-08-10T19:11:51  <jnewbery> wumpus : MarcoFalke has it right. 11022 is the simple subset
256 2017-08-10T19:11:53  <achow101> wumpus: 11022 is newer than 10882
257 2017-08-10T19:11:53  <wumpus> 11022 was removed from 0.15, and 10882 replaced it
258 2017-08-10T19:12:00  <gmaxwell> (at least not in short order)
259 2017-08-10T19:12:03  <wumpus> why and who did that then?
260 2017-08-10T19:12:07  * wumpus is really confused
261 2017-08-10T19:12:17  <gmaxwell> 11022 is a massive improvement and safty increase.
262 2017-08-10T19:12:26  <achow101> wumpus: 10882 was created, 11022 was split out from 10882
263 2017-08-10T19:12:27  <sipa> 11022 is 10882 without the shutdown logic
264 2017-08-10T19:12:30  <wumpus> what can we realistically finish in say, a week?
265 2017-08-10T19:12:47  <gmaxwell> wumpus: there was a thid PR you're thinking of 11022 is new, as of a few hours ago.
266 2017-08-10T19:12:58  <luke-jr> what if we just stop pruning, and let the normal low-disk-space shutdown do the job? ;)
267 2017-08-10T19:13:06  <sipa> luke-jr: die
268 2017-08-10T19:13:11  <luke-jr> :|
269 2017-08-10T19:13:13  <gmaxwell> luke-jr: pruning is also not the only issue.
270 2017-08-10T19:13:14  <wumpus> we can't continue adding things for 0.15 as that fix grows in scope more and more
271 2017-08-10T19:13:23  <sipa> wumpus: 11022 is a reduction in scope
272 2017-08-10T19:13:35  <sipa> i think 11022 can be ready to merge today or so
273 2017-08-10T19:13:38  <wumpus> as this all deals with something that is not a regression in 0.15, I'm starting to be really doubtful about this
274 2017-08-10T19:13:44  <gmaxwell> wumpus: that new PR radically reduced the scope, to the core part that has been in every PR so far.
275 2017-08-10T19:13:45  <luke-jr> gmaxwell: what am I missing?
276 2017-08-10T19:14:00  <sipa> *today
277 2017-08-10T19:14:12  <jnewbery> 11022 is ready now. It needs rereview by people, but it should be uncontroversial as it's a subset of what's already been ACKed
278 2017-08-10T19:14:57  <wumpus> ah yes I was confused with the other 'keypool topup' PR
279 2017-08-10T19:15:05  *** harrymm has quit IRC
280 2017-08-10T19:15:43  <MarcoFalke> ok, changed the milestones.
281 2017-08-10T19:15:54  <wumpus> thanks
282 2017-08-10T19:16:04  <gmaxwell> luke-jr: you could start by already reading the comments that are there.  Each version has failed in different corner cases.  I'll go update the PR with a longer list but after spending an hour talking to Pieter about it I'm just dispondent that it's all a mess that we won't fix quickly (again, not due to the code; but due to what behavior would actually be acceptable.)
283 2017-08-10T19:16:09  <jnewbery> full history: Jonas's PR was 10240. I rebased and cleaned that up as 10830. I then reduced the scope and incorporated a bunch of feedback in 10882. I've now reduced the scope again in 11022
284 2017-08-10T19:16:40  <wumpus> jnewbery: that's a painful history, thanks for sticking with it
285 2017-08-10T19:16:42  *** arowser has quit IRC
286 2017-08-10T19:17:12  <jnewbery> painful is a pretty accurate description!
287 2017-08-10T19:17:34  <jonasschnelli> ;-)
288 2017-08-10T19:17:43  <gmaxwell> luke-jr: but in general, versions that shutdown based on low keypool have a problem with existing wallets failing to work when users upgrade, and efforts to avoid that can create cases where we'll fail to force a shutdown when we should. (for example if the user backed up and restored a whole .bitcoin directory).
289 2017-08-10T19:17:56  <jnewbery> but let's try to get 11022 reviewed, and if gmaxwell could leave a nice long comment on 10882 about edge cases perhaps we can try again after 0.15
290 2017-08-10T19:18:05  *** arowser has joined #bitcoin-core-dev
291 2017-08-10T19:18:21  <gmaxwell> luke-jr: and I think now that a whole subfamily of suggestions I was making are just impossible to actually make work right, for which I am very sorry.
292 2017-08-10T19:18:35  <gmaxwell> jnewbery: will do
293 2017-08-10T19:18:46  <jnewbery> gmaxwell thanks
294 2017-08-10T19:19:32  <jnewbery> sipa ryanofsky morcos bluematt instagibbs reviewed 10882. Should be a straightforward task for them to rereview 11022
295 2017-08-10T19:19:39  <sipa> jnewbery: on it
296 2017-08-10T19:19:44  <instagibbs> gotcha
297 2017-08-10T19:19:45  <sipa> (right now)
298 2017-08-10T19:19:47  <wumpus> We can't rule all out edge cases. Tthe most important thing is that people upgrading won't automatically run into the issue because 0.15 sets a larger keypool default.
299 2017-08-10T19:20:10  <jnewbery> upgrade isn't an issue in 11022
300 2017-08-10T19:20:21  <wumpus> good!
301 2017-08-10T19:20:25  <instagibbs> will review today
302 2017-08-10T19:20:31  <jnewbery> (and actually isn't in 10882 as it's now implemented, but let's not get into that)
303 2017-08-10T19:20:47  <wumpus> do we have a test for that? :)
304 2017-08-10T19:21:11  <jnewbery> no, as far as I'm aware we have no upgrade tests. It'd be nice to have them
305 2017-08-10T19:21:41  <sipa> (gmaxwell went offline)
306 2017-08-10T19:21:57  <wumpus> no, we don't have any upgrade tests
307 2017-08-10T19:22:11  <instagibbs> jnewbery, to refresh memory: "Notably, it does not stop the node or prevent the best block from advancing if the keypool drops below a threshold" this is only in case of crypted?
308 2017-08-10T19:22:49  <sipa> instagibbs: my belief is that it'll just succesfully top up when unlocked
309 2017-08-10T19:23:24  <jnewbery> instagibbs, in 10882 we would only ever prevent best block advancing/stop node when top up was unsuccessful (ie encrypted locked wallet)
310 2017-08-10T19:23:39  <sipa> jnewbery: great
311 2017-08-10T19:23:39  <jnewbery> 11022 removes all prevent best block advancing/stop node behaviour
312 2017-08-10T19:23:57  <instagibbs> got it
313 2017-08-10T19:24:16  <wumpus> even better would it be if we had test cases for all of gmaxwell's edge cases
314 2017-08-10T19:24:18  <sipa> <gmaxwell> we can now have rescan instructions in our relwase notes: unlock the wallet and run rescan rpc
315 2017-08-10T19:24:19  <jnewbery> 11022 is really very simple. It has a bunch of refactor commits, but the functional change is fairly small
316 2017-08-10T19:24:54  * gmaxwell back
317 2017-08-10T19:25:20  <jnewbery> if we can get bitcoin-wallet-tool and offline topup into v0.16 we have a very nice way of sidestepping most of the problems I believe
318 2017-08-10T19:25:24  *** RoyceX has quit IRC
319 2017-08-10T19:25:44  <gmaxwell> jnewbery: sipa was just saying something like that to me.
320 2017-08-10T19:25:54  <sipa> jnewbery: alternatively, make the dynamic-load-wallet RPC fail in case of too low keypool, and make it take an optional passphrase
321 2017-08-10T19:25:55  <luke-jr> at least GUI can block on a passphrase
322 2017-08-10T19:26:00  <sipa> luke-jr: that too
323 2017-08-10T19:26:03  <jnewbery> yes!
324 2017-08-10T19:26:08  <luke-jr> sipa: oooh, that's an excellent approach for bitcoind
325 2017-08-10T19:26:23  <gmaxwell> but all to much for 0.15 now.  But at least 11022 massively narrows the window and creates a workaround.
326 2017-08-10T19:26:26  <sipa> agree
327 2017-08-10T19:27:19  <sipa> any other 0.15-related topics?
328 2017-08-10T19:27:44  <wumpus> although harder to implement there's no reason bitcoind couldn't block on a passphrase, justblock everything until a walletpassphrase command
329 2017-08-10T19:27:55  <jnewbery> yuck
330 2017-08-10T19:28:04  <luke-jr> if I prioritise rebasing the optional default-wallet, would it be considered for inclusion?
331 2017-08-10T19:28:05  <jnewbery> multiwallet?
332 2017-08-10T19:28:50  <luke-jr> wumpus: can RPC run without the node running?
333 2017-08-10T19:29:36  *** gribble has quit IRC
334 2017-08-10T19:29:53  <wumpus> luke-jr: in the same way the GUI can I guess
335 2017-08-10T19:30:09  <gmaxwell> jnewbery: I think that is less yuck than some other options.  Though really it's block until passphrase or the critical key level is changed.
336 2017-08-10T19:30:34  <wumpus> holding up RPC commands for a long time is bound to run into timeouts though
337 2017-08-10T19:30:53  <luke-jr> wumpus: we already throw exceptions during init
338 2017-08-10T19:31:04  <luke-jr> so we'd just need to make an exception for walletpassphrase
339 2017-08-10T19:31:13  <wumpus> yes it's kind of yuck, it's opposite from anything we want to do, with the wallet being able to block the node
340 2017-08-10T19:31:18  <luke-jr> the catch to this (and GUI prompting I guess) is that we need to load the wallet earlier
341 2017-08-10T19:32:17  <gmaxwell> longer term we'll need ways to rescan wallets when there is pruning.  E.g. PIR wallet queries. But that is a research project with a 1yr horizon or so.
342 2017-08-10T19:32:41  <gmaxwell> once we have something like this I think much of this mess goes away.
343 2017-08-10T19:32:50  <jnewbery> Are there any other circumstances where bitcoind waits for stdin? I think it might inadvertently break peoples assumptions
344 2017-08-10T19:32:52  <jonasschnelli> pir?
345 2017-08-10T19:33:07  <sipa> jonasschnelli: https://en.wikipedia.org/wiki/Private_information_retrieval
346 2017-08-10T19:33:08  <jnewbery> also it's messy if multiwallets are prompting for passphrases
347 2017-08-10T19:33:20  <jonasschnelli> thy
348 2017-08-10T19:33:32  <gmaxwell> jnewbery: not stdin, but accepting rpc connections and throwing the not ready yet error for all but walletpassphrase.
349 2017-08-10T19:33:45  <gmaxwell> (like we do when loading the block index)
350 2017-08-10T19:34:16  <jnewbery> oh ok, yeah that's not so bad
351 2017-08-10T19:34:27  <gmaxwell> now I understand the yuck better. :)
352 2017-08-10T19:34:27  <jnewbery> but to be clear, not for 0.15 :)
353 2017-08-10T19:34:31  <gmaxwell> yes.
354 2017-08-10T19:34:32  <wumpus> luke-jr: you mean going back into warmup mode? hmm then all clients would have to handle that
355 2017-08-10T19:34:43  *** alreadylate has quit IRC
356 2017-08-10T19:35:03  <wumpus> oh certainly not stdin
357 2017-08-10T19:35:03  <luke-jr> wumpus: I mean never leaving warmup mode :p
358 2017-08-10T19:35:12  <wumpus> luke-jr: that'd make sense
359 2017-08-10T19:35:42  <wumpus> luke-jr: I somehow assumed it was something that could happen at runtime
360 2017-08-10T19:35:54  <wumpus> anyhow, yes not for 0.15
361 2017-08-10T19:36:06  <luke-jr> it probably can
362 2017-08-10T19:36:08  *** gribble has joined #bitcoin-core-dev
363 2017-08-10T19:36:17  <luke-jr> keypool size is still configurable I assume
364 2017-08-10T19:36:29  <wumpus> but for dynamic wallet loading optionally passing the passphrase on load makes sense
365 2017-08-10T19:37:23  <wumpus> ok - any other topics?
366 2017-08-10T19:37:25  <jnewbery> Being able to run commands on load was my main motivation for #10740 . Unlocking and topping-up keypool fits well with that
367 2017-08-10T19:38:09  <gmaxwell> I'd like to remind people that we all need to be testing on master hard right now. :)
368 2017-08-10T19:38:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [WIP] [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
369 2017-08-10T19:38:45  <wumpus> if only we had rc1 out everyone could be testing on rc1 :)
370 2017-08-10T19:40:10  <sdaftuar> where are we on the segwit address format?
371 2017-08-10T19:40:21  <wumpus> #topic segwit address format
372 2017-08-10T19:41:02  <sipa> sdaftuar: https://github.com/sipa/bech32/pull/21
373 2017-08-10T19:41:19  <sipa> almost done with a C++ reference version (though gmaxwell keeps finding untested cases)
374 2017-08-10T19:41:29  *** JackH has quit IRC
375 2017-08-10T19:41:30  <sipa> when that's done, i'll submit a PR to core to integrate it
376 2017-08-10T19:41:34  <sdaftuar> great!
377 2017-08-10T19:41:39  <jonasschnelli> nice
378 2017-08-10T19:41:39  <cfields> sipa: great. will review that.
379 2017-08-10T19:42:02  <sipa> which will need some refactor to get rid of CBitcoinAddress (i'm sorry for ever introducing that... there is no point for that to be a separate class...)
380 2017-08-10T19:42:25  <Chris_Stewart_5> Is this going to be in 0.15.0 or 0.15.1?
381 2017-08-10T19:42:35  <cfields> sipa: maybe best to just cram it into CBitcoinAddress first for easy 0.15 backport ?
382 2017-08-10T19:42:40  <sdaftuar> not 0.15.0
383 2017-08-10T19:42:43  <wumpus> certainly not 0.15.0
384 2017-08-10T19:42:44  <Chris_Stewart_5> ok good
385 2017-08-10T19:42:49  <jonasschnelli> Chris_Stewart_5: not in 0.15.0 maybe in 0.15.SW
386 2017-08-10T19:42:59  <sipa> cfields: i'll see what i can do
387 2017-08-10T19:43:44  <cfields> ok
388 2017-08-10T19:44:22  <wumpus> any other topics?
389 2017-08-10T19:44:25  <CodeShark> I have a quick one
390 2017-08-10T19:44:45  <luke-jr> the hardest topics to discuss are the ones that are not disclosed. :P
391 2017-08-10T19:45:04  <CodeShark> I would need to rebase, but now that SegWit is activating I'd really like to merge https://github.com/bitcoin/bitcoin/pull/10350
392 2017-08-10T19:46:03  <wumpus> #topic Added support for MSG_FILTERED_WITNESS_BLOCK messages
393 2017-08-10T19:47:00  <jonasschnelli> Wound't that require a bip first?
394 2017-08-10T19:47:13  *** jimpo has quit IRC
395 2017-08-10T19:47:17  <CodeShark> is it really worth the effort?
396 2017-08-10T19:47:23  <CodeShark> it's getting deprecated eventually
397 2017-08-10T19:47:26  <CodeShark> probably pretty soon
398 2017-08-10T19:47:33  <gmaxwell> well obviously not merged now, but perhaps in the .SW release. It needs a bip. unconditionally but it would be a trivial spec.
399 2017-08-10T19:47:41  <CodeShark> ok
400 2017-08-10T19:47:45  <gmaxwell> I can help with the bip.
401 2017-08-10T19:47:53  <sipa> it doesn't look like it's too much work to add a witness proof
402 2017-08-10T19:47:54  <wumpus> yeah it's a network protocol change so it needs some kind of BIP
403 2017-08-10T19:47:55  <gmaxwell> (show of good will, since I really dislike the feature. :) )
404 2017-08-10T19:48:00  <CodeShark> thanks, gmaxwell
405 2017-08-10T19:48:20  <wumpus> if only to be able to refer to it in bips.md and such
406 2017-08-10T19:48:26  <gmaxwell> (not due to it itself, but due to increasing the scope of BIP37)
407 2017-08-10T19:48:33  <jonasschnelli> CodeShark: why would it get deprecated (you mean dep. bip37 in favor of client side filtering)?
408 2017-08-10T19:48:39  <CodeShark> jonasschnelli: yes
409 2017-08-10T19:48:43  <luke-jr> if it's literally only for short-term use by mSIGNA, I'm not sure it strictly NEEDS a BIP.
410 2017-08-10T19:48:54  <gmaxwell> luke-jr: it's trivial to specify however.
411 2017-08-10T19:48:56  <luke-jr> sure
412 2017-08-10T19:49:05  <CodeShark> yeah, probably should stick to process
413 2017-08-10T19:49:08  <wumpus> why not? it's good to have some kind of documentation
414 2017-08-10T19:49:18  <gmaxwell> and the spec can also do things like tell people it is intended to be short lived.
415 2017-08-10T19:49:20  <jonasschnelli> I guess there are still usecases for BIP37 once BIP150 is life (trusted peers)
416 2017-08-10T19:49:21  <wumpus> others might want to use it too
417 2017-08-10T19:49:46  <luke-jr> CodeShark: if you can rebase it quickly, maybe we can throw it in Knots until it's ready for Core
418 2017-08-10T19:49:58  <CodeShark> sure :)
419 2017-08-10T19:49:59  <jonasschnelli> I'm strongly advice for a BIP. Other may be interested and we don't want more specification within the code.
420 2017-08-10T19:50:07  <gmaxwell> jonasschnelli: you can still do better things for that case, like send them the addresses explicitly.
421 2017-08-10T19:50:25  <jonasschnelli> gmaxwell: Yes. But would require more work to do. :)
422 2017-08-10T19:50:27  <sipa> i'd really like to see the addition of witness proofs, though - i understand that for your exact use case (which implies a trusted full node) that's unnecessary, but i don't think we should go that route in protocol extensions
423 2017-08-10T19:50:42  <wumpus> gmaxwell: heh yes, if the connection is encrypted and the peer is trusted, why not, why even bother with a bloom filter
424 2017-08-10T19:50:56  <gmaxwell> in any case basically any argument against doing a BIP is an argument for one too... it's trivial.  it's intended to be short lived (BIP would tell people that).
425 2017-08-10T19:50:58  *** Cory has quit IRC
426 2017-08-10T19:51:10  <gmaxwell> sipa: it would be a trivial change to make it do the witness proofs, no? just root on the other tree.
427 2017-08-10T19:51:29  <sipa> gmaxwell: and give the coinbase, and normal merkle proof for the coinbase
428 2017-08-10T19:51:36  <CodeShark> sipa: I am still not convinced it's worth the effort to add the witness proof
429 2017-08-10T19:51:42  <wumpus> then again BIP37 works now, that's a point, step-by-step evolution usually means that things keep moving instead of being blocked by big moves
430 2017-08-10T19:51:52  <CodeShark> the coinbase issue means we need an entire new data structure
431 2017-08-10T19:51:53  <sipa> CodeShark: then i would be opposed to supporting it
432 2017-08-10T19:52:06  <sipa> CodeShark: use RPC instead
433 2017-08-10T19:52:11  <CodeShark> huh?!
434 2017-08-10T19:52:14  <gmaxwell> CodeShark: it's just a existing thing for the coinbase, and then one more rooted in it.
435 2017-08-10T19:52:54  <CodeShark> it already takes me hours to sync back just a few weeks
436 2017-08-10T19:53:00  <CodeShark> RPC would mean it takes forever
437 2017-08-10T19:53:03  <sipa> CodeShark: you're asking to add a feature, available to every P2P client, which can only be safely used in a trusted setting
438 2017-08-10T19:53:03  <luke-jr> why would you need a witness proof in this case anyway?
439 2017-08-10T19:53:11  *** SkynetS has joined #bitcoin-core-dev
440 2017-08-10T19:53:14  <CodeShark> sipa: ah, I see your point
441 2017-08-10T19:53:15  <sipa> luke-jr: because the full node can lie
442 2017-08-10T19:53:37  <luke-jr> sipa: about what? these peers don't have any need for the witness data at all
443 2017-08-10T19:53:38  <CodeShark> agree that the trusted mode is distinct from p2p, but the HTTP server approach just won't do ;)
444 2017-08-10T19:53:45  <sipa> luke-jr: read the PR
445 2017-08-10T19:53:55  <wumpus> sipa has a good point, if it's to be on the P2P network, it has to be possible to use it untrusted
446 2017-08-10T19:53:57  <sipa> luke-jr: CodeShark needs it to determine which subset of multisig signers spent the coins
447 2017-08-10T19:54:11  <luke-jr> oh!
448 2017-08-10T19:54:11  *** jimmysong has joined #bitcoin-core-dev
449 2017-08-10T19:54:11  *** SopaXorzTaker has quit IRC
450 2017-08-10T19:54:13  <wumpus> if not you'd have to wait for BIP150 (authentication)
451 2017-08-10T19:54:26  <wumpus> and allow it to authenticated peers only
452 2017-08-10T19:54:42  <sipa> yes, that would be private extensions easier
453 2017-08-10T19:55:14  <sipa> CodeShark: but honestly, i don't think adding a proof for the witnesses is that hard; just send two structures (one with normal proof for coinbase, one with witness proof for the rest)
454 2017-08-10T19:55:37  <CodeShark> it requires a lot of additional clientside modifications as well, I'd rather focus on clientside filtering
455 2017-08-10T19:55:44  <gmaxwell> yea, if we had BIP150 I wouldn't mind random extensions there even without bips. if you're only using it between trusted adjcencies the criteria is different.
456 2017-08-10T19:56:49  *** Pasha has joined #bitcoin-core-dev
457 2017-08-10T19:57:13  <CodeShark> not saying it's hard - just time I think would be better invested elsewhere
458 2017-08-10T19:57:26  <sipa> yes, like helping with client side filtering :)
459 2017-08-10T19:57:31  <CodeShark> indeed
460 2017-08-10T19:57:35  *** chjj has quit IRC
461 2017-08-10T19:57:39  <sdaftuar> also though, if you intend to only use something on trusted nodes you could just carry a custom patch, no?  i mean, if there's not much other demand for this extension.
462 2017-08-10T19:57:50  <achow101> does client side filtering have a bip?
463 2017-08-10T19:57:55  <jonasschnelli> Could you not impelement directly the client side filtering?
464 2017-08-10T19:58:07  <sipa> jonasschnelli: it's a nontrivial effort
465 2017-08-10T19:58:11  <jonasschnelli> achow101: roasbeef hasn't opened the PR (last state is the ML post)
466 2017-08-10T19:58:14  <sipa> needs stored bloom filters for all blocks on disk etc
467 2017-08-10T19:58:33  <wumpus> achow101: not afaik
468 2017-08-10T19:59:00  <jonasschnelli> sipa: Yes. But a long term strategy and there are a couple of people willing to contribute
469 2017-08-10T19:59:05  <sipa> sure
470 2017-08-10T19:59:05  <luke-jr> I assumed jonasschnelli meant implement BIP37 client-side
471 2017-08-10T19:59:20  <jonasschnelli> not bip37
472 2017-08-10T19:59:20  <CodeShark> lol, BIP37 needs to eventually die
473 2017-08-10T19:59:24  <gmaxwell> I don't thin the spec has been updated to eliminate the divisions yet.
474 2017-08-10T20:00:00  *** Pasha is now known as Cory
475 2017-08-10T20:00:10  <wumpus> meeting time is over
476 2017-08-10T20:00:18  *** chjj has joined #bitcoin-core-dev
477 2017-08-10T20:00:19  <wumpus> #endmeeting
478 2017-08-10T20:00:19  <lightningbot> Meeting ended Thu Aug 10 20:00:18 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
479 2017-08-10T20:00:19  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.html
480 2017-08-10T20:00:19  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.txt
481 2017-08-10T20:00:19  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-10-19.00.log.html
482 2017-08-10T20:00:22  <luke-jr> but I just pinged roasbeef for the meeting :P
483 2017-08-10T20:00:36  <wumpus> :P
484 2017-08-10T20:00:36  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11025: qa: Fix inv race in example_test (master...Mf1708-qaInvExampleTest) https://github.com/bitcoin/bitcoin/pull/11025
485 2017-08-10T20:00:40  <roasbeef> achow101: there's a BIP draft, but I've been side tracked on another project. I need to incorporate suggestions for optimizations, then wrap up some TODO's and i'll officially request a #
486 2017-08-10T20:00:54  <roasbeef> will be able to finish it up in a week or two
487 2017-08-10T20:01:04  <jonasschnelli> roasbeef: Thanks for working on this!
488 2017-08-10T20:01:18  <achow101> roasbeef: cool
489 2017-08-10T20:01:18  <CodeShark> yes, roasbeef  +1
490 2017-08-10T20:01:37  *** andytoshi has left #bitcoin-core-dev
491 2017-08-10T20:05:54  *** alreadylate has joined #bitcoin-core-dev
492 2017-08-10T20:06:26  *** alreadylate has quit IRC
493 2017-08-10T20:07:28  <instagibbs> roasbeef, does the other project rhyme with brightening
494 2017-08-10T20:09:02  <roasbeef> something that just occured to me is also that it would be possible for pruned nodes to still serve light clients, assuming they still keep the filters on disk
495 2017-08-10T20:09:03  <sipa> instagibbs: not in my understanding of english pronounciation
496 2017-08-10T20:09:11  <roasbeef> instagibbs: maaaybe
497 2017-08-10T20:10:28  *** chjj has quit IRC
498 2017-08-10T20:11:40  *** chjj has joined #bitcoin-core-dev
499 2017-08-10T20:26:27  *** chjj has quit IRC
500 2017-08-10T20:29:27  *** chjj has joined #bitcoin-core-dev
501 2017-08-10T20:44:59  <bitcoin-git> [bitcoin] luke-jr opened pull request #11026: Bugfix: Use testnet RequireStandard for -acceptnonstdtxn default (master...bugfix_acceptnonstd_def) https://github.com/bitcoin/bitcoin/pull/11026
502 2017-08-10T20:55:10  *** Dyaheon has quit IRC
503 2017-08-10T20:56:29  *** Dyaheon has joined #bitcoin-core-dev
504 2017-08-10T20:58:07  *** rjak2 has joined #bitcoin-core-dev
505 2017-08-10T20:58:07  *** rjak has quit IRC
506 2017-08-10T20:58:20  *** rjak2 is now known as rjak
507 2017-08-10T21:32:33  *** jimpo has joined #bitcoin-core-dev
508 2017-08-10T21:35:17  *** corinrose_ has quit IRC
509 2017-08-10T21:53:37  *** Yogaqueef has quit IRC
510 2017-08-10T22:07:13  *** arubi has quit IRC
511 2017-08-10T22:09:02  *** Chris_Stewart_5 has quit IRC
512 2017-08-10T22:28:16  *** chjj has quit IRC
513 2017-08-10T22:30:23  *** chjj has joined #bitcoin-core-dev
514 2017-08-10T22:33:48  *** justanotheruser has joined #bitcoin-core-dev
515 2017-08-10T22:34:33  *** chjj has quit IRC
516 2017-08-10T22:34:55  *** chjj has joined #bitcoin-core-dev
517 2017-08-10T22:36:36  *** Dizzle has quit IRC
518 2017-08-10T22:41:37  *** jimpo has quit IRC
519 2017-08-10T22:42:48  *** jimpo has joined #bitcoin-core-dev
520 2017-08-10T22:49:05  *** vicenteH has quit IRC
521 2017-08-10T22:56:10  *** jimmysong has quit IRC
522 2017-08-10T22:57:31  *** smill has quit IRC
523 2017-08-10T23:01:27  *** echonaut has quit IRC
524 2017-08-10T23:01:37  *** echonaut has joined #bitcoin-core-dev
525 2017-08-10T23:02:26  *** abpa has quit IRC
526 2017-08-10T23:09:03  <bitcoin-git> [bitcoin] achow101 opened pull request #11027: [RPC] Only return hex field once in getrawtransaction (master...fix-getrawtx) https://github.com/bitcoin/bitcoin/pull/11027
527 2017-08-10T23:26:45  *** goldstar has joined #bitcoin-core-dev
528 2017-08-10T23:27:12  *** LeMiner has quit IRC
529 2017-08-10T23:28:33  *** LeMiner has joined #bitcoin-core-dev
530 2017-08-10T23:29:04  *** justanotheruser has quit IRC
531 2017-08-10T23:29:59  *** RoyceX has joined #bitcoin-core-dev
532 2017-08-10T23:31:46  *** Aaronvan_ has joined #bitcoin-core-dev
533 2017-08-10T23:33:24  <sipa> happy block 0x75300 everyone
534 2017-08-10T23:34:01  <sipa> it doesn't look at good in hex :(
535 2017-08-10T23:35:05  *** AaronvanW has quit IRC
536 2017-08-10T23:40:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
537 2017-08-10T23:40:26  *** miknotauro has quit IRC
538 2017-08-10T23:50:19  *** Chris_Stewart_5 has quit IRC
539 2017-08-10T23:54:04  *** RoyceX has quit IRC
540 2017-08-10T23:58:50  <luke-jr> XD