1 2016-07-11T00:23:00  *** challisto has quit IRC
  2 2016-07-11T00:24:12  *** yy has joined #bitcoin-core-dev
  3 2016-07-11T00:27:03  *** yy has quit IRC
  4 2016-07-11T00:49:36  *** moli has joined #bitcoin-core-dev
  5 2016-07-11T00:52:43  *** molz has quit IRC
  6 2016-07-11T00:56:06  *** molz has joined #bitcoin-core-dev
  7 2016-07-11T00:57:47  *** belcher has quit IRC
  8 2016-07-11T00:58:41  *** belcher has joined #bitcoin-core-dev
  9 2016-07-11T00:58:51  *** moli has quit IRC
 10 2016-07-11T01:06:11  *** xiangfu has joined #bitcoin-core-dev
 11 2016-07-11T01:08:04  *** Chris_Stewart_5 has quit IRC
 12 2016-07-11T01:08:13  <GitHub125> [bitcoin] pstratem closed pull request #7940: [WIP] Fuzzing framework (master...2016-04-20-fuzzing-framework) https://github.com/bitcoin/bitcoin/pull/7940
 13 2016-07-11T01:08:58  <GitHub119> [bitcoin] pstratem closed pull request #8277: Refactor CBlockHeaderAndShortTxIDs::GetShortID into CTransaction (master...2016-06-26-ctransaction-getshortid) https://github.com/bitcoin/bitcoin/pull/8277
 14 2016-07-11T01:20:34  *** belcher has quit IRC
 15 2016-07-11T01:25:46  *** Ylbam has quit IRC
 16 2016-07-11T01:51:15  *** PRab has joined #bitcoin-core-dev
 17 2016-07-11T01:56:26  *** rrt has joined #bitcoin-core-dev
 18 2016-07-11T02:00:30  *** moli has joined #bitcoin-core-dev
 19 2016-07-11T02:02:34  *** molz has quit IRC
 20 2016-07-11T02:19:39  *** molz has joined #bitcoin-core-dev
 21 2016-07-11T02:22:45  *** moli has quit IRC
 22 2016-07-11T02:40:02  *** moli has joined #bitcoin-core-dev
 23 2016-07-11T02:41:47  *** molly has joined #bitcoin-core-dev
 24 2016-07-11T02:42:51  *** molz has quit IRC
 25 2016-07-11T02:44:06  *** molz has joined #bitcoin-core-dev
 26 2016-07-11T02:44:33  *** moli has quit IRC
 27 2016-07-11T02:46:57  *** molly has quit IRC
 28 2016-07-11T02:56:53  *** moli has joined #bitcoin-core-dev
 29 2016-07-11T02:59:33  *** molz has quit IRC
 30 2016-07-11T03:15:36  *** Justinus has quit IRC
 31 2016-07-11T03:27:20  *** Sosumi has quit IRC
 32 2016-07-11T03:35:46  *** cryptapus_ has joined #bitcoin-core-dev
 33 2016-07-11T03:35:46  *** cryptapus_ has joined #bitcoin-core-dev
 34 2016-07-11T03:42:45  *** JackH has quit IRC
 35 2016-07-11T04:02:17  *** Alopex has quit IRC
 36 2016-07-11T04:03:22  *** Alopex has joined #bitcoin-core-dev
 37 2016-07-11T04:50:11  *** Alopex has quit IRC
 38 2016-07-11T04:51:16  *** Alopex has joined #bitcoin-core-dev
 39 2016-07-11T05:06:26  *** Alopex has quit IRC
 40 2016-07-11T05:07:32  *** Alopex has joined #bitcoin-core-dev
 41 2016-07-11T05:31:43  *** molz has joined #bitcoin-core-dev
 42 2016-07-11T05:32:11  *** moli has quit IRC
 43 2016-07-11T05:33:58  *** cryptapus_ has quit IRC
 44 2016-07-11T05:56:05  *** paveljanik has quit IRC
 45 2016-07-11T05:57:15  *** GreenIsMyPepper has quit IRC
 46 2016-07-11T05:59:35  *** GreenIsMyPepper has joined #bitcoin-core-dev
 47 2016-07-11T06:07:11  *** Alopex has quit IRC
 48 2016-07-11T06:08:16  *** Alopex has joined #bitcoin-core-dev
 49 2016-07-11T06:20:13  *** GreenIsMyPepper has quit IRC
 50 2016-07-11T06:22:11  *** GreenIsMyPepper has joined #bitcoin-core-dev
 51 2016-07-11T07:07:48  *** MarcoFalke has left #bitcoin-core-dev
 52 2016-07-11T07:11:21  *** GreenIsMyPepper has quit IRC
 53 2016-07-11T07:13:12  *** GreenIsMyPepper has joined #bitcoin-core-dev
 54 2016-07-11T07:17:25  *** GreenIsMyPepper has quit IRC
 55 2016-07-11T07:19:42  *** GreenIsMyPepper has joined #bitcoin-core-dev
 56 2016-07-11T07:31:52  *** Ylbam has joined #bitcoin-core-dev
 57 2016-07-11T07:32:35  *** GreenIsMyPepper has quit IRC
 58 2016-07-11T07:34:44  *** GreenIsMyPepper has joined #bitcoin-core-dev
 59 2016-07-11T08:03:05  *** Guyver2 has joined #bitcoin-core-dev
 60 2016-07-11T08:03:36  *** jannes has joined #bitcoin-core-dev
 61 2016-07-11T08:05:43  *** fengling has joined #bitcoin-core-dev
 62 2016-07-11T08:12:57  *** assder has joined #bitcoin-core-dev
 63 2016-07-11T08:19:25  *** JackH has joined #bitcoin-core-dev
 64 2016-07-11T08:29:53  *** gabridome has quit IRC
 65 2016-07-11T08:37:02  *** arubi has quit IRC
 66 2016-07-11T08:41:09  *** arubi has joined #bitcoin-core-dev
 67 2016-07-11T09:03:24  <GitHub82> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67caef673089...26316ffa7dc5
 68 2016-07-11T09:03:24  <GitHub82> bitcoin/master 1ba3db6 Christian von Roques: bash-completion: Adapt for 0.12 and 0.13...
 69 2016-07-11T09:03:25  <GitHub82> bitcoin/master 26316ff Wladimir J. van der Laan: Merge #8289: bash-completion: Adapt for 0.12 and 0.13...
 70 2016-07-11T09:03:34  <GitHub140> [bitcoin] laanwj closed pull request #8289: bash-completion: Adapt for 0.12 and 0.13 (master...completion) https://github.com/bitcoin/bitcoin/pull/8289
 71 2016-07-11T09:10:50  <assder> When is the first release candidate for 0.13 expected?
 72 2016-07-11T09:13:49  <gmaxwell> "Soon"
 73 2016-07-11T09:22:29  *** Guyver2 has quit IRC
 74 2016-07-11T09:52:01  *** moli has joined #bitcoin-core-dev
 75 2016-07-11T09:53:40  <GitHub143> [bitcoin] laanwj pushed 3 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/080457c4ee97...5c8438207661
 76 2016-07-11T09:53:40  <GitHub78> [bitcoin] laanwj closed pull request #8318: [0.12] Backport "Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY #7540" (0.12...rename_nop3_0.12) https://github.com/bitcoin/bitcoin/pull/8318
 77 2016-07-11T09:53:41  <GitHub143> bitcoin/0.12 ac5577b BtcDrak: Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY
 78 2016-07-11T09:53:41  <GitHub143> bitcoin/0.12 c4e5688 BtcDrak: Rename NOP3 to CHECSEQUENCEVERIFY in rpc tests
 79 2016-07-11T09:53:42  <GitHub143> bitcoin/0.12 5c84382 Wladimir J. van der Laan: Merge #8318: [0.12] Backport "Rename OP_NOP3 to OP_CHECKSEQUENCEVERIFY #7540"...
 80 2016-07-11T09:54:18  *** molz has quit IRC
 81 2016-07-11T09:54:43  *** kadoban has quit IRC
 82 2016-07-11T10:06:27  *** kekstone has left #bitcoin-core-dev
 83 2016-07-11T10:09:49  *** YOU-JI has joined #bitcoin-core-dev
 84 2016-07-11T10:12:24  *** MarcoFalke has joined #bitcoin-core-dev
 85 2016-07-11T10:14:55  *** MarcoFalke has left #bitcoin-core-dev
 86 2016-07-11T10:16:45  *** rrt has quit IRC
 87 2016-07-11T10:20:51  *** mkarrer has joined #bitcoin-core-dev
 88 2016-07-11T10:29:25  <GitHub157> [bitcoin] laanwj pushed 2 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/5c8438207661...1233cb42dde9
 89 2016-07-11T10:29:25  <GitHub157> bitcoin/0.12 fe98533 Jonas Schnelli: [Qt] Disable some menu items during splashscreen/verification state...
 90 2016-07-11T10:29:25  <GitHub27> [bitcoin] laanwj closed pull request #8302: 0.12.2: [Qt] Disable some menu items during splashscreen/verification state (0.12...Mf1607-012qtDebugSplash) https://github.com/bitcoin/bitcoin/pull/8302
 91 2016-07-11T10:29:26  <GitHub157> bitcoin/0.12 1233cb4 Wladimir J. van der Laan: Merge #8302: 0.12.2: [Qt] Disable some menu items during splashscreen/verification state...
 92 2016-07-11T10:43:31  *** laurentmt has joined #bitcoin-core-dev
 93 2016-07-11T10:44:16  *** laurentmt has quit IRC
 94 2016-07-11T10:51:35  <GitHub118> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26316ffa7dc5...304eff3c614a
 95 2016-07-11T10:51:35  <GitHub118> bitcoin/master 477777f MarcoFalke: [rpcwallet] Don't use floating point
 96 2016-07-11T10:51:36  <GitHub118> bitcoin/master 304eff3 Wladimir J. van der Laan: Merge #8317: [rpcwallet] Don't use floating point...
 97 2016-07-11T10:51:45  <GitHub31> [bitcoin] laanwj closed pull request #8317: [rpcwallet] Don't use floating point (master...Mf1607-rpcFloat) https://github.com/bitcoin/bitcoin/pull/8317
 98 2016-07-11T11:12:49  *** MarcoFalke has joined #bitcoin-core-dev
 99 2016-07-11T11:25:07  *** jtimon has joined #bitcoin-core-dev
