1 2016-11-17T00:37:58  *** adiabat has joined #bitcoin-core-dev
  2 2016-11-17T00:39:26  <jtimon> petertodd: regarding your last comment on the removign ISM thread...do you mean restoring ISM and then adding your new rule as a SF?
  3 2016-11-17T00:40:43  <jtimon> is the point to remove ISM later with a coordinated HF?
  4 2016-11-17T00:44:34  <BlueMatt> -rw------- 1 matt matt 1.7T Nov 16 16:44 /home/matt/.bitcoin/debug.log
  5 2016-11-17T00:44:36  <BlueMatt> lol
  6 2016-11-17T01:31:38  *** shangzhou has quit IRC
  7 2016-11-17T01:42:38  *** Ylbam has quit IRC
  8 2016-11-17T01:44:11  *** shangzhou has joined #bitcoin-core-dev
  9 2016-11-17T01:46:17  *** ybit has joined #bitcoin-core-dev
 10 2016-11-17T01:49:14  *** abpa has quit IRC
 11 2016-11-17T01:49:46  *** abpa has joined #bitcoin-core-dev
 12 2016-11-17T01:52:12  <shangzhou> gmaxwell: i did some search this morning at baidu. Searched "c1726ccc50635795c942c7d7e51d979c4f83a3d17f8982e9d02a114a15fef419" only one result (a thread http://8btc.com/thread-41510-1-5.html) someone use Avast complain that bitcoin 0.13.1 win exe downloaded from bitcoin.org was blocked by the avast. Search something like "bitcoin 0.13.1 win exe" top one is
 13 2016-11-17T01:52:12  <shangzhou> bitcoin.org's download link.
 14 2016-11-17T01:54:01  *** abpa has quit IRC
 15 2016-11-17T02:22:16  <bitcoin-git> [bitcoin] Christewart opened pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174
 16 2016-11-17T02:59:52  *** DigiByteDev has joined #bitcoin-core-dev
 17 2016-11-17T03:00:53  *** Giszmo has quit IRC
 18 2016-11-17T03:14:39  *** veleiro has joined #bitcoin-core-dev
 19 2016-11-17T03:17:20  <veleiro> herro, tag release 13.1 on debian stretch 'make' gives me this: https://paste.debian.net/plain/896347 wat wrong :(
 20 2016-11-17T03:28:51  *** btcdrak has joined #bitcoin-core-dev
 21 2016-11-17T03:47:42  *** Chris_Stewart_5 has quit IRC
 22 2016-11-17T03:56:37  *** DigiByteDev has quit IRC
 23 2016-11-17T04:01:38  *** shangzhou has quit IRC
 24 2016-11-17T04:07:40  *** nickler has quit IRC
 25 2016-11-17T04:11:46  <sipa> veleiro: my guess is that you have too little memory
 26 2016-11-17T04:28:28  <veleiro> sipa: youre probably right. i'm so sure to doing make -j4? it uses too many resources is my guess
 27 2016-11-17T04:28:45  <veleiro> i just did a normal 'make' and it was a success..
 28 2016-11-17T04:29:12  <veleiro> s/i'm so sure/i'm so use
 29 2016-11-17T04:29:28  <veleiro> thanks~
 30 2016-11-17T04:39:40  <luke-jr> #bitcoin is the support channel btw
 31 2016-11-17T04:44:30  <veleiro> sorry luke-jr, its a big community now days. i didnt mean to bloat this chan
 32 2016-11-17T04:45:37  <luke-jr> np, just clarifying for next time
 33 2016-11-17T04:46:44  *** nickler has joined #bitcoin-core-dev
 34 2016-11-17T04:47:54  *** PaulCapestany has quit IRC
 35 2016-11-17T04:49:41  <bitcoin-git> [bitcoin] mruddy opened pull request #9175: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175
 36 2016-11-17T04:49:46  *** PaulCapestany has joined #bitcoin-core-dev
 37 2016-11-17T05:08:25  *** aalex has joined #bitcoin-core-dev
 38 2016-11-17T05:12:34  *** DigiByteDev has joined #bitcoin-core-dev
 39 2016-11-17T05:15:04  *** aalex has quit IRC
 40 2016-11-17T06:25:19  *** rabidus has quit IRC
 41 2016-11-17T06:32:56  *** dgenr8 has joined #bitcoin-core-dev
 42 2016-11-17T06:45:46  <bitcoin-git> [bitcoin] jtimon opened pull request #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts() (master...0.13-chainparams-loadblockindexguts) https://github.com/bitcoin/bitcoin/pull/9176
 43 2016-11-17T06:57:48  *** Ylbam has joined #bitcoin-core-dev
 44 2016-11-17T07:01:07  <bitcoin-git> [bitcoin] jtimon opened pull request #9177: NOMERGE: WIP: Support block signed custom testchains (master...0.13-blocksign) https://github.com/bitcoin/bitcoin/pull/9177
 45 2016-11-17T07:01:36  *** rabidus has joined #bitcoin-core-dev
 46 2016-11-17T07:12:14  *** aalex has joined #bitcoin-core-dev
 47 2016-11-17T07:12:14  *** tunafizz has quit IRC
 48 2016-11-17T07:19:43  *** aalex has quit IRC
 49 2016-11-17T07:21:44  *** tunafizz has joined #bitcoin-core-dev
 50 2016-11-17T07:24:20  *** tunafizz has quit IRC
 51 2016-11-17T07:26:53  *** roidster has quit IRC
 52 2016-11-17T07:28:37  *** tunafizz has joined #bitcoin-core-dev
 53 2016-11-17T07:32:37  *** tunafizz has quit IRC
 54 2016-11-17T07:38:42  *** MarcoFalke has joined #bitcoin-core-dev
 55 2016-11-17T07:43:18  *** tunafizz has joined #bitcoin-core-dev
 56 2016-11-17T07:48:12  *** tunafizz has quit IRC
 57 2016-11-17T07:49:11  *** tunafizz has joined #bitcoin-core-dev
 58 2016-11-17T08:16:06  *** droark has quit IRC
 59 2016-11-17T08:16:38  *** tunafizz has quit IRC
 60 2016-11-17T08:17:33  *** tunafizz has joined #bitcoin-core-dev
 61 2016-11-17T08:18:28  *** MarcoFalke has quit IRC
 62 2016-11-17T08:27:49  *** tunafizz has quit IRC
 63 2016-11-17T08:28:11  *** tunafizz has joined #bitcoin-core-dev
 64 2016-11-17T08:30:42  *** rubensayshi has joined #bitcoin-core-dev
 65 2016-11-17T08:32:34  *** tunafizz has quit IRC
 66 2016-11-17T08:34:57  *** tunafizz has joined #bitcoin-core-dev
 67 2016-11-17T08:39:37  *** tunafizz has quit IRC
 68 2016-11-17T08:40:51  *** tunafizz has joined #bitcoin-core-dev
 69 2016-11-17T09:04:24  *** tunafizz has quit IRC
 70 2016-11-17T09:09:11  *** Guyver2 has joined #bitcoin-core-dev
 71 2016-11-17T09:11:14  *** tunafizz has joined #bitcoin-core-dev
 72 2016-11-17T09:19:30  *** tunafizz has quit IRC
 73 2016-11-17T09:20:58  *** tunafizz has joined #bitcoin-core-dev
 74 2016-11-17T09:26:00  *** AaronvanW has quit IRC
 75 2016-11-17T09:29:22  <petertodd> jtimon: no, I mean, making chains other than the existing one invalid unless they follow the new rules
 76 2016-11-17T09:29:33  *** AaronvanW has joined #bitcoin-core-dev
 77 2016-11-17T09:29:33  *** AaronvanW has quit IRC
 78 2016-11-17T09:29:33  *** AaronvanW has joined #bitcoin-core-dev
 79 2016-11-17T09:29:52  <petertodd> jtimon: that still allows reorgs - it's not a checkpoint - but allows you to remove all the ISM logic.
 80 2016-11-17T09:30:37  <petertodd> jtimon: of course, by "allows reorgs" - it mainly only allows truly massive reorgs, but I think that's sufficient to keep this from being a checkpoint
 81 2016-11-17T09:33:18  *** tunafizz has quit IRC
 82 2016-11-17T09:33:36  *** tunafizz has joined #bitcoin-core-dev
 83 2016-11-17T09:38:19  *** JackH has joined #bitcoin-core-dev
 84 2016-11-17T09:43:29  *** laurentmt has joined #bitcoin-core-dev
 85 2016-11-17T09:43:50  *** laurentmt has quit IRC
 86 2016-11-17T09:47:39  *** DigiByteDev has quit IRC
 87 2016-11-17T09:57:39  *** tunafizz has quit IRC
 88 2016-11-17T10:00:48  *** tunafizz has joined #bitcoin-core-dev
 89 2016-11-17T10:07:54  *** aalex has joined #bitcoin-core-dev
 90 2016-11-17T10:07:56  *** tunafizz has quit IRC
 91 2016-11-17T10:08:35  *** tunafizz has joined #bitcoin-core-dev
 92 2016-11-17T10:14:34  *** aalex has quit IRC
 93 2016-11-17T10:24:55  *** arowser has quit IRC
 94 2016-11-17T10:26:29  *** arowser has joined #bitcoin-core-dev
 95 2016-11-17T10:29:25  *** jtimon has quit IRC
 96 2016-11-17T10:34:45  *** MarcoFalke_web has joined #bitcoin-core-dev
 97 2016-11-17T10:43:27  *** sanada has quit IRC
 98 2016-11-17T10:44:04  *** sanada has joined #bitcoin-core-dev
 99 2016-11-17T10:47:18  *** tunafizz has quit IRC
100 2016-11-17T10:48:53  *** tunafizz has joined #bitcoin-core-dev
101 2016-11-17T10:53:11  *** DigiByteDev has joined #bitcoin-core-dev
102 2016-11-17T10:53:15  *** tunafizz has quit IRC
103 2016-11-17T10:54:16  *** tunafizz has joined #bitcoin-core-dev
104 2016-11-17T10:56:04  *** DigiByteDev has quit IRC
105 2016-11-17T11:07:48  *** tunafizz has quit IRC
106 2016-11-17T11:09:41  *** tunafizz has joined #bitcoin-core-dev
107 2016-11-17T11:27:52  *** tunafizz has quit IRC
108 2016-11-17T11:28:21  *** tunafizz has joined #bitcoin-core-dev
109 2016-11-17T11:49:43  *** DigiByteDev has joined #bitcoin-core-dev
110 2016-11-17T11:49:46  <morcos> petertodd: yes that is what i was saying as well, i just don't know how to do that efficiently
111 2016-11-17T11:50:50  *** DigiByteDev has quit IRC
112 2016-11-17T11:56:22  *** tunafizz has quit IRC
113 2016-11-17T11:57:14  *** tunafizz has joined #bitcoin-core-dev
114 2016-11-17T12:23:43  *** Guyver2__ has joined #bitcoin-core-dev
115 2016-11-17T12:26:26  *** Guyver2 has quit IRC
116 2016-11-17T12:26:27  *** Guyver2__ is now known as Guyver2
117 2016-11-17T12:41:09  *** shesek has quit IRC
118 2016-11-17T12:41:35  *** Guyver2__ has joined #bitcoin-core-dev
119 2016-11-17T12:45:02  *** Guyver2 has quit IRC
120 2016-11-17T12:45:09  *** Guyver2__ is now known as Guyver2
121 2016-11-17T12:54:55  *** shesek has joined #bitcoin-core-dev
122 2016-11-17T12:58:05  <wumpus> what is the proper way to pass arguments to the secp256k1 configure script that is invoked by bitcoin's?
123 2016-11-17T13:01:48  *** windsok has quit IRC
124 2016-11-17T13:03:16  <wumpus> oh nm I can just pass "--with-asm=arm --enable-experimental" to the outer configure and it works. doh
125 2016-11-17T13:04:11  <wumpus> ... I'd been manually patching configure.ac all that time :-)
126 2016-11-17T13:06:46  *** cryptapus has joined #bitcoin-core-dev
127 2016-11-17T13:06:46  *** cryptapus has joined #bitcoin-core-dev
128 2016-11-17T13:07:50  <luke-jr> hehe
129 2016-11-17T13:09:02  <wumpus> never tried as I expected it to croak on unknown arguments
130 2016-11-17T13:10:00  <luke-jr> there's an argument to make it not even warn :D
131 2016-11-17T13:10:24  *** windsok has joined #bitcoin-core-dev
132 2016-11-17T13:11:04  *** tunafizz has quit IRC
133 2016-11-17T13:11:25  *** tunafizz has joined #bitcoin-core-dev
134 2016-11-17T13:15:30  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cb2ed300a89e...f6db48ad1c8f
135 2016-11-17T13:15:31  <bitcoin-git> bitcoin/master 5f274a1 jnewbery: log block size and weight correctly.
136 2016-11-17T13:15:31  <bitcoin-git> bitcoin/master f6db48a Wladimir J. van der Laan: Merge #8838: Calculate size and weight of block correctly in CreateNewBlock()...
137 2016-11-17T13:19:18  <bitcoin-git> [bitcoin] Christewart closed pull request #9174: Modifying incorrect comments from BIP66 -> BIP62 (master...master) https://github.com/bitcoin/bitcoin/pull/9174
138 2016-11-17T13:25:57  *** aalex has joined #bitcoin-core-dev
139 2016-11-17T13:26:24  *** tunafizz has quit IRC
140 2016-11-17T13:27:33  *** tunafizz has joined #bitcoin-core-dev
141 2016-11-17T13:32:21  *** tunafizz has quit IRC
142 2016-11-17T13:33:25  *** aalex has quit IRC
143 2016-11-17T13:34:23  *** tunafizz has joined #bitcoin-core-dev
144 2016-11-17T13:35:45  *** MarcoFalke has joined #bitcoin-core-dev
145 2016-11-17T13:39:29  *** roidster has joined #bitcoin-core-dev
146 2016-11-17T13:39:38  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (master...Mf1611-doc) https://github.com/bitcoin/bitcoin/pull/9178
147 2016-11-17T13:40:32  *** cryptapus_afk has quit IRC
148 2016-11-17T13:49:57  *** MarcoFalke has quit IRC
149 2016-11-17T13:51:15  *** Chris_Stewart_5 has joined #bitcoin-core-dev
150 2016-11-17T13:51:59  *** cryptapus_afk has joined #bitcoin-core-dev
151 2016-11-17T13:51:59  *** cryptapus_afk has joined #bitcoin-core-dev
152 2016-11-17T14:10:21  *** DigiByteDev has joined #bitcoin-core-dev
153 2016-11-17T14:20:38  *** Chris_Stewart_5 has quit IRC
154 2016-11-17T14:24:47  *** shesek has quit IRC
155 2016-11-17T14:29:26  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6db48ad1c8f...aaca05c0dabd
156 2016-11-17T14:29:26  <bitcoin-git> bitcoin/master fa63ee8 MarcoFalke: Doxygen: Set PROJECT_NAME = "Bitcoin Core"
157 2016-11-17T14:29:26  <bitcoin-git> bitcoin/master aaca05c Wladimir J. van der Laan: Merge #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core"...
158 2016-11-17T14:29:41  <bitcoin-git> [bitcoin] laanwj closed pull request #9178: Doxygen: Set PROJECT_NAME = "Bitcoin Core" (master...Mf1611-doc) https://github.com/bitcoin/bitcoin/pull/9178
159 2016-11-17T14:30:46  *** MarcoFalke_web has quit IRC
160 2016-11-17T14:32:39  *** MarcoFalke_web has joined #bitcoin-core-dev
161 2016-11-17T14:35:12  *** harrymm has quit IRC
162 2016-11-17T14:38:06  *** harrymm has joined #bitcoin-core-dev
163 2016-11-17T14:38:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
164 2016-11-17T14:44:37  *** shesek has joined #bitcoin-core-dev
165 2016-11-17T14:45:21  *** veleiro has quit IRC
166 2016-11-17T14:48:41  *** aalex has joined #bitcoin-core-dev
167 2016-11-17T14:50:52  <instagibbs> Chris_Stewart_5, so malleability in this context is not txid malleability
168 2016-11-17T14:51:12  <instagibbs> rather witness malleability. Some joker relayer could stuff transactions with junk data and the transaction is still valid
169 2016-11-17T14:51:48  *** Giszmo has joined #bitcoin-core-dev
170 2016-11-17T14:53:48  *** To7 has quit IRC
171 2016-11-17T14:54:52  <Chris_Stewart_5> instagibbs: I still don't understand the 'empty byte array' thing, and I also can't seem to find where this empty byte array is pushed onto the stack in the codebase
172 2016-11-17T14:55:12  <Chris_Stewart_5> I get why we have all the other checks inside of CheckSignatureEncoding: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L185
173 2016-11-17T14:56:24  <Chris_Stewart_5> The way I read BIP146, it's almost saying that you cannot place a OP_FALSE onto the stack unless OP_CHECKSIG had as input an empty byte array as a signature, but of course that doesn't make sense
174 2016-11-17T14:56:42  <Chris_Stewart_5> https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#nullfail
175 2016-11-17T14:58:37  *** cannon-c has joined #bitcoin-core-dev
176 2016-11-17T14:58:56  *** cannon-c has left #bitcoin-core-dev
177 2016-11-17T15:06:28  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/aaca05c0dabd...a8b2a82618be
178 2016-11-17T15:06:28  <bitcoin-git> bitcoin/master d8274bc Jonas Schnelli: Add compile and link options echo to configure
179 2016-11-17T15:06:29  <bitcoin-git> bitcoin/master a8b2a82 Wladimir J. van der Laan: Merge #9156: Add compile and link options echo to configure...
180 2016-11-17T15:06:43  <bitcoin-git> [bitcoin] laanwj closed pull request #9156: Add compile and link options echo to configure (master...2016/11/configure) https://github.com/bitcoin/bitcoin/pull/9156
181 2016-11-17T15:14:10  *** Chris_Stewart_5 has quit IRC
182 2016-11-17T15:18:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
183 2016-11-17T15:24:00  *** dgenr8 has quit IRC
184 2016-11-17T15:24:02  *** laurentmt has joined #bitcoin-core-dev
185 2016-11-17T15:26:22  *** laurentmt has quit IRC
186 2016-11-17T15:56:00  <instagibbs> Chris_Stewart_5, not sure how you are confused here: "If an OP_CHECKSIG is trying to return a FALSE value to the stack, we require that the relevant signature must be an empty byte array."
187 2016-11-17T15:56:18  <instagibbs> if a checksig is to fail, signatures must be false as well
188 2016-11-17T15:57:02  <instagibbs> false aka ""
189 2016-11-17T16:00:18  *** Chris_Stewart_5 has quit IRC
190 2016-11-17T16:15:25  *** laurentmt has joined #bitcoin-core-dev
191 2016-11-17T16:16:07  *** laurentmt has quit IRC
192 2016-11-17T16:18:05  *** DigiByteDev has quit IRC
193 2016-11-17T16:22:05  *** Chris_Stewart_5 has joined #bitcoin-core-dev
194 2016-11-17T16:28:25  <sipa> Chris_Stewart_5: it is not talking about OP_FALSE, but about a FALSE returned by checksig
195 2016-11-17T16:32:59  *** MarcoFalke_web has quit IRC
196 2016-11-17T16:45:08  <morcos> cfields: yeah i ran a longer test and your new branch doesn't really provide any benefit but the old one still provides a significant improvement
197 2016-11-17T16:45:38  <Chris_Stewart_5> sipa: "any BIP66-compliant non-empty byte array but not a valid signature" - this means that it is not a valid signature wrt to the public key in the script, right?
198 2016-11-17T16:47:37  <Chris_Stewart_5> and if so, how can this fail immediately without checking the signature: https://github.com/bitcoin/bitcoin/blob/35fe0393f216aa6020fc929272118eade5628636/src/script/interpreter.cpp#L880
199 2016-11-17T16:54:17  <sipa> Chris_Stewart_5: see 4 lines up
200 2016-11-17T17:01:45  *** Sosumi has joined #bitcoin-core-dev
201 2016-11-17T17:02:45  <Chris_Stewart_5> Is the only difference between CheckSignatureEncoding & IsValidSignatureEncoding the LOW_S check & trivially passes the empty byte array as a sig
202 2016-11-17T17:10:28  <Chris_Stewart_5> I guess my real question is could 'F' in the examples be a LOW_S sig https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki#examples
203 2016-11-17T17:10:59  <Chris_Stewart_5> sorry HIGH_S I guess
204 2016-11-17T17:12:10  *** Victorsueca has quit IRC
205 2016-11-17T17:23:51  *** rubensayshi has quit IRC
206 2016-11-17T17:31:18  *** abpa has joined #bitcoin-core-dev
207 2016-11-17T17:35:37  *** Sosumi has quit IRC
208 2016-11-17T17:36:46  *** Chris_Stewart_5 has quit IRC
209 2016-11-17T17:51:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
210 2016-11-17T17:53:34  *** sdaftuar has quit IRC
211 2016-11-17T17:57:42  *** MarcoFalke has joined #bitcoin-core-dev
212 2016-11-17T18:05:45  *** MarcoFalke has left #bitcoin-core-dev
213 2016-11-17T18:07:18  *** Chris_Stewart_5 has quit IRC
214 2016-11-17T18:07:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
215 2016-11-17T18:10:23  *** jtimon has joined #bitcoin-core-dev
216 2016-11-17T18:48:36  *** BonyM1 has quit IRC
217 2016-11-17T18:50:56  *** jcorgan has joined #bitcoin-core-dev
218 2016-11-17T18:56:28  *** MarcoFalke_web has joined #bitcoin-core-dev
219 2016-11-17T19:01:13  <achow101> meeting?
220 2016-11-17T19:01:13  <CodeShark> Meeting time?
221 2016-11-17T19:01:44  <jcorgan> whew, though i borked up the time zone again
222 2016-11-17T19:01:50  <jcorgan> *thought
223 2016-11-17T19:01:57  <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
224 2016-11-17T19:02:01  <jonasschnelli> here
225 2016-11-17T19:02:05  <kanzure> hi.
226 2016-11-17T19:02:07  <BlueMatt> oh, hey
227 2016-11-17T19:02:10  <instagibbs> hello
228 2016-11-17T19:02:21  <petertodd> hi
229 2016-11-17T19:03:13  <michagogo> o/
230 2016-11-17T19:03:14  <cfields> grr, flaky inet. here now.
231 2016-11-17T19:03:22  <michagogo> Wait, isn't it in an hour?
232 2016-11-17T19:03:30  <michagogo> Or is the time defined in UTC?
233 2016-11-17T19:03:37  <achow101> michagogo: UTC
234 2016-11-17T19:03:48  *** BonyM1 has joined #bitcoin-core-dev
235 2016-11-17T19:03:55  <jtimon> hi
236 2016-11-17T19:04:09  <michagogo> Ah. I guess I've just missed them all since we switched off of DST
237 2016-11-17T19:04:10  <jtimon> proposed topics?
238 2016-11-17T19:04:21  <jonasschnelli> #startmeeting
239 2016-11-17T19:04:21  <lightningbot> Meeting started Thu Nov 17 19:04:21 2016 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
240 2016-11-17T19:04:21  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
241 2016-11-17T19:04:27  <wumpus> hello
242 2016-11-17T19:05:09  <sipa> present
243 2016-11-17T19:05:31  * michagogo looks at wumpus's @
244 2016-11-17T19:05:34  <CodeShark> Hi
245 2016-11-17T19:05:37  <jonasschnelli> No topic proposals?
246 2016-11-17T19:05:50  <MarcoFalke_web> Short meeting, then :P
247 2016-11-17T19:06:02  <instagibbs> ideas for account removal/replacement? I'm getting annoyed at account code :)
248 2016-11-17T19:06:02  <sipa> can i ask a bit about shared_ptr changes?
249 2016-11-17T19:06:32  <jonasschnelli> #topic shared_ptr
250 2016-11-17T19:06:41  *** ChanServ sets mode: -o wumpus
251 2016-11-17T19:06:42  <morcos> i have a topic, i'd like tot alk about priority
252 2016-11-17T19:07:01  <sipa> the #topic is only recognized when said by the chair, i think
253 2016-11-17T19:07:06  <morcos> also +1 instagibbs
254 2016-11-17T19:07:14  <jonasschnelli> I'm the chair
255 2016-11-17T19:07:19  <sipa> oh!
256 2016-11-17T19:07:28  <instagibbs> sipa, better watch yourself ;)
257 2016-11-17T19:07:37  * sipa will go stand in the corner
258 2016-11-17T19:07:44  <sipa> so, i have a series of 3 PRs to introduce shared_ptr in more places
259 2016-11-17T19:08:14  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9125
260 2016-11-17T19:08:20  <sipa> #9125, #8580, #8589
261 2016-11-17T19:08:22  <gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
262 2016-11-17T19:08:24  <gribble> https://github.com/bitcoin/bitcoin/issues/8580 | Make CTransaction actually immutable by sipa · Pull Request #8580 · bitcoin/bitcoin · GitHub
263 2016-11-17T19:08:25  <gribble> https://github.com/bitcoin/bitcoin/issues/8589 | Inline CTxInWitness inside CTxIn (on top of #8580) by sipa · Pull Request #8589 · bitcoin/bitcoin · GitHub
264 2016-11-17T19:09:05  <wumpus> I'm testing #9125
265 2016-11-17T19:09:05  <sipa> the first i hope is a clear improvement and necessary refactor for the ones that follow (and it's 3-4% reindex performance improvement)
266 2016-11-17T19:09:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
267 2016-11-17T19:09:29  <jonasschnelli> Do I understand it right that one of the key benefits of the shared_ptr transition are the concurrency benefits with less locking?
268 2016-11-17T19:09:43  <sipa> that is a potential future advantage
269 2016-11-17T19:09:44  <BlueMatt> sipa: concept ack+1000
270 2016-11-17T19:09:45  <wumpus> also less copying
271 2016-11-17T19:09:45  <gmaxwell> No.
272 2016-11-17T19:09:46  <jonasschnelli> and less copis
273 2016-11-17T19:09:47  <BlueMatt> to all of them
274 2016-11-17T19:09:54  <sipa> but less copying is the immediate reason
275 2016-11-17T19:09:58  <gmaxwell> Thats an abstract advantage of shared pointers.
276 2016-11-17T19:10:01  <jonasschnelli> Okay.
277 2016-11-17T19:10:16  <gmaxwell> But right avoiding copies is that it accomplishes here.
278 2016-11-17T19:10:17  *** aalex_ has joined #bitcoin-core-dev
279 2016-11-17T19:10:27  <jonasschnelli> So performance and memory? Right?
280 2016-11-17T19:10:28  <sipa> the second one may be more controversial, as it affects the wallet code significantly, making CWalletTx not inherit from CTransaction anymore, and move it to a field
281 2016-11-17T19:10:32  <cfields> sipa: is there any specific part of the first that you think needs extra scrutiny/testing?
282 2016-11-17T19:10:38  <wumpus> sipa: YES
283 2016-11-17T19:10:59  <sipa> wumpus: YES as in "do it" or YES as in "it's more controversial"
284 2016-11-17T19:11:03  <wumpus> CWalleTx is pretty much the example of an abuse of inheritance
285 2016-11-17T19:11:05  <wumpus> in OOP
286 2016-11-17T19:11:11  <gmaxwell> wumpus: that was exactly my response.
287 2016-11-17T19:11:12  <sipa> ok, glad you agree on that
288 2016-11-17T19:11:38  <jonasschnelli> Yes. Also, is there a reason for the extra CMerkleTx inheritance?
289 2016-11-17T19:11:46  <sipa> jonasschnelli: abuse of C++
290 2016-11-17T19:11:49  <wumpus> wallettx should *contain* a line-level tx, plus metadata
291 2016-11-17T19:11:50  <jonasschnelli> heh
292 2016-11-17T19:12:02  <sipa> jonasschnelli: meaning you don't need to copy the interface
293 2016-11-17T19:12:46  <sipa> and then inlining CTxInWitness is to just simplify the code
294 2016-11-17T19:13:03  <sipa> (which is likely a small performance regression for non-witness txn, but an improvement for witness txn)
295 2016-11-17T19:13:45  <sipa> if no further comments on that, i'm done with the topic
296 2016-11-17T19:13:51  <jonasschnelli> While were at it, we should also remove "main.h" and "txmempool.h" from wallet.c (slightly OT) to avoid the circular dependency.
297 2016-11-17T19:13:53  <wumpus> no comments, i think it's the way forward
298 2016-11-17T19:14:11  <sipa> jonasschnelli: why is that a circular dependency?
299 2016-11-17T19:14:11  <jonasschnelli> sipa: ack
300 2016-11-17T19:14:12  <gmaxwell> why isn't it all done and merged yet? :P
301 2016-11-17T19:14:12  *** aalex has quit IRC
302 2016-11-17T19:14:23  <sipa> jonasschnelli: main and txmempool should not depend on wallet
303 2016-11-17T19:14:32  <sipa> but wallet depending on main seems perfectly expected for me
304 2016-11-17T19:14:34  <wumpus> wallet is allowed to depend on stuff in libbitcoin_server
305 2016-11-17T19:14:42  <wumpus> just not the other way around
306 2016-11-17T19:14:44  <jonasschnelli> sipa: have a look at https://github.com/bitcoin/bitcoin/pull/8745
307 2016-11-17T19:15:24  <sipa> what should i see there?
308 2016-11-17T19:15:37  <wumpus> I think we can discuss this outside the meeting? other more urgent topics?
309 2016-11-17T19:15:45  <sipa> ah, i understnad
310 2016-11-17T19:15:51  <jonasschnelli> Yes. Outside the meeting.
311 2016-11-17T19:15:51  <sipa> yes, let's discuss design at another time
312 2016-11-17T19:16:10  <jonasschnelli> morcos had the topic proposal "priority"
313 2016-11-17T19:16:16  <morcos> Lets talk about potential for account or priority removal (2 separate topics)
314 2016-11-17T19:16:27  <sipa> agree on topic
315 2016-11-17T19:16:31  <jonasschnelli> #action account or priority removal
316 2016-11-17T19:16:36  <jonasschnelli> #topic account or priority removal
317 2016-11-17T19:16:36  <gmaxwell> lol
318 2016-11-17T19:16:40  <jonasschnelli> :/
319 2016-11-17T19:16:53  <morcos> I think luke-jr was the main proponent of keeping priority around, so if he's not here, maybe we need to postpone further discussion
320 2016-11-17T19:17:08  <morcos> but it was my hope that we could all be in agreeement that it serves not much of a function any more
321 2016-11-17T19:17:32  <morcos> Perhaps we can set a target for 0.15 if 0.14 is too close, but it would be nice to remove ALL of the priority code
322 2016-11-17T19:17:46  <morcos> it would clean a lot of things up
323 2016-11-17T19:17:49  <wumpus> I think that ship has already sailed?
324 2016-11-17T19:17:54  <BlueMatt> morcos: ACK, but maybe 0.15
325 2016-11-17T19:17:59  <BlueMatt> deprecate more formally in 0.14
326 2016-11-17T19:18:09  <wumpus> I mean, we merged some stuff on the way for priority removal already
327 2016-11-17T19:18:09  <morcos> BlueMatt: that makes sense to me
328 2016-11-17T19:18:14  <BlueMatt> wumpus: not even eligius is doing any priority selection now...at the time maybe luke could have argued for it, but now.....
329 2016-11-17T19:18:21  <sipa> we removed priority estimation
330 2016-11-17T19:18:38  <jcorgan> is there any empirical data on miner behavior?
331 2016-11-17T19:18:40  <morcos> wumpus: i mostly agree, but the removal of priority estimation was because it wasn't functional any more, so it was an easier decision
332 2016-11-17T19:18:42  <sipa> all that is left is priority based mining, i think
333 2016-11-17T19:19:04  <sipa> if it serves no function (and maybe we need a bit more data on that), it should be equally easy imho
334 2016-11-17T19:19:13  <gmaxwell> I agree, I think any desire to keep it around could be answered by intelligent automatic use of fee delta. But this is going to get rehashed with luke later anyways. I think it's likely that everyone who regularly attends the meetings except luke agrees.
335 2016-11-17T19:19:26  <morcos> there is also the free transactoin and rate limiting code
336 2016-11-17T19:19:28  <wumpus> users can still set prioritizetransaction
337 2016-11-17T19:20:09  <achow101> does priority estimation even work? estimatepriority just gives me -1 regardless
338 2016-11-17T19:20:18  <sipa> achow101: priority estimation is removed
339 2016-11-17T19:20:19  <morcos> achow101: thats why it is removed for 0.14
340 2016-11-17T19:20:29  <sipa> achow101: the RPC remains for backward compatibility, but is a stub
341 2016-11-17T19:20:30  <gmaxwell> jcorgan: some had been collected in the past when it was defaulted to off.  general result is that its not used ~anywhere anymore.
342 2016-11-17T19:20:33  <wumpus> so if prioritization on some criterion that is not fee it can still be implemented outside of bitcoind
343 2016-11-17T19:20:44  <morcos> it works, its just correctly telling you that no priority is high enough to get you mined quickluy
344 2016-11-17T19:20:50  <achow101> ah, i see
345 2016-11-17T19:21:01  <wumpus> heh
346 2016-11-17T19:22:00  <morcos> back in a couple min
347 2016-11-17T19:22:10  <jtimon> so I thought we were waiting on 0.14 for removing the priority, now we wait for 0.15?
348 2016-11-17T19:22:47  <wumpus> is there any reason to hurry?
349 2016-11-17T19:22:54  <sipa> jtimon: there seem to be at least 4 components to "removing the priority", i'm not sure they all need to happen simultaneously
350 2016-11-17T19:23:10  <sipa> (rpc, estimation, mining, relay)
351 2016-11-17T19:23:29  <jtimon> wumpus: no, any reason to wait ?
352 2016-11-17T19:23:35  <wumpus> I'm sure no one is really waiting for it to be removed, it can be removed part by part and 0.15 is a fine target
353 2016-11-17T19:23:40  <gmaxwell> relay is the only one I really care much about, because it currently causes bandwidth wasting relaying around junk that won't get mined.
354 2016-11-17T19:23:50  <jtimon> if people want to work on that, I don't see why they should wait
355 2016-11-17T19:23:53  <wumpus> jtimon: there are always other "priorities"
356 2016-11-17T19:24:09  <MarcoFalke_web> Can we disable relay by default for .14?
357 2016-11-17T19:24:46  <jonasschnelli> ack on DEFAULT_RELAYPRIORITY = false; for 0.14
358 2016-11-17T19:25:05  <gmaxwell> I'd support that, if we don't go further.
359 2016-11-17T19:25:23  <sipa> agree
360 2016-11-17T19:25:25  <MarcoFalke_web> What do you mean with "go further"?
361 2016-11-17T19:25:32  <wumpus> disabling by default always makes sense as a first step
362 2016-11-17T19:25:36  <gmaxwell> MarcoFalke_web: remove the code entirely.
363 2016-11-17T19:25:47  <MarcoFalke_web> #action DEFAULT_RELAYPRIORITY = false; for 0.14
364 2016-11-17T19:25:59  <wumpus> even if you rip out the code two days later...
365 2016-11-17T19:26:13  <jtimon> ok, I see, disable for 0.14 first what you want to remove for 0.15, that makes sense
366 2016-11-17T19:26:34  <sipa> ok, account removal?
367 2016-11-17T19:26:42  <MarcoFalke_web> next topic
368 2016-11-17T19:26:50  *** cannon-c has joined #bitcoin-core-dev
369 2016-11-17T19:26:55  <morcos> wait i'm confused
370 2016-11-17T19:27:03  <gmaxwell> uh oh.
371 2016-11-17T19:27:08  <morcos> what are the proposed changes to relay
372 2016-11-17T19:27:22  <morcos> that priority doesn't let you skip the rate limiting
373 2016-11-17T19:28:17  <morcos> ok nm, ignore me.  we are proposing that you always have to have minrelaytxfee
374 2016-11-17T19:28:22  <gmaxwell> Yes.
375 2016-11-17T19:28:29  <jonasschnelli> #topic "account removal"
376 2016-11-17T19:28:39  <morcos> i don't think thats going to help too much with junk, but agree it would be good change
377 2016-11-17T19:28:40  <gmaxwell> also, the help text for relaypriority is wrong/confusing. :P
378 2016-11-17T19:28:56  *** sdaftuar has joined #bitcoin-core-dev
379 2016-11-17T19:29:13  <MarcoFalke_web> I think we already have a pull open for this #7729
380 2016-11-17T19:29:14  <morcos> account removal is more tricky
381 2016-11-17T19:29:16  <wumpus> so I proposed a label API to replace accounts at the start of this year, it still hasn't had much review yet: https://github.com/bitcoin/bitcoin/pull/7729
382 2016-11-17T19:29:17  <jonasschnelli> There is sill an open PR from wumpus to #7729 which is a step towards account removal
383 2016-11-17T19:29:20  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
384 2016-11-17T19:29:21  <jonasschnelli> heh
385 2016-11-17T19:29:22  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
386 2016-11-17T19:29:24  <wumpus> not sure there's anything new to discuss there
387 2016-11-17T19:29:33  <gmaxwell> "Bitcoin developers oppose accountability."
388 2016-11-17T19:30:04  <morcos> so the idea would be we have to have labels first
389 2016-11-17T19:30:08  <morcos> maybe for a release or two
390 2016-11-17T19:30:09  <jonasschnelli> morcos: what would be your approach for the removal-transition?
391 2016-11-17T19:30:15  <morcos> and then we coudl remove accounts?
392 2016-11-17T19:30:18  <wumpus> if people are ok with that proposal I'll go forward with it, but there's always so little attention on wallet related changes, let alone deprecating features
393 2016-11-17T19:30:24  <wumpus> morcos: yes
394 2016-11-17T19:30:26  <instagibbs> yes labels would have to come first
395 2016-11-17T19:30:32  <morcos> i mean i wish we could just rip them out, they're terrible.  but it seems like people still depend on them
396 2016-11-17T19:30:32  <gmaxwell> I think I had just managed to miss 7729.
397 2016-11-17T19:30:43  <gmaxwell> Doing both lavels and accounts means more breaking API changes, no?
398 2016-11-17T19:30:55  <MarcoFalke_web> wumpus: You mentioned that this may cause problems when people use the account AND label api?
399 2016-11-17T19:31:09  <wumpus> MarcoFalke_web: there may need to be protection against that, yes
400 2016-11-17T19:31:20  <gmaxwell> morcos: most of the time I see them mentioned, they are being used as labels.
401 2016-11-17T19:31:21  <wumpus> MarcoFalke_web: though the same already happens if you use accounts and the GUI
402 2016-11-17T19:31:32  <wumpus> MarcoFalke_web: and there is no protection against that either
403 2016-11-17T19:31:33  <jtimon> can't we replace accounts with labels all at once?
404 2016-11-17T19:32:04  <gmaxwell> morcos: and people are confused when the accounts centric behavior shows up...  or, alternatively, they're confused when they don't control "from" addresses (that they're not seperate wallets).
405 2016-11-17T19:32:04  <jtimon> it's not like we haven't been warning against the use of accounts for ages
406 2016-11-17T19:32:06  <wumpus> can we first *agree* on the label api?
407 2016-11-17T19:32:19  <instagibbs> jtimon, at some point I don't think people believe the deprecated warning
408 2016-11-17T19:32:22  <sipa> jtimon: go review 7729 (and i should do the same)
409 2016-11-17T19:32:25  <instagibbs> we should put scary ascii art :)
410 2016-11-17T19:32:26  <gmaxwell> so proposed action: everyone go comment on 7729.
411 2016-11-17T19:32:30  <instagibbs> action yes
412 2016-11-17T19:32:32  <morcos> ok, lets all read 7729 again and discuss on there
413 2016-11-17T19:32:35  <instagibbs> ack
414 2016-11-17T19:32:37  <morcos> damn i type too slow
415 2016-11-17T19:32:38  <jtimon> sipa: right
416 2016-11-17T19:32:39  <gmaxwell> yea, it sounds great.
417 2016-11-17T19:32:53  <instagibbs> also who uses labels that we talk to? dooglus?
418 2016-11-17T19:32:55  <MarcoFalke_web> #action look at https://github.com/bitcoin/bitcoin/pull/7729
419 2016-11-17T19:33:15  <jonasschnelli> Removing the accounting system entirely will be difficult (especially old wallet migration)
420 2016-11-17T19:33:29  <wumpus> whether to rip accounts at the same time as introducing labels is for later discussion, none of this is hard to implement, but deciding what API we want is more difficult
421 2016-11-17T19:33:36  <wumpus> jonasschnelli: no, it's not difficult at all
422 2016-11-17T19:34:14  <wumpus> jonasschnelli: you could even keep the accounting records around and just ignore them and treat previous accounts as labels instead
423 2016-11-17T19:34:22  <gmaxwell> ^ is what I expected.
424 2016-11-17T19:34:23  <sipa> just the concept of 'balance of a label/account' disappears, not the ability to selectively list transactions affecting labels/accounts
425 2016-11-17T19:34:25  <jonasschnelli> I once did it in a test branch and it took me a long time to get it right... but maybe I was overcomplicating stuff there
426 2016-11-17T19:34:38  <MarcoFalke_web> I think dooglus use case would be covered by the new label api, but better someone ping him on the pr
427 2016-11-17T19:34:41  <wumpus> jonasschnelli: it's mainly a matter of deleting code
428 2016-11-17T19:34:56  <jonasschnelli> Right. I removed it with no labels migration
429 2016-11-17T19:35:07  <gmaxwell> I expected the account->label change would mostly be a matter of getting rid of balance related functionality. And otherwise not much perhaps beyond some new label centric features.
430 2016-11-17T19:35:11  <sipa> jonasschnelli: i think you're overcomplicating
431 2016-11-17T19:35:16  <wumpus> gmaxwell: yes
432 2016-11-17T19:35:34  <wumpus> gmaxwell: and just to be claear *account* RPCs are renamed to *label*, basically
433 2016-11-17T19:35:36  <sipa> jonasschnelli: it's literally just removing the balance RPCs, and then dropping the 'from account' field in send RPC, and renaming the rest account->label
434 2016-11-17T19:35:44  <wumpus> yes
435 2016-11-17T19:35:48  <gmaxwell> (e.g. of 'obvious' additional features: multiple labels on items, being able to label a single transaction without labling any involved addresses)
436 2016-11-17T19:36:23  <wumpus> well at first it just implements the GUI label API, which doesn't allow labeling transactions either
437 2016-11-17T19:36:30  <wumpus> I think that's a whole different thing
438 2016-11-17T19:36:31  <gmaxwell> yep. makes sense.
439 2016-11-17T19:36:59  <jonasschnelli> you can label addresses but not transactions, right?
440 2016-11-17T19:37:03  <wumpus> right
441 2016-11-17T19:37:04  <jonasschnelli> We have a comment feature for transaction
442 2016-11-17T19:37:07  <jtimon> isn't the move call also affected (if we still have that)?
443 2016-11-17T19:37:13  <morcos> perhaps as an immediate step, we could more forcefully declare accounts unsupported and deprecated for 0.14
444 2016-11-17T19:37:13  <jonasschnelli> (which is sadly not really used and exposed)
445 2016-11-17T19:37:17  <wumpus> move will disappear jtimon
446 2016-11-17T19:37:25  <wumpus> please actually read #7729 :(
447 2016-11-17T19:37:26  <jtimon> wumpus: k
448 2016-11-17T19:37:27  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
449 2016-11-17T19:37:31  <morcos> so that in the course of adding labels, we don't have to worry about any edge case mixing of the 2
450 2016-11-17T19:37:36  <gmaxwell> morcos: that would be negative for the many people who use accounts as labels today, however.
451 2016-11-17T19:38:11  <wumpus> first introduce labels
452 2016-11-17T19:38:14  <morcos> gmaxwell: yeah but i don't mean we're actually going to change it,  i just worry that in the course of adding labels around accounts we'll give ourselves extra work, but maybe not.
453 2016-11-17T19:38:21  <wumpus> only then I'll agree on doing anything more to deprecate accounts
454 2016-11-17T19:38:34  <wumpus> if we don't move forward for labels, we'll stay in this state forever
455 2016-11-17T19:38:42  <gmaxwell> I need to read the PR to comment more!
456 2016-11-17T19:38:47  <instagibbs> 2 spooky
457 2016-11-17T19:38:52  *** Chris_Stewart_5 has quit IRC
458 2016-11-17T19:40:03  <instagibbs> any other topics?
459 2016-11-17T19:40:04  <wumpus> making more noise about removing accounts before we have a labels API will just make people (such as dooglus) panicked
460 2016-11-17T19:40:33  * gmaxwell looks at btcdrak pining #joinmarket and contemplates ^ :P
461 2016-11-17T19:41:10  <gmaxwell> okay, I think we should take the proposed action of everyone reading and commenting on 7729 and move to another subject.
462 2016-11-17T19:41:11  <jonasschnelli> I guess he's afk
463 2016-11-17T19:41:18  <wumpus> yes
464 2016-11-17T19:41:55  <gmaxwell> Or otherwise, we could instead engage in the age old art of completely uninformed combat.
465 2016-11-17T19:42:16  <morcos> you want to talk about block size?
466 2016-11-17T19:42:18  <jtimon> morcos: are you saying remove accounts before labels or just do both at the same time (to not worry about incompatibilities between the 2)?
467 2016-11-17T19:42:24  <gmaxwell> "I haven't read 7729 but I oppose any change that causes blindness in small children!"
468 2016-11-17T19:42:34  <petertodd> gmaxwell: I didn't read your last comment, but ACK
469 2016-11-17T19:42:53  <jtimon> other topics?
470 2016-11-17T19:42:54  <jonasschnelli> If there are no other topic, we could talk about "auxiliary block requests" if some are interested in it?
471 2016-11-17T19:43:08  <jtimon> what is that?
472 2016-11-17T19:43:14  <jonasschnelli> #9171
473 2016-11-17T19:43:15  <gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
474 2016-11-17T19:43:20  <gmaxwell> jonasschnelli: will that cause blindness in small children?
475 2016-11-17T19:43:24  * BlueMatt petitions for one more review on #9075
476 2016-11-17T19:43:26  <gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
477 2016-11-17T19:43:44  <gmaxwell> jtimon: it provides hot and cold running blocks.
478 2016-11-17T19:43:45  <sipa> gmaxwell: yes, through xkcd 378
479 2016-11-17T19:43:46  <jonasschnelli> jtimon "auxiliary block requests" is a requirement for SPV
480 2016-11-17T19:43:48  <instagibbs> BlueMatt, thanks, added to queue
481 2016-11-17T19:44:01  <jonasschnelli> It allows you to request blocks during IBD... which not getting validated
482 2016-11-17T19:44:18  <morcos> jonasschnelli: is there some more general description of how all that would work.  i started to look at it, but i wasn't sure what the high level design was
483 2016-11-17T19:44:30  <instagibbs> ACK morcos I couldn't grasp immediately
484 2016-11-17T19:44:39  <jonasschnelli> Hmm... I can write a paper?
485 2016-11-17T19:45:03  <morcos> it doesn't have to be formal
486 2016-11-17T19:45:23  <jonasschnelli> It's simple: you ask your node, "giveme blocks D, F, G", node downloads blocks "D, F, G" and pass it though the signals with validate=fale"
487 2016-11-17T19:45:27  <BlueMatt> jonasschnelli: note that I'm working to remove fForceProcessing/etc from ProcessNewBlock...please do not pass the blockRequest object all the way in...
488 2016-11-17T19:45:38  <gmaxwell> I have to admit I expirenced some groan related to "oh no, yet another block fetching modality" -- but the application of being able to on demand randomly request blocks is perfectly reasonsable.  More description would be helpful.
489 2016-11-17T19:45:54  <jonasschnelli> It uses all the available mechanisms.
490 2016-11-17T19:46:04  <BlueMatt> jonasschnelli: I'd kinda prefer this not call AcceptBlock at all...do we need to store the block or can we just pass to wallet?
491 2016-11-17T19:46:10  <jonasschnelli> It just "prioritize the requested blocks"
492 2016-11-17T19:46:14  <sipa> overall concept ack, but i think the implementation will need to change with the ongoing network processing refactors
493 2016-11-17T19:46:51  <gmaxwell> BlueMatt: seems foolish to download blocks twice... which would happen if we didn't store them.
494 2016-11-17T19:46:57  <BlueMatt> hum, true
495 2016-11-17T19:46:57  <jonasschnelli> BlueMatt: Right. We could factor out the on-disk-storing part
496 2016-11-17T19:47:08  <BlueMatt> still, would be nice to not store unless we need to
497 2016-11-17T19:47:15  <wumpus> it needs to get the chance to store it, atl east
498 2016-11-17T19:47:20  <gmaxwell> ^ yep.
499 2016-11-17T19:47:23  <sipa> BlueMatt: it would integrate into some callback for downloaded blocks, i would guess
500 2016-11-17T19:47:23  <BlueMatt> gmaxwell: we could also use the needs-download logic in the p2p logic to dedup download
501 2016-11-17T19:47:31  <gmaxwell> Interaction with pruning seems somewhat complicated.
502 2016-11-17T19:47:40  <BlueMatt> that way the p2p logic could decide to hand to ProcessNewBlock...or not
503 2016-11-17T19:47:43  <wumpus> there may be further policy not to store it, e.g. based on pruning and such
504 2016-11-17T19:47:45  <BlueMatt> gmaxwell: thats part of my concern
505 2016-11-17T19:47:56  <wumpus> but for a full IBD you'd really want to pre-fill blocks
506 2016-11-17T19:48:02  <BlueMatt> just seems kinda broken to have the block-processing logic process a block which it explicitly doesnt want
507 2016-11-17T19:48:15  <gmaxwell> BlueMatt: but the main application now is a node that starts off with a spv mode wallet while it syncs up in the background.  Such nodes will likely also be pruned.
508 2016-11-17T19:48:18  <wumpus> it will likely want it later
509 2016-11-17T19:48:27  <sipa> i guess there should be a separation of "which blocks to download" and "which blocks to process" logic
510 2016-11-17T19:48:32  <sipa> where the second can ask the first
511 2016-11-17T19:48:38  <jonasschnelli> I think to make it work with pruning is not very hard... just step after step
512 2016-11-17T19:48:57  <BlueMatt> wumpus: yes, I'm saying if we have a full-spv mode then the p2p logic should be able to not pass it to ProcessNewBlock....alternatively it can choose to do so if it thinks block-logic needs it
513 2016-11-17T19:48:58  <wumpus> could e.g. store it for later processing
514 2016-11-17T19:49:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
515 2016-11-17T19:49:16  <wumpus> discarding by default would be stupid, at least
516 2016-11-17T19:49:28  <BlueMatt> wumpus: sure, but we have logic to figure out if we want a block or not, already
517 2016-11-17T19:49:36  <BlueMatt> jonasschnelli: note that I have a pr to change the stuff there to deserialize blocks into shared_ptrs, so passing it over to wallet should use that
518 2016-11-17T19:50:02  <BlueMatt> #9014, though its blocked on #9075
519 2016-11-17T19:50:02  <gmaxwell> blocks as sharedptr, hurrah
520 2016-11-17T19:50:02  <jonasschnelli> BlueMatt: okay. Though #9171 aims to be a wallet free PR
521 2016-11-17T19:50:06  <gribble> https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
522 2016-11-17T19:50:07  <gribble> https://github.com/bitcoin/bitcoin/issues/9075 | Decouple peer-processing-logic from block-connection-logic (#3) by TheBlueMatt · Pull Request #9075 · bitcoin/bitcoin · GitHub
523 2016-11-17T19:50:09  <gribble> https://github.com/bitcoin/bitcoin/issues/9171 | Introduce auxiliary block requests by jonasschnelli · Pull Request #9171 · bitcoin/bitcoin · GitHub
524 2016-11-17T19:50:32  <sipa> BlueMatt: note that after 9125, deserializing into a share_ptr is literally just "std::shared_ptr<const CBlock> ptr; ss >> ptr; "
525 2016-11-17T19:50:40  <BlueMatt> sipa: cool
526 2016-11-17T19:52:53  <jonasschnelli> more topics? 8m to go.
527 2016-11-17T19:53:27  <wumpus> *crickets*
528 2016-11-17T19:53:27  <Chris_Stewart_5> jonasschnelli: What is the use case for that? Why request the full block if we aren't validating?
529 2016-11-17T19:53:39  <sipa> Chris_Stewart_5: light wallet support
530 2016-11-17T19:53:49  <gmaxwell> Chris_Stewart_5: so we can scan it for wallet transactions.
531 2016-11-17T19:53:50  <instagibbs> Chris_Stewart_5, you download blocks based on age of your wallet
532 2016-11-17T19:53:55  <jonasschnelli> Chris_Stewart_5: allow receiving and sending transactions in "client" mode
533 2016-11-17T19:54:00  <sipa> Chris_Stewart_5: the ability to use the wallet before you're fully synced
534 2016-11-17T19:54:11  <instagibbs> "Where did my money go" <---
535 2016-11-17T19:54:14  <wumpus> let's take basic questions to outside the meeting
536 2016-11-17T19:54:31  <Chris_Stewart_5> This is alt solution to BIP37 then, or complementary?
537 2016-11-17T19:54:44  <gmaxwell> Chris_Stewart_5: bip37 _utterly_ destroys privacy, and would waste bandwidth if you're later going to need the block for verification anyways.
538 2016-11-17T19:54:56  <jonasschnelli> Chris_Stewart_5: its a safer solution then BIP37...
539 2016-11-17T19:55:38  <gmaxwell> (BIP37 is also vulnerable to txn being hidden from you)
540 2016-11-17T19:55:55  <wumpus> yes, BIP37 is a bad idea, we're not going to use it in core
541 2016-11-17T19:56:37  <Chris_Stewart_5> Yes I understand that part, I'm trying to piece together how new spv mode will function i guess.
542 2016-11-17T19:56:39  <wumpus> (bad idea with untrusted peers at least, and that's the use case here)
543 2016-11-17T19:56:52  <jonasschnelli> I think it could have it's reason when connected to a BIP150 authed trusted peer. But only then.
544 2016-11-17T19:56:53  <wumpus> any other topics?
545 2016-11-17T19:56:57  <wumpus> the meeting is derailed
546 2016-11-17T19:57:13  <wumpus> otherwise better to close it
547 2016-11-17T19:57:15  <instagibbs> 3 minutes, no topics, bound to
548 2016-11-17T19:57:17  <MarcoFalke_web> #endsmeeting
549 2016-11-17T19:57:22  <jonasschnelli> #endmeeting
550 2016-11-17T19:57:22  <lightningbot> Meeting ended Thu Nov 17 19:57:22 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
551 2016-11-17T19:57:22  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.html
552 2016-11-17T19:57:22  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.txt
553 2016-11-17T19:57:22  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-11-17-19.04.log.html
554 2016-11-17T19:57:27  <gmaxwell> If you end the meeting will it be classified as back on track or forever derailed?
555 2016-11-17T19:57:32  <sipa> Chris_Stewart_5: it will just download full blocks
556 2016-11-17T19:57:42  <achow101> will we have a meeting next week? It's a holiday in the US
557 2016-11-17T19:57:43  <sipa> Chris_Stewart_5: and possibly remember them for validation later
558 2016-11-17T19:57:46  <jonasschnelli> sipa: \o/ new navigation on http://bitcoin.sipa.be
559 2016-11-17T19:57:49  <jonasschnelli> hurra
560 2016-11-17T19:57:57  <sipa> jonasschnelli: yes, thanks to jameson lopp
561 2016-11-17T19:58:10  <jonasschnelli> achow101: US? is that the place where they just abandoned politics?
562 2016-11-17T19:58:13  <instagibbs> Chris_Stewart_5, I'm a new full node, wallet is a week or two old. Then you can grab the last two weeks of blocks and find payments
563 2016-11-17T19:58:21  <achow101> jonasschnelli: yeah, that one
564 2016-11-17T19:58:22  <instagibbs> meanwhile background you're still validating
565 2016-11-17T19:58:29  <gmaxwell> jonasschnelli: political discussion to ##bitcoin.
566 2016-11-17T19:58:45  <Chris_Stewart_5> What about bandwidth usage? Doesn't this require much more bandwidth? Not a concern?
567 2016-11-17T19:58:47  <gmaxwell> achow101: the meetings stop for nothing except almost everyone being gone at once. :P
568 2016-11-17T19:58:49  <wumpus> gmaxwell: well I think this meeting will stay derailed no matter waht, there's no way to un-log what is logged :)
569 2016-11-17T19:59:02  <jonasschnelli> Chris_Stewart_5: if you want to do a full validation, you need to block anyways.
570 2016-11-17T19:59:14  <jonasschnelli> So you have some already downloaded blocks around the tip
571 2016-11-17T19:59:18  <Chris_Stewart_5> and if you don't?
572 2016-11-17T19:59:39  <jonasschnelli> You waste bandwidth
573 2016-11-17T19:59:43  <jonasschnelli> which can be okay.
574 2016-11-17T19:59:45  <wumpus> Chris_Stewart_5: it's just a different compromise
575 2016-11-17T19:59:50  <gmaxwell> Chris_Stewart_5: besides, fetching blocks is 14kb/s ongoing (28kb/s perhaps soon)-- most people running bitcoin core can handle that without batting an eye.
576 2016-11-17T19:59:58  <jonasschnelli> either you waste pricavy or bandwidth... you can choose.
577 2016-11-17T20:00:05  <wumpus> right
578 2016-11-17T20:00:08  <instagibbs> even if you don't want to catch up, it's still better than bloom filters or centralized nodes
579 2016-11-17T20:00:14  <Chris_Stewart_5> jonasschnelli: If we are removing BIP37 there isn't a choice.
580 2016-11-17T20:00:20  <gmaxwell> STOP
581 2016-11-17T20:00:21  <gmaxwell> die
582 2016-11-17T20:00:28  <gmaxwell> okay, now that you are all dead...
583 2016-11-17T20:00:28  <wumpus> no one is *removing* BIP37
584 2016-11-17T20:00:32  <gmaxwell> ^ that.
585 2016-11-17T20:00:35  <jonasschnelli> heh
586 2016-11-17T20:00:42  <jonasschnelli> (rofl)
587 2016-11-17T20:00:43  <wumpus> can people stop FUDing and panicking about everything we do?
588 2016-11-17T20:00:45  <wumpus> thank you
589 2016-11-17T20:00:51  <achow101> panic panic
590 2016-11-17T20:01:21  <gmaxwell> When in danger or in doubt run in terror, scream and shout.
591 2016-11-17T20:01:22  <wumpus> we're just nopt using BIP37 for the light wallet mode in bitcoin core. If you want to use it in your wallet go ahead.
592 2016-11-17T20:01:40  <wumpus> it's a big internet and you don't need to do what we do
593 2016-11-17T20:01:52  <jonasschnelli> Chris_Stewart_5: </panic mode> you can use BIP37 with plenty of other wallets, but when using Core, we don't want scarifies privacy over because of some GB bandwidth
594 2016-11-17T20:01:58  <bsm1175321> I'm interested in making an update to BIP37 to improve light wallet security...
595 2016-11-17T20:02:08  <gmaxwell> Maybe someday BIP37 goes away, but only if it were replaced with something better for the things that use it now. There are proposals but at the moment no one is actively working on them.
596 2016-11-17T20:02:10  <jonasschnelli> That's IMO impossible..
597 2016-11-17T20:02:15  <wumpus> many people only use their bitcoin wallet with wifi so could care less about bandwidth usage
598 2016-11-17T20:02:18  <jonasschnelli> Maybe Bloom Filter Commitments
599 2016-11-17T20:02:22  <wumpus> they care about privacy, though
600 2016-11-17T20:02:50  <jonasschnelli> People are downloading a 10GB movie just to rent it for 24h... why would they not be willing to download 10GB to get financial privacy?
601 2016-11-17T20:03:14  <sipa> bsm1175321: the only proposal i know that improves it is pretty radically different (bloom filter commitments)
602 2016-11-17T20:03:16  <wumpus> yeah, it's simply a choice/compromise, I don't understand what is so difficult about understanding that
603 2016-11-17T20:03:41  <jcorgan> why interpret ambiguity in a way that gives the speaker the benefit of the doubt when you can construe anything they say in the worst possible way to reinforce your pre-existing conclusions?
604 2016-11-17T20:03:43  <gmaxwell> jonasschnelli: the filter commitment scheme can also be done without the commitments. (just loses the censorship resistance).
605 2016-11-17T20:03:54  <bsm1175321> sipa: I'll read up.  Any links?  I'm also interested in UTXO set commitments.
606 2016-11-17T20:04:20  <bsm1175321> Also perfectly happy with something pretty radically different.
607 2016-11-17T20:04:33  <jonasschnelli> gmaxwell: do you have a post or paper about this?
608 2016-11-17T20:04:46  <sipa> bsm1175321: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012636.html
609 2016-11-17T20:05:25  <gmaxwell> jonasschnelli: the post describing the commited filters mentions that it can be done without the commitment. The only thing the commitment adds is the inability for nodes to lie about the filter content. Which is good, but it doesn't have to be delivered right away.
610 2016-11-17T20:05:39  <bsm1175321> sipa: thanks!
611 2016-11-17T20:05:46  <jonasschnelli> Okay. Thanks for the link sipa
612 2016-11-17T20:05:51  <gmaxwell> My view is that it would best be accomplished by implementing it without the commitment but in a way that would be sutiable for commitment later.
613 2016-11-17T20:06:46  <gmaxwell> also, as an aside, cuckoo filters are likely a better data structure for this than bloom filters... but there is a big area for research here.
614 2016-11-17T20:07:57  <bsm1175321> +1 on cuckoo filters.  Waaaay faster and the performance characteristics are more understandable (one fewer parameter)
615 2016-11-17T20:08:22  <gmaxwell> segwit also opens up a new option, which is just fetching full blocks without witnesses.
616 2016-11-17T20:09:34  <gmaxwell> If segwit were used exclusively the size of a full block without the witness would be about 500k... not exactly as small as a filter, but still perfectly private.
617 2016-11-17T20:10:29  <sipa> jcorgan: what was that a response to?
618 2016-11-17T20:10:59  <bsm1175321> I wonder if some kind of oblivious transfer protocol would be practical for light wallet privacy?
619 2016-11-17T20:11:12  <jcorgan> ?
620 2016-11-17T20:12:14  <jcorgan> oh, earlier, that was about Chris_Stewart_5 comment
621 2016-11-17T20:13:07  <jcorgan> a snark that lost its context when too many other comments flew by while i was typing
622 2016-11-17T20:14:21  *** cannon-c has quit IRC
623 2016-11-17T20:14:25  <bitcoin-git> [bitcoin] mruddy closed pull request #9175: WIP: remove script checking dependency on checkpoints (master...script_check) https://github.com/bitcoin/bitcoin/pull/9175
624 2016-11-17T20:15:03  <Chris_Stewart_5> jcorgan: I misinterpreted wumpus comment about 'not using' BIP37 in core as 'removing' it and apparently that triggered everyone ;). Thanks for the support though, some one has to ask the dumb questions :-)
625 2016-11-17T20:15:30  <bsm1175321> e.g. http://percy.sourceforge.net/
626 2016-11-17T20:21:57  *** tunafizz has quit IRC
627 2016-11-17T20:28:20  *** jtimon has quit IRC
628 2016-11-17T20:30:06  *** meownow has joined #bitcoin-core-dev
629 2016-11-17T20:30:13  <meownow> hi all
630 2016-11-17T21:02:26  *** cryptapus has quit IRC
631 2016-11-17T21:02:56  *** meownow has quit IRC
632 2016-11-17T21:18:40  *** Chris_Stewart_5 has quit IRC
633 2016-11-17T21:24:12  <bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/a8b2a82618be...9346f8429957
634 2016-11-17T21:24:12  <bitcoin-git> bitcoin/master e2e069d Matt Corallo: Revert "RPC: Give more details when "generate" fails"...
635 2016-11-17T21:24:13  <bitcoin-git> bitcoin/master 7c98ce5 Matt Corallo: Remove pfrom parameter from ProcessNewBlock...
636 2016-11-17T21:24:14  <bitcoin-git> bitcoin/master ae22357 Matt Corallo: Replace CValidationState param in ProcessNewBlock with BlockChecked
637 2016-11-17T21:24:26  <bitcoin-git> [bitcoin] sipa closed pull request #9075: Decouple peer-processing-logic from block-connection-logic (#3) (master...net_processing_4) https://github.com/bitcoin/bitcoin/pull/9075
638 2016-11-17T21:33:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
639 2016-11-17T21:59:01  *** Victorsueca has joined #bitcoin-core-dev
640 2016-11-17T22:03:29  *** meownow has joined #bitcoin-core-dev
641 2016-11-17T22:09:25  <meownow> main.cpp is the best place to start in terms of trying to understand the source code, correct?
642 2016-11-17T22:10:24  *** jtimon has joined #bitcoin-core-dev
643 2016-11-17T22:11:10  <MarcoFalke_web> Carefully reviewing pull requests is the best place to start in terms of trying to understand the source code :P
644 2016-11-17T22:14:22  <meownow> ok, will do that then!
645 2016-11-17T22:15:15  <MarcoFalke_web> #9142 looks ready for merge.
646 2016-11-17T22:15:16  <gribble> https://github.com/bitcoin/bitcoin/issues/9142 | Move -salvagewallet, -zap(wtx) to where they belong by jonasschnelli · Pull Request #9142 · bitcoin/bitcoin · GitHub
647 2016-11-17T22:23:31  *** Chris_Stewart_5 has quit IRC
648 2016-11-17T22:38:06  <meownow> could someone do an ELI5 for the debate that occurs RE this pull request? i kind of get it but at the same time am a bit confused
649 2016-11-17T22:38:44  <meownow> oops, this pull request: https://github.com/bitcoin/bitcoin/pull/63
650 2016-11-17T22:39:39  *** MarcoFalke has joined #bitcoin-core-dev
651 2016-11-17T22:39:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
652 2016-11-17T22:41:17  <sipa> meownow: it was later proposed as a BIP, and implemented in #707
653 2016-11-17T22:41:19  <gribble> https://github.com/bitcoin/bitcoin/issues/707 | Implement BIP 14 : separate protocol version from client version by gavinandresen · Pull Request #707 · bitcoin/bitcoin · GitHub
654 2016-11-17T22:46:13  <meownow> ty will check that out
655 2016-11-17T23:12:59  <jtimon> sipa: another related question why is https://github.com/bitcoin/bitcoin/pull/9125/files#diff-5cb8d9decaa15620a8f98b0c6c44da9bR382 necessary?
656 2016-11-17T23:13:05  <BlueMatt> jtimon/sipa do we care about https://github.com/bitcoin/bitcoin/pull/9075/files#r88568772 ?
657 2016-11-17T23:13:37  *** achow101 has left #bitcoin-core-dev
658 2016-11-17T23:18:51  *** meownow has quit IRC
659 2016-11-17T23:19:29  <jtimon> BlueMatt: I guess if we can maintain the printing of the error without much disruption that would be nice, but I don't really know how important this is for bip22, maybe luke-jr has an opinion on this?
660 2016-11-17T23:23:42  <jtimon> sipa: never mind, read more about move
661 2016-11-17T23:24:00  *** Alina-malina has quit IRC
662 2016-11-17T23:28:03  <bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014
663 2016-11-17T23:28:40  <BlueMatt> sipa: do you want me to go ahead and rebase ^ on the shared_ptr serialization from 9125?
664 2016-11-17T23:31:42  *** Alina-malina has joined #bitcoin-core-dev
665 2016-11-17T23:32:39  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute (master...Mf1611-blockFreeTxs) https://github.com/bitcoin/bitcoin/pull/9179
666 2016-11-17T23:34:46  *** MarcoFalke_web has quit IRC
667 2016-11-17T23:43:09  <bitcoin-git> [bitcoin] mruddy opened pull request #9180: WIP: remove script checking dependency on checkpoints v2 (master...isburied) https://github.com/bitcoin/bitcoin/pull/9180
668 2016-11-17T23:53:04  *** MarcoFalke has left #bitcoin-core-dev
669 2016-11-17T23:54:04  *** Guyver2 has quit IRC