100 2016-07-11T11:40:29  *** arubi has quit IRC
101 2016-07-11T11:41:52  *** arubi has joined #bitcoin-core-dev
102 2016-07-11T11:54:57  *** arubi has quit IRC
103 2016-07-11T11:55:28  *** arubi has joined #bitcoin-core-dev
104 2016-07-11T11:58:45  <MarcoFalke> Who guessed it
105 2016-07-11T11:58:54  <sipa> ?
106 2016-07-11T11:58:56  <MarcoFalke> Of course windows test are timing out, ow
107 2016-07-11T11:59:41  <MarcoFalke> I am not sure why they don't work in parallel "out of the box"
108 2016-07-11T11:59:57  <MarcoFalke> Maybe wine can't handle it?
109 2016-07-11T12:00:00  <sipa> reduce their parallelism?
110 2016-07-11T12:00:49  *** laurentmt has joined #bitcoin-core-dev
111 2016-07-11T12:01:40  <MarcoFalke> There is already an overhead of about 2 for just using wine. Then, disabling parallel is another slowdown by 4.
112 2016-07-11T12:01:51  <MarcoFalke> So about 8 times longer rpc test for windows
113 2016-07-11T12:01:57  <sipa> fun.
114 2016-07-11T12:02:18  *** laurentmt has quit IRC
115 2016-07-11T12:06:25  <luke-jr> what? why would WINE have any overhead?
116 2016-07-11T12:23:11  *** Chris_Stewart_5 has joined #bitcoin-core-dev
117 2016-07-11T12:25:43  *** MarcoFalke has quit IRC
118 2016-07-11T13:06:53  *** MarcoFalke has joined #bitcoin-core-dev
119 2016-07-11T13:10:06  <wumpus> luke-jr: that's not really clear, I'd expect an overhead at startup/shutdown due to setting up the 'virtual windows environment', but not on networking
120 2016-07-11T13:10:59  *** harrymm has quit IRC
121 2016-07-11T13:12:03  <GitHub175> [bitcoin] jtimon opened pull request #8328: Consensus: Rename: Move consensus code to the consensus directory (master...0.12.99-consensus-rename) https://github.com/bitcoin/bitcoin/pull/8328
122 2016-07-11T13:14:37  <jtimon> ping kanzure ^^
123 2016-07-11T13:15:01  <jtimon> quite trivial to review, just touches the makefile and a bunch of includes
124 2016-07-11T13:16:01  <kanzure> thanks for the ping
125 2016-07-11T13:16:19  <jtimon> no problem, thanks for asking for it
126 2016-07-11T13:19:44  *** harrymm has joined #bitcoin-core-dev
127 2016-07-11T13:25:41  *** Chris_Stewart_5 has quit IRC
128 2016-07-11T13:27:32  *** YOU-JI has quit IRC
129 2016-07-11T13:30:57  *** harrymm has quit IRC
130 2016-07-11T13:31:26  *** harrymm has joined #bitcoin-core-dev
131 2016-07-11T13:33:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
132 2016-07-11T13:34:55  *** laurentmt has joined #bitcoin-core-dev
133 2016-07-11T13:35:28  *** laurentmt has quit IRC
134 2016-07-11T13:36:49  *** MarcoFalke has left #bitcoin-core-dev
135 2016-07-11T13:41:09  *** assder has quit IRC
136 2016-07-11T13:42:24  <jtimon> sipa: what's the advantage of validating this https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L3558 in ContextualCheckBlock() instead of ConnectBlock() ?
137 2016-07-11T13:42:59  <jtimon> and the same question kind of applies to the other 2 consensus checks in there
138 2016-07-11T13:43:43  <jtimon> in other words would it be crazy to move all those checks to just connectblock? why?
139 2016-07-11T13:45:11  <jtimon> or in other words, is it necessary or advantageous to call ContextualCheckBlock() in other places other than ConnectBlock() in some way I'm missing?
140 2016-07-11T13:45:26  <jtimon> answers from anyone welcomed
141 2016-07-11T13:46:58  *** GreenIsMyPepper has quit IRC
142 2016-07-11T13:48:11  <sipa> jtimon: contextualcheckblock runs before storing a block on disk, connectblock after
143 2016-07-11T13:48:44  *** molz has joined #bitcoin-core-dev
144 2016-07-11T13:48:45  <sipa> so everything that can be in contextualcheckblock should be, as it make attacks that cause disk space wasting harder
145 2016-07-11T13:48:45  *** GreenIsMyPepper has joined #bitcoin-core-dev
146 2016-07-11T13:49:08  <jtimon> I see, so the advantage is to discard offending blocks before storing them on disk for checks that are relatively cheap
147 2016-07-11T13:49:29  <jtimon> I didn't knew we stored invalid blocks at all
148 2016-07-11T13:49:48  <jtimon> why do we store invalid blocks?
149 2016-07-11T13:50:58  *** moli has quit IRC
150 2016-07-11T13:51:06  <sipa> because we can't know until we reorg the chainstate
151 2016-07-11T13:51:27  <sipa> we may accept a block on a side branch that does not overtake the best chai  yet
152 2016-07-11T13:51:32  <sipa> *chain
153 2016-07-11T13:51:55  <jtimon> but it's still valid, no?
154 2016-07-11T13:52:09  <sipa> we can't know that without reorg
155 2016-07-11T13:52:21  <sipa> because we need the utxo set for its parent
156 2016-07-11T13:52:28  <jtimon> we can know whether a block is valid in its chain without knowing whether it belongs to the "longest" chain or not, right?
157 2016-07-11T13:52:38  <sipa> in theory, yes
158 2016-07-11T13:52:43  <sipa> in practice, no
159 2016-07-11T13:52:55  <sipa> because we don't have its utxoset we can't validate
160 2016-07-11T13:53:19  <jtimon> oh, I see, we never build incompatible utxo histories
161 2016-07-11T13:53:38  <sipa> right, we just have a single utxo set for the tip
162 2016-07-11T13:54:04  <sipa> and delay full validation until we're forced to switch tips
163 2016-07-11T13:54:15  <jtimon> I thought that was part of the CCoinsViewCache purpose...
164 2016-07-11T13:55:14  <jtimon> but I guess yeah, it doesn't make sense to fully validate until you're forced to reorg by the accumulated pow, storing that block is cheaper I guess
165 2016-07-11T13:55:18  <sipa> no, that's just so we don't have to write everything to disk immediately
166 2016-07-11T13:55:42  <sipa> now, pow is the most expensive thing for an attacker
167 2016-07-11T13:56:03  <sipa> so everything that comes after pow validation and corruption checks does not matter very much
168 2016-07-11T13:56:09  <sipa> why are you asking, btw?
169 2016-07-11T13:56:17  <sipa> ah, i know
170 2016-07-11T13:56:27  <sipa> iswitnessenabled depends on versionbits
171 2016-07-11T13:56:38  <jtimon> mhmm, why do we validate any part of a block that we don't see as belonging to the longest chain at all?
172 2016-07-11T13:57:28  <sipa> because we at least need to know whether it is actually the right block
173 2016-07-11T13:57:42  <sipa> a peer could change one transaction before relay
174 2016-07-11T13:57:43  <jtimon> sipa: it was part of my latest consensus refactor branch to get rid of ContextualCheckBlock()
175 2016-07-11T13:58:06  <sipa> and in that case we must punish the peer, but not mark the block as invalid
176 2016-07-11T13:58:32  <sipa> so an invariant is that all blocks on disk are known to actually match the blocks whose headers we know
177 2016-07-11T13:59:42  <jtimon> if we know it's not making a longer chain, why bother validating BIP113 ?
178 2016-07-11T14:00:15  <sipa> validating bip113 is not necessary i think
179 2016-07-11T14:00:30  <sipa> but the segwit commitment check is
180 2016-07-11T14:01:10  <sipa> before storing on disk
181 2016-07-11T14:01:25  *** Chris_Stewart_5 has quit IRC
182 2016-07-11T14:02:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
183 2016-07-11T14:03:42  <jtimon> that's useful, what about the bip34 check in ContextualCheckBlock(), can it be moved out?
184 2016-07-11T14:04:02  <sipa> i believe so
185 2016-07-11T14:04:12  <jtimon> ok, thanks
186 2016-07-11T14:04:31  <jtimon> but not the new segwit one, fine
187 2016-07-11T14:06:38  <jtimon> well, I would prefer to pass the consensus validation flags instead of calling IsWitnessEnabled() from there
188 2016-07-11T14:08:41  <jtimon> but I should try to write that first before discussing it further
189 2016-07-11T14:11:56  *** Sosumi has joined #bitcoin-core-dev
190 2016-07-11T14:32:02  *** Chris_Stewart_5 has quit IRC
191 2016-07-11T14:32:18  *** achow101 has quit IRC
192 2016-07-11T14:36:07  *** laurentmt has joined #bitcoin-core-dev
193 2016-07-11T14:37:01  *** laurentmt has quit IRC
194 2016-07-11T14:42:11  *** Giszmo has joined #bitcoin-core-dev
195 2016-07-11T14:46:57  *** Chris_Stewart_5 has joined #bitcoin-core-dev
196 2016-07-11T15:24:17  <sdaftuar> reviewers, please review some open PRs for 0.13.0: #8295, #8305, #8312
197 2016-07-11T15:38:18  *** harrymm has quit IRC
198 2016-07-11T15:38:40  *** harrymm has joined #bitcoin-core-dev
199 2016-07-11T15:42:08  *** harrymm has quit IRC
200 2016-07-11T15:42:34  *** harrymm has joined #bitcoin-core-dev
201 2016-07-11T15:43:01  *** bsm117532 has quit IRC
202 2016-07-11T15:43:36  *** bsm117532 has joined #bitcoin-core-dev
203 2016-07-11T15:44:14  *** bsm117532 has quit IRC
204 2016-07-11T15:44:43  *** bsm117532 has joined #bitcoin-core-dev
205 2016-07-11T15:45:35  *** harrymm has quit IRC
206 2016-07-11T15:45:45  *** Chris_Stewart_5 has quit IRC
207 2016-07-11T15:46:23  *** achow101 has joined #bitcoin-core-dev
208 2016-07-11T16:04:22  *** a87ry5 has joined #bitcoin-core-dev
209 2016-07-11T16:07:22  *** GreenIsMyPepper has quit IRC
210 2016-07-11T16:12:19  *** a87ry5 has quit IRC
211 2016-07-11T16:13:41  *** spudowiar has joined #bitcoin-core-dev
212 2016-07-11T16:16:33  *** harrymm has joined #bitcoin-core-dev
213 2016-07-11T16:17:57  *** GreenIsMyPepper has joined #bitcoin-core-dev
214 2016-07-11T16:34:25  *** BTCking has joined #bitcoin-core-dev
215 2016-07-11T16:34:26  <BTCking> AMAZING! My bitcoin-grower is now ready. Send me some bitcoin (1btc, 2btc, etc.) and get MUCH more back INSTANTLY. This uses Block-chain explanding technology! Proven safe & secure. You cannot lose. PM me to begin!!
216 2016-07-11T16:35:34  <sipa> BTCking: fuck off
217 2016-07-11T16:35:49  * BTCking slaps sipa around a bit with a large trout
218 2016-07-11T16:35:49  <BTCking> AMAZING! My bitcoin-grower is now ready. Send me some bitcoin (1btc, 2btc, etc.) and get MUCH more back INSTANTLY. This uses Block-chain explanding technology! Proven safe & secure. You cannot lose. PM me to begin!!
219 2016-07-11T16:36:46  *** sipa has quit IRC
220 2016-07-11T16:36:46  *** sipa has joined #bitcoin-core-dev
221 2016-07-11T16:36:56  *** ChanServ sets mode: +o sipa
222 2016-07-11T16:37:02  *** sipa sets mode: +b *!*wowperson@*.hsd1.wa.comcast.net
223 2016-07-11T16:37:02  *** BTCking was kicked by sipa (BTCking)
224 2016-07-11T16:37:35  *** LeMiner2 has joined #bitcoin-core-dev
225 2016-07-11T16:39:16  *** LeMiner has quit IRC
226 2016-07-11T16:39:16  *** LeMiner2 is now known as LeMiner
227 2016-07-11T16:47:08  <GitHub65> [bitcoin] jtimon opened pull request #8329: Consensus: MOVEONLY: Move functions for tx verification (master...0.12.99-consensus-moveonly-tx) https://github.com/bitcoin/bitcoin/pull/8329
228 2016-07-11T16:49:04  <jtimon> kanzure: ping again, still quite simple to review and re-write
229 2016-07-11T17:04:56  *** dgenr8 has quit IRC
230 2016-07-11T17:09:00  *** dgenr8 has joined #bitcoin-core-dev
231 2016-07-11T17:10:27  *** spudowiar has quit IRC
232 2016-07-11T17:13:40  *** Giszmo has quit IRC
233 2016-07-11T17:14:51  *** Giszmo has joined #bitcoin-core-dev
234 2016-07-11T17:16:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
235 2016-07-11T17:28:04  *** Chris_Stewart_5 has quit IRC
236 2016-07-11T17:30:56  *** droark has joined #bitcoin-core-dev
237 2016-07-11T17:35:25  *** BCBot has quit IRC
238 2016-07-11T17:35:42  *** BCBot has joined #bitcoin-core-dev
239 2016-07-11T17:38:34  *** molz has quit IRC
240 2016-07-11T17:39:03  *** moli has joined #bitcoin-core-dev
241 2016-07-11T17:46:05  *** BCBot2 has joined #bitcoin-core-dev
242 2016-07-11T17:46:22  *** BCBot2 has quit IRC
243 2016-07-11T17:48:19  *** BCBot2 has joined #bitcoin-core-dev
244 2016-07-11T17:50:02  *** BCBot2 has joined #bitcoin-core-dev
245 2016-07-11T17:51:52  *** BCBot2 has quit IRC
246 2016-07-11T17:52:31  *** BCBot2 has joined #bitcoin-core-dev
247 2016-07-11T17:55:25  *** BCBot2 has joined #bitcoin-core-dev
248 2016-07-11T17:57:27  *** BCBot2 has joined #bitcoin-core-dev
249 2016-07-11T17:57:57  *** BCBot2 has quit IRC
250 2016-07-11T18:00:26  *** BCBot2 has joined #bitcoin-core-dev
251 2016-07-11T18:03:52  *** mkarrer has quit IRC
252 2016-07-11T18:10:13  *** kadoban has joined #bitcoin-core-dev
253 2016-07-11T18:10:31  <sipa> sdaftuar: done
254 2016-07-11T18:10:35  *** sipa sets mode: -o sipa
255 2016-07-11T18:10:40  <sdaftuar> sipa: thanks!
256 2016-07-11T18:13:45  <sipa> github.com down?
257 2016-07-11T18:15:01  <eragmus> sipa: http://www.isup.me/github.com
258 2016-07-11T18:15:39  <eragmus> http://isitdownorjust.me/github-com/
259 2016-07-11T18:16:03  <sipa> thanks
260 2016-07-11T18:16:07  <sipa> it also works from my vps...
261 2016-07-11T18:16:41  <tadasv> working fine for me
262 2016-07-11T18:19:26  *** mkarrer has joined #bitcoin-core-dev
263 2016-07-11T18:19:54  *** spudowiar has joined #bitcoin-core-dev
264 2016-07-11T18:33:29  <gmaxwell> sdaftuar: maybe it doesn't matter because its a corner case, but #8305 makes it look like it will effectively discard the dangling header-- it pushmessages a getheaders and returns, without AcceptBlockHeader or UpdateBlockAvailability.
265 2016-07-11T18:33:51  <sdaftuar> oh, UpdateBlocKAvailability, hmm
266 2016-07-11T18:34:23  *** Guyver2 has joined #bitcoin-core-dev
267 2016-07-11T18:34:38  <gmaxwell> Is the expectation that it'll come back in via the getheaders, and that the remote end won't do anything smart like not send it because it already did?  (I guess thats reasonable?) though the lack of updateavailablity probably means we'll send a redundant announcement in that direction.
268 2016-07-11T18:35:01  <sdaftuar> well there's no way to avoid getting the headers message back to you
269 2016-07-11T18:35:16  <sdaftuar> if you set hashstop equal to the hash of that header, it'll still appear in the response
270 2016-07-11T18:35:40  <sdaftuar> i don't think the remote end is allowed to not re-send, though i suppose lack of a spec makes this a difficult statement to concretely make
271 2016-07-11T18:35:59  <sdaftuar> but we expect the contents of a headers message to be a linear connecting chain
272 2016-07-11T18:36:14  <gmaxwell> K. That makes sense, I thought that was the assumption but wanted to be sure (I think it's correct.)
273 2016-07-11T18:37:37  <sdaftuar> i guess there could be an advantage to setting hashLastUnknownBlock if a header doesn't connect... that would mean that if a different peer supplied the missing headers, we could download the block from the peer who made the announcement
274 2016-07-11T18:37:51  <sdaftuar> but that would only matter if the peer didn't respond to the getheaders being pushed in this patch
275 2016-07-11T18:38:05  <gmaxwell> so now let me ask, if I send you a header that doesn't connect because of timestamp stupidity. And I'm your only peer. If there are two blocks in a row during the time when the prior header will be rejected... When will it start connecting again?  I'll get the flag false on me, then it'll never be sent to true, since all further headers I send will also not connect.
276 2016-07-11T18:38:07  <sdaftuar> which is a weird corner case
277 2016-07-11T18:38:38  <gmaxwell> On the update front, I was mostly think in terms of not sending surpflous compact block messages.
278 2016-07-11T18:38:56  <sdaftuar> when you respond to the getheaders, the bit is cleared
279 2016-07-11T18:39:29  <midnightmagic> ;;isitdown github.com
280 2016-07-11T18:39:30  <gribble> github.com is up
281 2016-07-11T18:40:05  <sdaftuar> and the headers will start connecting again
282 2016-07-11T18:40:08  <sdaftuar> well,
283 2016-07-11T18:40:11  <sdaftuar> unless the time stamp is still broken
284 2016-07-11T18:40:30  *** xinxi has joined #bitcoin-core-dev
285 2016-07-11T18:40:44  <gmaxwell> hm. I was thinking that it wouldn't be set to true if the getheaders reply also didn't connect due to bad timestamps.
286 2016-07-11T18:41:26  <xinxi> Hi guys
287 2016-07-11T18:41:42  <xinxi> Anybody here?
288 2016-07-11T18:42:11  <sdaftuar> gmaxwell: yeah, i can't solve the problem of a bunch of blocks in a row all being invalid to one peer but not another
289 2016-07-11T18:42:22  <sdaftuar> but typically, the first block is too far ahead
290 2016-07-11T18:42:36  <sdaftuar> and then by the time the next block comes in, you would be able to accept both
291 2016-07-11T18:42:46  <sdaftuar> if you'd be willing to try
292 2016-07-11T18:42:50  <sdaftuar> but we have no "try" mechanism currently
293 2016-07-11T18:43:39  <sdaftuar> i guess the question is, what should we do if a peer is relaying many blocks in a row that are all actually too far in the future?
294 2016-07-11T18:43:52  <sdaftuar> i just fall back to the current behavior of failing/disconnecting
295 2016-07-11T18:45:09  <sdaftuar> i did briefly think about whether it would be feasible to somehow accept headers that are too far in the future, but i'm pretty sure that's a major rewrite to our consensus logic
296 2016-07-11T18:45:27  <sdaftuar> (accept them, so that you could re-try them later)
297 2016-07-11T18:50:15  <sdaftuar> gmaxwell: perhaps we could always send a getheaders if the peer is whitelisted?
298 2016-07-11T18:51:52  *** spudowiar has quit IRC
299 2016-07-11T18:52:32  <gmaxwell> I don't think that would be an awful thing, but I don't think it addresses the concern-- you shouldn't only fail to fail if you have whitelisted peers.
300 2016-07-11T18:53:25  <sdaftuar> i guess i could do the thing you imply -- actually just check to see if the headers connect, and use that to re-set the bit
301 2016-07-11T18:55:03  <gmaxwell> maybe I'm misunderstanding, but that situation I'm thinking about is if you're slow on time by a few seconds, rejected a block, then the next comes in, and it still doesn't connect... you're going to stop sending getheaders after that. Then no others will connect from that peer.  The time is a bit freaky, since it's a temporary failure.
302 2016-07-11T18:55:33  <sdaftuar> yes, i agree your example is a correct one
303 2016-07-11T18:55:53  <sdaftuar> i'm just trying to distinguish that from an example where an attacker sends you a chain that's far into the future
304 2016-07-11T18:56:59  <gmaxwell> I think we award a little bit of misbehaving there. Ironically, for sync purposes it might be better to immediately disconnect: at least that will clear the flag! :)
305 2016-07-11T18:58:34  <gmaxwell> relying on DOS disconnect to make progress is weird though, but I think thats the answer here: after some number non-connecting blocks I think you'll disconnect the peer.  When you reconnect, the flag will be true and you'll try to sync again.
306 2016-07-11T18:59:37  <gmaxwell> sdaftuar: to prevent looping, why not store the most recent ID. And don't getheader again if it's the same?
307 2016-07-11T19:00:09  <gmaxwell> e.g. block announce, doesn't connect, store the most recent ID and getheader. Get headers, still doesn't connect and most recent ID is the same. Stop.
308 2016-07-11T19:00:39  <sdaftuar> sorry, what is most recent ID?
309 2016-07-11T19:01:20  <gmaxwell> when the headers response comes in take the ID (hash) of the latest block in the reply. And do not keep requesting headers when that value hasn't changed for this peer.
310 2016-07-11T19:02:05  <gmaxwell> I announce X, X doesn't connect. Remember X, request headers.  Headers come in, they tell you a bunch of junk ending at X. Still doesn't connect. Stop.
311 2016-07-11T19:02:38  <sdaftuar> gmaxwell: i guess i just worry about assuming too much about the broken implementations out there
312 2016-07-11T19:02:53  *** xinxi has quit IRC
313 2016-07-11T19:02:54  <sdaftuar> eg maybe the peer who was sending me 160kb of junk was sending me random junk
314 2016-07-11T19:04:06  <gmaxwell> Well thats what misbehaving is for.
315 2016-07-11T19:04:07  *** xinxi has joined #bitcoin-core-dev
316 2016-07-11T19:04:33  <sdaftuar> but in your example, wouldn't that behavior result in infinite loop?
317 2016-07-11T19:05:04  <gmaxwell> The headers reply would end with the block X, which we already had remembered, so we would stop there.
318 2016-07-11T19:05:21  <gmaxwell> no loop. then they later announce block y, and we'd getheaders again. and hopefully connect.
319 2016-07-11T19:05:32  <gmaxwell> So basically  one headers retry per novel header they send.
320 2016-07-11T19:05:45  <sdaftuar> i'm specifically referring to peers that are totally broken and on initial getheaders sync, they send us 2000 headers that don't connect
321 2016-07-11T19:06:39  <sdaftuar> i don't want to assume too much about how that peer is doing that
322 2016-07-11T19:06:51  <gmaxwell> sure, whatever, testnet node on mainnet or whatnot.
323 2016-07-11T19:06:58  <sdaftuar> if getting it wrong means 160kb over and over again...
324 2016-07-11T19:07:32  <gmaxwell> just don't assume it's malicious, since there are better ways to waste our bandwidth for malicious peers.
325 2016-07-11T19:08:14  <sdaftuar> well you're suggesting we assume it's deterministic i think.  which is hopefully true, but if it's not, then sadness
326 2016-07-11T19:08:45  <gmaxwell> yes, indeed, and actually the 2000 limit gets in the way too.
327 2016-07-11T19:09:15  <sdaftuar> i mean, i think in practice your suggestion probably works, i was just hoping for something more robust to accidental disaster
328 2016-07-11T19:10:24  <gmaxwell> speaking of 2000, I'm not seeing how what you suggest doesn't actually break sync.
329 2016-07-11T19:10:36  <sipa> can i get a summary of the problem?
330 2016-07-11T19:11:19  <gmaxwell> oh nevermind last comment, I was mistaking the order.
331 2016-07-11T19:11:31  <sdaftuar> sipa: i noticed on testnet that i had a node that would fall out of sync, because its one peer would occasionally send a block header (using headers announcements) that was too far in the future
332 2016-07-11T19:11:39  <gmaxwell> (I was thinking that we'd request headers, if there was more than 2000 missing, that they sent the later headers first)
333 2016-07-11T19:11:45  <sdaftuar> so the peer thought the header was valid, but the local node would reject
334 2016-07-11T19:11:56  <sdaftuar> this is a case i had never thought of when working on the headers announcements stuff
335 2016-07-11T19:12:21  <sdaftuar> since the announcing peer doesn't realize the recipient rejects the header, they continue to announce blocks on top of the header
336 2016-07-11T19:12:35  <sipa> sdaftuar: yes, i get that
337 2016-07-11T19:12:43  <sipa> but you have a patch for that
338 2016-07-11T19:12:43  <sdaftuar> resulting in headers announcements that don't connect for the recipient, and then eventually disconnect
339 2016-07-11T19:13:06  <xinxi> hey guys, I want to make Bitcoin provably correct.
340 2016-07-11T19:13:08  <sdaftuar> oh right.  so gmaxwell wonders if we can avoid failure in the case where two blocks come in quickly, where the first block is still invalid when the second one is announced
341 2016-07-11T19:13:17  <sdaftuar> my patch doesn't address that
342 2016-07-11T19:13:19  <xinxi> I am serious.
343 2016-07-11T19:13:31  <sipa> xinxi: you'll need to be a bit more specific
344 2016-07-11T19:13:56  <sipa> what part do you want to prove?
345 2016-07-11T19:14:02  <gmaxwell> sipa: and sdaftuar is concerned that relaxations will leave it in a state where its constantly requesting headers over and over again.
346 2016-07-11T19:14:17  <xinxi> sipa: thank you for your attention. Yeah, basically, I think bugs are still in the C++ implementation. And I want to make sure it's absolutely correct.
347 2016-07-11T19:14:27  <xinxi> so there will be no bugs.
348 2016-07-11T19:14:44  <sipa> xinxi: that implies you have a specification for correct to compare to
349 2016-07-11T19:14:46  <gmaxwell> I think this could be addressed by just adding a small amount of DOS each time.
350 2016-07-11T19:15:09  <gmaxwell> Correct with respect to a specification may well be meaningless if the specification is not "correct" in a broader sense.
351 2016-07-11T19:15:22  <xinxi> sipa: yeah, I want to work out a formal specification as well.
352 2016-07-11T19:15:26  <sipa> xinxi: for the consensus logic, the code implementation is the specification, so it is by definition correct
353 2016-07-11T19:15:37  <xinxi> something like mathematical theorems about the code.
354 2016-07-11T19:15:55  <sipa> xinxi: however, being able to verify that the behaviour of that code does not change between releases would be incredibly valuable
355 2016-07-11T19:16:37  <sipa> unfortunately, due to historical reasons mostly, the consensus code is not well separated from the rest
356 2016-07-11T19:16:39  <gmaxwell> sdaftuar: e.g. I think we could just trigger a getheaders on any header message with only a single header in it that doesn't connect, and add a small dos penalty.
357 2016-07-11T19:16:43  <xinxi> sipa: I understand what you mean. The code, as a specification, may not be consistent with itself.
358 2016-07-11T19:16:52  <gmaxwell> sdaftuar: then every new block that shows up on the network will cause us to retry to connect.
359 2016-07-11T19:16:54  <morcos> i know this sounds kind of janky, but it seems to me that a lot of this sync logic is stuff that to a human is kind of obviously stupid.  i wonder if putting in a bit of belt and suspender check on things getting stuck might make sense.
360 2016-07-11T19:17:25  <sipa> xinxi: indeed. not consistent with itself, or not consistent with other implementations/versions
361 2016-07-11T19:17:28  <gmaxwell> sdaftuar: and eventually it will either connect, or disconnect the peer.
362 2016-07-11T19:17:43  <xinxi> sipa: also, you may not want to treat bugs as part of the specification like the heartbleed bug in OpenSSL should not be part of OpenSSL.
363 2016-07-11T19:17:56  <sipa> xinxi: we have to
364 2016-07-11T19:17:57  <btcdrak> xinxi: there is a slow and arduous process of extracting the consensus code into a separate library which will make things a lot easier in the long run.
365 2016-07-11T19:18:11  <morcos> for instance very 60 secs you clear out some state such as fLastHeadersConnected and perhaps nSyncStarted (maybe only if we're not actively receiving headers)
366 2016-07-11T19:18:19  <morcos> i'm sure we can imagine other things that kind of get stuck
367 2016-07-11T19:18:24  <xinxi> btcdrak: I've heard of that. It's libconsensus, isn't it?
368 2016-07-11T19:18:27  <gmaxwell> morcos: you mean like a periodic, pick a random peer and restart our efforts to sync with it? and loudly logging that the sync state machine has failed if that accomplishes anything?
369 2016-07-11T19:18:37  <sipa> xinxi: even if we would write down a specification for the behaviour, and every one would agree that that spec is indeed the behaviour we want
370 2016-07-11T19:18:54  <sipa> xinxi: what if we then find a bug, and the code does something slightly different?
371 2016-07-11T19:18:55  <sdaftuar> gmaxwell: i think that sounds pretty good, though the DoS score should decay back down once headers that do connect are received, right?  otherwise, over a long enough period of time, you eventually disconnect your peer
372 2016-07-11T19:19:12  <morcos> gmaxwell: yes something along those lines, i like the idea of loudly announcing it so we try to make stuff work in general, but that next time we miss something, hopefully it kind of autorecovers (like power cycling)
373 2016-07-11T19:19:13  <btcdrak> xinxi: the problem is it's quite disruptive to the codebase and causes everyone's pull-requests to need rebasing so it tends to get done slowly and in bursts. yes it's called libconsensus
374 2016-07-11T19:19:23  <gmaxwell> sdaftuar: yea, :( the whole dos score thing is kinda lame.
375 2016-07-11T19:19:25  <xinxi> btcdrak: but still, that probably reduces bugs in the consensus part, but still it does not guarantee the correctness.
376 2016-07-11T19:19:29  <sipa> xinxi: the code would have a bug, arguably. but we can't tell everyone to change their code, so it will need to be the document that had to be changed
377 2016-07-11T19:19:59  <gmaxwell> morcos: I agree with that in principle. We don't however, want to end up with a web of redundant mechenisms, potentially interacting.
378 2016-07-11T19:20:16  <sipa> xinxi: so we've usually said that a specification for bitcoin would be descriptive but not prescriptive... the laws of the network are those implemented by the code that people choose to run, not by an abstract descriptio
379 2016-07-11T19:20:22  <morcos> a bigger web you mean?
380 2016-07-11T19:20:27  <gmaxwell> morcos: hah
381 2016-07-11T19:20:47  <sdaftuar> unfortunately some of the bugs we've encountered (eg that hasHeaders thing that got reverted) wouldn't be fixed on restart either
382 2016-07-11T19:20:58  <sipa> for 0.14 i think we need to refactor the sync code
383 2016-07-11T19:21:07  * sdaftuar ducks
384 2016-07-11T19:21:10  <sipa> many parallel mechanisms and duplicated code
385 2016-07-11T19:21:17  <gmaxwell> sdaftuar: you could instead have a simple counter, set to zero whenever you connect, incremented on every non-connecting header response. And dos score only when it hits a threshold to avoid that effect.
386 2016-07-11T19:21:25  <sipa> no blame anywhere, but we've accumulated too much technical debt
387 2016-07-11T19:21:40  <sdaftuar> gmaxwell: yep that's what i was thinking too
388 2016-07-11T19:21:48  <gmaxwell> sdaftuar: I believe thats the first sync stuck bug I've ever seen that wasn't fixed on a restart.
389 2016-07-11T19:22:07  <sdaftuar> i think i've seen 0.9 nodes not be able to recover from restart
390 2016-07-11T19:22:09  <xinxi> sipa: we don't have to be like that. I was motivated by the project CompCert and SEL4. SEL4 is a OS kernel that's proved to be 100% consistent with the specification.
391 2016-07-11T19:22:27  <sipa> xinxi: that implies you have a specification
392 2016-07-11T19:22:37  <sipa> as i've said before, we can't have one
393 2016-07-11T19:22:46  <sipa> we can describe the current behaviour
394 2016-07-11T19:22:52  <gmaxwell> sdaftuar: well there was also the "stops on too many orphans" stuff between ~0.8 and 0.10.
395 2016-07-11T19:22:59  <sipa> and then formally prove that future code matches that behaviour
396 2016-07-11T19:23:47  <gmaxwell> (where it would start fetching blocks backwards, run into a 750 block orphan limit then stop, but even that could recover with enough restarts)
397 2016-07-11T19:24:25  <xinxi> sipa: I just don't understand the factor that stops us from driving a formal specification from the code.
398 2016-07-11T19:24:42  <gmaxwell> sdaftuar: in any case, I think doing get headers triggered on single header responses, and counting the failures, and DOSing on too many failures... would address both our concerns here.
399 2016-07-11T19:25:05  <sipa> xinxi: deriving? yes, we could
400 2016-07-11T19:25:12  <sdaftuar> gmaxwell: sounds right to me as well.  for 0.13.0?
401 2016-07-11T19:25:40  <sipa> xinxi: i guess my point is that the only way to write a formal specification is by extracting it from the actually implemented and deployed code
402 2016-07-11T19:25:41  <xinxi> sipa: yeah, that's where we can start from.
403 2016-07-11T19:25:58  <sipa> xinxi: and not from behaviour that humans write
404 2016-07-11T19:25:59  <btcdrak> xinxi: the difficulty is if the code differs from the written specification the code wins. Even if you class it as a bug, changing it is extremely hard because you have to change the network consensus. There are examples where this has happened and we've just had to live with the bug.
405 2016-07-11T19:26:09  <gmaxwell> Yes, I think it wouldn't be more complex than that patch you currently have. (this is also not just a testnet problem-- we're just fortunate that miners have lately not be excessively rolling their timestamps forward...)
406 2016-07-11T19:26:40  <btcdrak> xinxi: the other problem is unknown bugs which we might not be aware of, rare edge cases say, are actually part of the consensus rules even if we dont know it.
407 2016-07-11T19:26:46  <sdaftuar> ok i'll see if i can whip up an improved patch
408 2016-07-11T19:26:56  <gmaxwell> btcdrak: the kind of "formal specification" in the sense of SEL4 can be proven to agree with the code (effectively, the specification is at least as complex as the implementation)
409 2016-07-11T19:26:58  <btcdrak> xinxi: so it's hard to document things you dont know
410 2016-07-11T19:27:05  <xinxi> @btcdrak those rare edge bugs can be eliminated by formal proofs I think.
411 2016-07-11T19:27:26  <btcdrak> xinxi: seems like a very worthwhile pursuit though.
412 2016-07-11T19:27:59  <xinxi> so the motivation of this is to avoid catastrophic failures of Bitcoin.
413 2016-07-11T19:28:04  <sipa> xinxi: for example, for a long time, bitcoin relied on OpenSSL's signature parsing code
414 2016-07-11T19:28:14  <sipa> xinxi: people thought they knew what this code did
415 2016-07-11T19:28:23  <sipa> xinxi: and reimplemented the logic in other places
416 2016-07-11T19:28:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
417 2016-07-11T19:28:41  <sipa> but nobody checked that what they thought actually matched what openssl was doing
418 2016-07-11T19:28:45  <sipa> turns out, it didn't
419 2016-07-11T19:29:14  <sipa> so now bitcoin's "specification" implicitly depended on OpenSSL's implementation
420 2016-07-11T19:29:29  <xinxi> sipa: this kind of inconsistencies can be eliminated by formal proofs as well.
421 2016-07-11T19:29:34  <sipa> xinxi: absolutely
422 2016-07-11T19:29:56  <sipa> xinxi: but only if they would take OpenSSL's code into account and analyse it, and not treat it as a black box
423 2016-07-11T19:30:05  <gmaxwell> xinxi: I'm not sure if you have a grasp of the difficulty of what you're thinking about, go look at the size of the SEL4 kernel. I believe it's about 4000 lines of C.  The isabelle specification for it is something like a half million lines, and though it proves many useful things about it, it falls far short of proving so much that agreement with the spec would be equivilent to correct in a hum
424 2016-07-11T19:30:11  <gmaxwell> an sense.
425 2016-07-11T19:30:16  <sipa> and this cross-layer effect on consensus makes it IMHO nearly impossible
426 2016-07-11T19:30:24  <xinxi> gmaxwell: it's about 9000 lines of code.
427 2016-07-11T19:30:27  <sipa> but i am not an expert on the state of the art of formal code proofs
428 2016-07-11T19:30:54  <gmaxwell> xinxi: k, my figures are from memory thus approximate.
429 2016-07-11T19:31:30  <xinxi> gmaxwell: SEL4 has to guarantee high efficiency. So the code has to be written in C which is difficult to prove.
430 2016-07-11T19:32:04  <gmaxwell> xinxi: yes, and Bitcoin has to achieve high efficiency, efficiency is a security parameter for us.
431 2016-07-11T19:32:07  <xinxi> For Bitcoin, the programming language is not a big issue, and using languages like Coq, which enables a unified way for both coding and proofs could make it a lot easier.
432 2016-07-11T19:32:12  <gmaxwell> No. incorrect.
433 2016-07-11T19:32:32  <gmaxwell> If nodes are not fast enough the system will stop converging, at some point this results in a total consensus failure.
434 2016-07-11T19:32:41  <xinxi> I think OCaml is quite decent in terms of efficiency. Coq can generate OCaml code.
435 2016-07-11T19:32:58  <sipa> well we're not going to rewrite the consensus code in another language!
436 2016-07-11T19:33:00  <gmaxwell> Coq can generate C code via the compcert formalization (see VST).
437 2016-07-11T19:33:14  <xinxi> gmaxwell: here we go.
438 2016-07-11T19:33:15  <sipa> (or at least not without proving that the existing code matches the new code)
439 2016-07-11T19:33:44  <xinxi> how many lines of code are there for the consensus part?
440 2016-07-11T19:34:05  <xinxi> rewriting the consensus part is not infeasible after you separate it out.
441 2016-07-11T19:34:07  <sipa> do you include the cryptography library? the c++ standard library? the kernel?
442 2016-07-11T19:34:25  <gmaxwell> Far more than SEL4, the crypto part of it alone is that big.
443 2016-07-11T19:34:27  <sipa> changes in any of those can affect consensus
444 2016-07-11T19:34:44  <sipa> at some point you have to make an abstraction
445 2016-07-11T19:34:57  <kanzure> "formal proofs" cannot eliminate edge cases, they can only prove that the edge case exists
446 2016-07-11T19:34:59  <xinxi> sipa: we can leave cryptography part there first. C++ is just hopeless for verification. It's too complicated.
447 2016-07-11T19:35:11  <sipa> xinxi: then i think there is nothing we can do
448 2016-07-11T19:35:13  <kanzure> xinxi: how are you migrating the network precisely?
449 2016-07-11T19:35:18  <kanzure> wtf?
450 2016-07-11T19:35:28  <gmaxwell> chill chill.
451 2016-07-11T19:35:39  <sipa> these are intesting things to discuss
452 2016-07-11T19:35:44  <Chris_Stewart_5> xinxi: I think someone wrote a libsecp256k1 for ocaml if you are serious about implementing
453 2016-07-11T19:35:52  <Chris_Stewart_5> using ctypes
454 2016-07-11T19:36:04  <sipa> Chris_Stewart_5: what if the ocaml implementation doesn't match the C one?
455 2016-07-11T19:36:14  <sipa> we won't know without analysing the one that is actually used
456 2016-07-11T19:36:27  <sipa> (libsecp256k1, by the way, does have formal proofs for part of its operation)
457 2016-07-11T19:36:33  <xinxi> I mean we can separate out libconsensus first, and then use Coq to rewrite it and generate a provably correct version of libconsensus.
458 2016-07-11T19:36:48  <kanzure> xinxi: there are a lot of subtle side effects from the actual running network, but everyone in here still thinks it would be valuable to pursue formal verification anyway
459 2016-07-11T19:36:52  *** gmaxwell has left #bitcoin-core-dev
460 2016-07-11T19:37:13  <sipa> xinxi: how will you prove that the existing libconsensus (which only does script validation, not full block validation) matches that Coq specification?
461 2016-07-11T19:37:14  <kanzure> libconsensus imho should be a priority similar to segwit
462 2016-07-11T19:37:54  <sipa> kanzure: i agree. but we first need a plan for what 'libconsensus' means. people have been talking about it for ages, and have meant very different (and conflicting) things with it
463 2016-07-11T19:38:08  <xinxi> sipa: we don't prove the existing libconsensus. We derive the formal specification based on the existing libconsensus, and then write another libconsensus in Coq.
464 2016-07-11T19:38:11  <kanzure> sipa: maybe we can hijack the milan conference for these purposes (scaling bitcoin 3)
465 2016-07-11T19:38:14  <GitHub72> [bitcoin] JeremyRubin opened pull request #8330: WIP: Structure Packing Optimizations in CTransaction and CTxMemPoolEntry (master...structurepacking) https://github.com/bitcoin/bitcoin/pull/8330
466 2016-07-11T19:38:40  <Chris_Stewart_5> sipa: It just binds to the C library, so unless there is a bug in ctypes you should be ok
467 2016-07-11T19:38:42  <sipa> xinxi: does you derivation prove that the specification matches the current libconsensus?
468 2016-07-11T19:39:13  <sipa> sorry; does you derivation result in a specification that provably captures the current behaviour?
469 2016-07-11T19:39:32  <xinxi> sipa: no. do they have to match exactly?
470 2016-07-11T19:39:35  <sipa> Yes.
471 2016-07-11T19:39:38  <xinxi> we just take off there.
472 2016-07-11T19:39:48  <kanzure> can coq do outputs re: "behavior is definitely undefined here"?
473 2016-07-11T19:40:02  <sipa> xinxi: the specification for the network is the actually deployed code
474 2016-07-11T19:40:15  <sipa> any divergence from it can result in a network fork
475 2016-07-11T19:40:29  <xinxi> sipa: I think there can be slight difference?
476 2016-07-11T19:40:36  <sipa> xinxi: such as?
477 2016-07-11T19:40:44  <sipa> if you can't describe the current code exactly, we're done
478 2016-07-11T19:40:54  <kanzure> once you announce a difference, soeone will probably try to trigger those circumstances anyway :)
479 2016-07-11T19:41:15  <sipa> we won't rewrite the consensus layer in another language without certainty that it does not introduce any changes compared to the current code
480 2016-07-11T19:42:15  <xinxi> have you guys talked about this before?
481 2016-07-11T19:42:20  <sipa> yes
482 2016-07-11T19:42:20  <kanzure> endlessly
483 2016-07-11T19:42:34  <xinxi> many times?
484 2016-07-11T19:42:36  <sipa> xinxi: i don't think you're understanding what i'm saying
485 2016-07-11T19:42:48  <sipa> we do not prescribe the rules of the network
486 2016-07-11T19:42:50  <kanzure> xinxi: there is high interest in our community in formal verification and libconsensus and coq.
487 2016-07-11T19:43:08  <Chris_Stewart_5> ^^^
488 2016-07-11T19:43:08  <petertodd> sipa: along with the pragmatic requirement that the new language have a sufficiently large community of programmers to be maintainable - unusual languages don't need that criteria
489 2016-07-11T19:43:21  <sipa> petertodd: agree, but i wasn't going to bring that up
490 2016-07-11T19:43:49  <sipa> the first point is that our compatibility concerns are way beyond almost any other system
491 2016-07-11T19:44:19  <xinxi> @petertodd that may not be a problem. Later the code will be proof driven. And the core team writes the specification, and the committers need to prove the correctness of their code, which makes them impossible to make any mistakes.
492 2016-07-11T19:44:22  <kanzure> xinxi: this seems like something you would like to work on?
493 2016-07-11T19:44:37  <sipa> xinxi: i'm getting annoyed
494 2016-07-11T19:44:46  <sipa> xinxi: the core team does not write the specification
495 2016-07-11T19:45:15  <xinxi> @kanzure yes, it is. And two professors in my school, i.e. National University of Singapore, are willing to work in it as well. They are experts on software verification.
496 2016-07-11T19:45:23  <petertodd> ...and the specification will change over time as new features are soft-forked in, and specification flaws are fixed
497 2016-07-11T19:45:23  <sipa> xinxi: that's very interesting
498 2016-07-11T19:45:35  <xinxi> and we may have big funding support.
499 2016-07-11T19:45:56  <xinxi> the purpose is simple. we want to make bitcoin reliable.
500 2016-07-11T19:46:02  <sipa> xinxi: but i first want to understand why you say "< xinxi> sipa: I think there can be slight difference?"
501 2016-07-11T19:46:05  <Chris_Stewart_5> petertodd: Specifications can be changed overtime, and theoretically the proofs should reflect those changes
502 2016-07-11T19:46:13  <xinxi> the impact could be huge.
503 2016-07-11T19:46:25  <kanzure> xinxi: there are many bitcoin developers who want that as well. i think you could easily find collaborators from this conversation.
504 2016-07-11T19:46:48  <petertodd> xinxi: it's not going to be huge - the reliability of the consensus specification/implementation hasn't been a major problem for bitcoin - other problems are far higher-impact (scaling)
505 2016-07-11T19:47:06  <petertodd> xinxi: I'd suggest you focus your efforts on smart-contract use-cases, where specification flaws have been a huge problem (ethereum dao)
506 2016-07-11T19:47:13  <sipa> hey
507 2016-07-11T19:47:26  <kanzure> petertodd: nooo we do need some people thinking about libconsensus things
508 2016-07-11T19:47:38  <xinxi> petertodd: I think we are just lucky that Bitcoin has not yet experienced any catastrophic attacks?
509 2016-07-11T19:47:42  <Chris_Stewart_5> petertodd: I disagree, the consensus layer is the bedrock of bitcoin, if we screw that up in a major way we are done
510 2016-07-11T19:48:04  <kanzure> smart contract stuff is already getting formal verification attention, i woudn't worry about that, it was fairly high profile and papers have been published already
511 2016-07-11T19:48:08  <petertodd> kanzure: I'm not saying we don't, it's just that from the point of view of a researcher, they're going to get better return on their time by doing other things
512 2016-07-11T19:48:20  <kanzure> disagree
513 2016-07-11T19:48:41  <xinxi> petertodd: not all researchers work for papers.
514 2016-07-11T19:48:47  <petertodd> xinxi: it's not luck... it's how we make changes - turns out that intense review works
515 2016-07-11T19:48:51  <xinxi> impact is much more important.
516 2016-07-11T19:48:56  <Chris_Stewart_5> petertodd: Until it doesn't
517 2016-07-11T19:49:06  <Chris_Stewart_5> Bitcoin has already had issues with this in the past
518 2016-07-11T19:49:18  <xinxi> petertodd: OpenSSL has been used by so many people. Still it has serious bugs.
519 2016-07-11T19:49:18  *** jtimon has quit IRC
520 2016-07-11T19:49:21  <Chris_Stewart_5> Bip66 (or was it 62) comes to mind
521 2016-07-11T19:49:23  <sipa> how many consensus failures in bitcoin can you name? :)
522 2016-07-11T19:49:27  <sipa> yes, that's one
523 2016-07-11T19:49:43  <sipa> the march 2013 fork was another one
524 2016-07-11T19:49:59  <btcdrak> xinxi: you should probably also have a conversation with jtimon (who just pinged out). he's going a lot of the libconsensus stuff.
525 2016-07-11T19:50:02  <petertodd> Chris_Stewart_5: there's no reason to think yet that formal proofs actually do any better in practice, because the pool of talent that can work on them is much smaller
526 2016-07-11T19:50:15  <sipa> and bitcoin's scripting language before the removal of OP_VER was also a consensus problem
527 2016-07-11T19:50:20  <sipa> i don't know of any others tbh
528 2016-07-11T19:50:27  <petertodd> xinxi: indeed, which is why OpenSSL got replaced by libsecp256k1
529 2016-07-11T19:50:38  <sipa> OP_VER was in 2010
530 2016-07-11T19:50:46  <sipa> and all the others were due to supporting libraries
531 2016-07-11T19:50:58  <sipa> xinxi: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009697.html <- read that
532 2016-07-11T19:51:02  <xinxi> btcdrak: Yeah some one mentioned him to me.
533 2016-07-11T19:51:07  <sipa> (shameless plug)
534 2016-07-11T19:51:25  <sipa> xinxi: it gives you an idea of how complicated it was to find some of the actually known consensus failures in bitcoin
535 2016-07-11T19:51:43  <sipa> the fact that no easier ones have been found may give an indication
536 2016-07-11T19:52:29  <Chris_Stewart_5> petertodd: I think there actually has been some considerable interest in the formal verification community in bitcoin. I've talked to a handful of researchers myself and I don't think directing them away from the core protocol is a good idea
537 2016-07-11T19:52:31  <xinxi> I mean the provably correct version of libconsensus may not be consistent with the existing one. The most serious result would be a hard fork, rigth?
538 2016-07-11T19:52:44  *** TomMc has joined #bitcoin-core-dev
539 2016-07-11T19:52:46  <xinxi> But after that, we will take off. And Bitcoin will be much more secure than before.
540 2016-07-11T19:52:56  <sipa> xinxi: but we'll need a hard fork to get there?
541 2016-07-11T19:53:19  <xinxi> if the provably correct version is done, is it worth to have a hard fork?
542 2016-07-11T19:53:31  <sipa> maybe
543 2016-07-11T19:53:37  <petertodd> Chris_Stewart_5: I'm not saying there isn't interest, I'm saying that if you want to make a high impact with formal verification deployed in production, Bitcoin isn't interesting because the risks of deploying formal verification in production are higher than the theoretical benefits
544 2016-07-11T19:53:56  <sipa> xinxi: but there are requirements beyond just correctness
545 2016-07-11T19:54:06  <petertodd> Chris_Stewart_5: whereas with smart-contract systems, the risks of the existing approaches are known to be very high - likely too high to be practical - so the risks of alternate approaches are less in comparison
546 2016-07-11T19:54:32  <sipa> xinxi: such as performance, and ease of maintenance
547 2016-07-11T19:54:35  <btcdrak> xinxi: there are other things than correctness which can cause consensus failure.
548 2016-07-11T19:54:54  <xinxi> petertodd: sorry, peter, I think current smart contract platforms are trying to solve some hypothetical problems. But this is a bit irrelevant.
549 2016-07-11T19:55:20  <petertodd> xinxi: speaking of performance, will your formal verification techniques be able to guarantee bounds on execution time/space?
550 2016-07-11T19:55:27  <kanzure> is jl2012 in singapore?
551 2016-07-11T19:55:33  <btcdrak> hk
552 2016-07-11T19:55:37  <kanzure> damn
553 2016-07-11T19:55:37  <sipa> jl2012 is in hong kong
554 2016-07-11T19:55:43  <sipa> what petertodd said
555 2016-07-11T19:56:00  <petertodd> xinxi: *ethereum* is trying to solve a hypothetical problem; systems like R3's Corda are solving very real problems. Yes, they may be problems in centralized systems, but that doesn't make those problems any less real.
556 2016-07-11T19:56:42  <sipa> i think proving time and space bounds (ideally on the current code!) is probably more useful in practice than a formal specification (which i expect to be much more complicated than you expect, if it is to have production value)
557 2016-07-11T19:56:55  <xinxi> petertodd: I think most smart contracts should run on AWS. That's much more efficient and easy to use.
558 2016-07-11T19:57:24  <xinxi> sipa: why do we need to prove time and space bounds?
559 2016-07-11T19:57:36  <petertodd> xinxi: smart contracts are about verification, not computation; "should run on AWS" makes no sense
560 2016-07-11T19:58:08  <sipa> xinxi: because if an attack exists that can make validation slow on some nodes, you can take advantage of that (a miner could knock out competition, or get a propagation advantage)
561 2016-07-11T19:58:14  <petertodd> xinxi: if you exceed the time/space bounds allowed by the actual implementation, the system fails to reach consensus
562 2016-07-11T19:58:25  <sipa> xinxi: if an attack exists that can make memory grow unbounded, you can knock out validation
563 2016-07-11T19:58:53  <petertodd> xinxi: in fact, it's fair to say that much of the current development effort is ultimately about making the upper-bound time cost of a block lower
564 2016-07-11T19:58:57  <sipa> xinxi: for bitcoin's security assumptions to hold, verification of blocks must be negligable in time compared to the block production rate
565 2016-07-11T19:59:40  <xinxi> sipa: that sounds like the scalability issues that you guys are trying to solve.
566 2016-07-11T20:00:48  <sipa> well, it's much more a problem today than fear of consensus failure
567 2016-07-11T20:01:28  <xinxi> petertodd: a simpler way to do smart contracts is to have trustworthy organization to run a platform on AWS and then people can run their smart contracts on the platform. It's scalable, efficient, and can also be verified.
568 2016-07-11T20:02:09  <petertodd> xinxi: the whole point of smart contracts in banking is to get away from that model
569 2016-07-11T20:02:22  <btcdrak> xinxi: but we are interested in decentralised systems; there's special about yet another centralised system.
570 2016-07-11T20:02:42  <sipa> petertodd, xinxi: i think centralized smart contract design is a bit off topic here
571 2016-07-11T20:02:43  <petertodd> xinxi: verifying computaitons are done correctly is not easy
572 2016-07-11T20:02:47  <xinxi> petertodd: yeah, we can use Bitcoin in that AWS based smart contract platform. It does not have to be decentralized.
573 2016-07-11T20:03:50  <petertodd> sipa: point is, I think xinxi would be much better off solving problems in that problem space first, as they're easier to solve with more impact, and that'll give them tools to tackle bitcoin later; misunderstandings about that problem space are indicative of serious misunderstandings with how bitcoin works
574 2016-07-11T20:04:10  <petertodd> xinxi: again, do you understand my point about verification vs. computation?
575 2016-07-11T20:06:22  <xinxi> petertodd: you are right. A third party's platform cannot be fully trusted and thus full verification is impossible. But most people's smart contracts don't need that kind of strong verification.
576 2016-07-11T20:06:46  *** gmaxwell has joined #bitcoin-core-dev
577 2016-07-11T20:08:08  <xinxi> To me, Bitcoin is great because it is solving a real problem.
578 2016-07-11T20:08:09  *** Giszmo has quit IRC
579 2016-07-11T20:08:35  <Chris_Stewart_5> xinxi: Having a formally verified library of smart contracts would be useful. As in any programming language you end up having design patterns, you will see the emergence of patterns in smart contracts imo
580 2016-07-11T20:09:03  <xinxi> Chris_Stewart_5: it is truly useful in some extreme cases.
581 2016-07-11T20:09:38  <petertodd> xinxi: I suspect you're unclear as to what smart contracts even do... the sane use-cases I'm talking about, are to formalize legal contracts, allowing adherence to them to be verified - that only works because you can take the state you're in - legally speaking - and verify that it matches the smart contracts (aka protocol definitions)
582 2016-07-11T20:09:59  <xinxi> And the biggest concern of Bitcoin to me is not the lack of functions but its security. Many people still think it is too young and not reliable enough and could fail completely and thus don't want to adopt it.
583 2016-07-11T20:10:10  <petertodd> xinxi: bitcoin is exactly the same, except that on top of that, PoW allows our state to converge to a single consensus history
584 2016-07-11T20:10:33  <petertodd> xinxi: the most likely way bitcoin will fail right now is a failure of decentralization, which is very closely tied to scalability
585 2016-07-11T20:11:00  <sipa> petertodd: agree, but i still think smart contracts is off topic here.
586 2016-07-11T20:11:07  <sipa> of the type you're describing
587 2016-07-11T20:11:49  *** Giszmo has joined #bitcoin-core-dev
588 2016-07-11T20:11:50  <petertodd> sipa: again, I'm trying to explain to xinxi how this stuff works - not make smart contracts the topic...
589 2016-07-11T20:12:02  <sipa> ok, great
590 2016-07-11T20:12:53  <sipa> xinxi: i think it's unlikely that people will accept a hard fork to switch to a more formally provable consensus implementation
591 2016-07-11T20:13:01  <xinxi> petertodd: to me, smart contracts are just contracts in code.
592 2016-07-11T20:13:13  <sipa> i think you're talking about different things
593 2016-07-11T20:13:51  <petertodd> xinxi: that's not any different from what I said... legal contracts are verification, not computation - they're about conditions that need to be met for something to be valid - aka a protocol specification
594 2016-07-11T20:14:38  <petertodd> xinxi: equally, the definition of the bitcoin protocol is what the bitcoin implementation accepts as valid - the fact the code that does that is somewhat intermixed with code that records state is just a historical mistake
595 2016-07-11T20:14:42  <xinxi> yeah, a coded contracts can be run on AWS and still legally binding.
596 2016-07-11T20:15:08  <xinxi> you just write the legal part in terms of conditions.
597 2016-07-11T20:15:09  <sipa> xinxi: but if it has very clear benefits (like performance/resource bounds), is easy to work with... maybe, but that's not something for us to decide
598 2016-07-11T20:15:11  <btcdrak> xinxi: in this space smart contracts are self enforcing contract
599 2016-07-11T20:15:36  <sipa> xinxi: i don't think people should ever expect a future hard forking change to succeed
600 2016-07-11T20:15:38  <petertodd> xinxi: why do you keep saying AWS here? that's completely missing the point: what you want is to be able to show to someone else (e.g a judge, but hopefully it doesn't go that far) that the smart contract hasn't been upheld
601 2016-07-11T20:16:18  <sipa> xinxi: so imho for formal verification to be practical in the short term, it has to be about the currently deployed code
602 2016-07-11T20:16:19  <petertodd> btcdrak: self-enforcing because of the underlying proof-of-work layers ensuring consensus, and the fact that people widely choose to accept the outputs of the system - bitcoin being a perfect - albeit inflexible - example
603 2016-07-11T20:16:40  *** Giszmo has quit IRC
604 2016-07-11T20:16:40  <xinxi> My point is current smart contract platforms are mostly solving hypothetical problems.
605 2016-07-11T20:16:46  <petertodd> sipa: yeah, pragmatically speaking, replacing the entire codebase in a hardfork is going to be incredibly controversial at best
606 2016-07-11T20:16:51  <sipa> petertodd: indeed
607 2016-07-11T20:17:30  <sipa> petertodd, xinxi: again, please take that discussion elsewhere. yes, there is some overlap that is relevant here. but discussion about what problems smart contracts are solving is not
608 2016-07-11T20:17:37  *** ChanServ sets mode: +o sipa
609 2016-07-11T20:17:54  <petertodd> sipa: ack
610 2016-07-11T20:17:55  <xinxi> sipa: yeah. My focus is still formal verification.
611 2016-07-11T20:18:00  *** sipa sets mode: -o sipa
612 2016-07-11T20:18:01  <sipa> thanks
613 2016-07-11T20:18:30  <sipa> xinxi: have you read my BIP66 writeup above?
614 2016-07-11T20:18:56  <xinxi> So you are Pieter?
615 2016-07-11T20:18:58  <sipa> yes
616 2016-07-11T20:19:02  <xinxi> cool
617 2016-07-11T20:19:03  <sipa> i think it is useful to illustrate the difficulty of consensus problems
618 2016-07-11T20:19:09  <sipa> of finding
619 2016-07-11T20:19:39  <kanzure> btcdrak: bitcoincore.org/en/team/ is lacking usernames
620 2016-07-11T20:20:44  <btcdrak> kanzure: really could do with a bio page. people's user handles are not always consistent across platforms
621 2016-07-11T20:20:59  *** go1111111 has joined #bitcoin-core-dev
622 2016-07-11T20:21:13  <xinxi> sipa: please let met read it first.
623 2016-07-11T20:21:47  <petertodd> xinxi: we'll, lets continue the discussion in another hour or two after you read it :)
624 2016-07-11T20:21:52  <petertodd> bbl!
625 2016-07-11T20:21:54  *** spudowiar has joined #bitcoin-core-dev
626 2016-07-11T20:23:11  <sipa> xinxi: (i'll only mention this once): bitcoin core's cryptography library (libsecp256k1) does have some modest attempts at formally verifying pieces of the code, and help there would also be very welcome. It's much less ambitious than proving properties about bitcoin's consensus code, but also much easier to accomplish something in my opinion
627 2016-07-11T20:23:41  <kanzure> sipa: don't you guys have that libsecp256k1 paper at some point? :D
628 2016-07-11T20:23:53  <sipa> kanzure: at some point.
629 2016-07-11T20:24:52  <btcdrak> xinxi: see https://github.com/bitcoin-core/secp256k1
630 2016-07-11T20:25:13  <xinxi> btcdrak: thanks.
631 2016-07-11T20:25:31  <xinxi> sipa: that's understandable. It takes huge amount of money to get started.
632 2016-07-11T20:26:30  *** Chris_Stewart_5 has quit IRC
633 2016-07-11T20:27:24  <sipa> also, #secp256k1 for that
634 2016-07-11T20:29:29  *** Giszmo has joined #bitcoin-core-dev
635 2016-07-11T20:29:39  *** Chris_Stewart_5 has joined #bitcoin-core-dev
636 2016-07-11T20:31:59  <Chris_Stewart_5> sipa: I just read the email, however the hard fork last July wasn't related to the implementation of BIP66 , it was just spv mining correct?
637 2016-07-11T20:32:13  <sipa> that was not a hard fork
638 2016-07-11T20:32:18  <sipa> just miners creating invalid blocks
639 2016-07-11T20:32:40  <sipa> and it triggered when bip65 activated
640 2016-07-11T20:32:47  <sipa> not bip66, which was a year earlier
641 2016-07-11T20:35:32  <Chris_Stewart_5> Seems that OP_CLTV was activated ~7 months ago?
642 2016-07-11T20:35:53  <Chris_Stewart_5> I distinctly remember the issue being July 4th of last year
643 2016-07-11T20:35:54  <btcdrak> yes, he means BIP66
644 2016-07-11T20:35:58  <Chris_Stewart_5> oh ok
645 2016-07-11T20:36:06  <sipa> oh, i'm misremembering
646 2016-07-11T20:36:19  <btcdrak> CLTV went without a hitch.
647 2016-07-11T20:36:25  <sipa> apologies
648 2016-07-11T20:36:30  <Chris_Stewart_5> np
649 2016-07-11T20:36:55  <btcdrak> I dont know, I think we must give a punishment.
650 2016-07-11T20:38:06  <Chris_Stewart_5> Seven more years of reading openssl!
651 2016-07-11T20:38:20  <btcdrak> too harsh. maybe no computer! and go to bed early!
652 2016-07-11T20:46:19  <sipa> hah
653 2016-07-11T20:46:43  <xinxi> sipa: so you wrote most of secp256k1?
654 2016-07-11T20:46:55  *** BCBot has quit IRC
655 2016-07-11T20:47:12  *** BCBot has joined #bitcoin-core-dev
656 2016-07-11T20:48:13  <xinxi> The email seems fantastic.
657 2016-07-11T20:48:39  <xinxi> It's truly a tough journey.
658 2016-07-11T20:49:25  <sipa> xinxi: i started it; most of the fancier optimizations and verifications/tests were proposed or implemented by others
659 2016-07-11T20:50:20  *** Giszmo has quit IRC
660 2016-07-11T20:53:22  *** Chris_Stewart_5 has quit IRC
661 2016-07-11T20:56:45  *** Giszmo has joined #bitcoin-core-dev
662 2016-07-11T20:57:13  <xinxi> sipa: that's interesting. I saw it's written in C intead of C++. I thought you deliberately did that for verification?
663 2016-07-11T20:58:25  <sipa> xinxi: it started as C++, actually, but gmaxwell suggested converting it to C to aide with formal verification
664 2016-07-11T20:58:36  <sipa> as there are more analysis tools available for C than C++
665 2016-07-11T20:58:45  <sipa> this was very early on
666 2016-07-11T20:58:56  <xinxi> sipa: fantastic! I am so glad to see it's formally verified!
667 2016-07-11T20:59:10  <sipa> i wouldn't say it's formally verified
668 2016-07-11T20:59:21  <sipa> just some pieces
669 2016-07-11T20:59:29  <xinxi> C++ is just too complicated to verify.
670 2016-07-11T20:59:32  <sipa> i can discuss more on #secp256k1
671 2016-07-11T20:59:43  <xinxi> Is it a channel?
672 2016-07-11T20:59:45  <sipa> yes
673 2016-07-11T20:59:54  <xinxi> sipa: let's talk there.
674 2016-07-11T21:04:42  *** Giszmo has quit IRC
675 2016-07-11T21:06:01  *** Giszmo has joined #bitcoin-core-dev
676 2016-07-11T21:08:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
677 2016-07-11T21:14:17  *** laurentmt has joined #bitcoin-core-dev
678 2016-07-11T21:14:38  *** laurentmt has quit IRC
679 2016-07-11T21:23:07  *** justanotheruser has quit IRC
680 2016-07-11T21:23:51  *** justanotheruser has joined #bitcoin-core-dev
681 2016-07-11T21:24:15  *** justanotheruser has quit IRC
682 2016-07-11T21:24:40  *** justanotheruser has joined #bitcoin-core-dev
683 2016-07-11T21:32:42  *** frankenmint has joined #bitcoin-core-dev
684 2016-07-11T21:34:16  *** xinxi has quit IRC
685 2016-07-11T21:38:04  *** arubi has quit IRC
686 2016-07-11T21:42:20  *** arubi has joined #bitcoin-core-dev
687 2016-07-11T21:43:42  *** xinxi has joined #bitcoin-core-dev
688 2016-07-11T21:43:59  *** jannes has quit IRC
689 2016-07-11T21:44:34  *** moli has quit IRC
690 2016-07-11T21:47:58  *** xinxi has quit IRC
691 2016-07-11T21:51:07  *** spudowiar has quit IRC
692 2016-07-11T21:52:01  *** spudowiar has joined #bitcoin-core-dev
693 2016-07-11T22:13:33  *** frankenmint has quit IRC
694 2016-07-11T22:14:09  *** Guyver2 has quit IRC
695 2016-07-11T22:15:20  *** proslogion has joined #bitcoin-core-dev
696 2016-07-11T22:15:23  *** frankenmint has joined #bitcoin-core-dev
697 2016-07-11T22:15:35  *** proslogion has left #bitcoin-core-dev
698 2016-07-11T22:17:31  *** TomMc has quit IRC
699 2016-07-11T22:28:32  *** belcher has joined #bitcoin-core-dev
700 2016-07-11T22:30:32  *** TomMc has joined #bitcoin-core-dev
701 2016-07-11T22:35:15  <GitHub44> [bitcoin] dooglus opened pull request #8331: Fix three 'comparison between signed and unsigned integer expressions' warnings. (master...fix-compilation-warnings) https://github.com/bitcoin/bitcoin/pull/8331
702 2016-07-11T22:50:22  *** moli has joined #bitcoin-core-dev
703 2016-07-11T23:06:15  *** Giszmo has quit IRC
704 2016-07-11T23:10:00  *** Giszmo has joined #bitcoin-core-dev
705 2016-07-11T23:16:55  *** Giszmo has quit IRC
706 2016-07-11T23:25:26  *** spudowiar has quit IRC
707 2016-07-11T23:40:01  *** mkarrer has quit IRC
708 2016-07-11T23:42:50  *** Giszmo has joined #bitcoin-core-dev
709 2016-07-11T23:49:18  *** Giszmo has quit IRC