1 2016-08-18T00:00:56  *** murch has quit IRC
  2 2016-08-18T00:01:32  *** FNinTak has quit IRC
  3 2016-08-18T00:12:12  *** fengling has joined #bitcoin-core-dev
  4 2016-08-18T00:17:06  *** fengling has quit IRC
  5 2016-08-18T00:23:13  *** fengling has joined #bitcoin-core-dev
  6 2016-08-18T00:23:26  *** spudowiar has quit IRC
  7 2016-08-18T00:28:32  <phantomcircuit> cfields: alrighty then
  8 2016-08-18T00:28:54  <phantomcircuit> gmaxwell: things have been a bit lax on that front recently actually
  9 2016-08-18T00:29:10  <phantomcircuit> personally i strongly prefer that each commit in a pr is itself functional
 10 2016-08-18T00:29:26  <phantomcircuit> we've had a few where that's a commit at the end which fixes a bug in the first commit
 11 2016-08-18T00:30:54  <jcorgan> it is nice to have all commits compile nicely to be able to use git bisect
 12 2016-08-18T00:31:11  <instagibbs> I kind of like to see changes as they are worked on personally, with cleanup at the end. Often force pushes means I can't really track what has changed super easily. But I'm sure that's my lack of foo
 13 2016-08-18T00:31:26  <cfields> phantomcircuit: looking at the rpc tests, i'm not seeing how the caches don't stomp eachother
 14 2016-08-18T00:34:09  <phantomcircuit> instagibbs: the idea is that you do the normal thing with cleanup and then before merge rebase such that the overall change is identical
 15 2016-08-18T00:34:59  *** Samdney has quit IRC
 16 2016-08-18T00:40:54  *** Megaf has quit IRC
 17 2016-08-18T00:41:12  *** cryptapus has joined #bitcoin-core-dev
 18 2016-08-18T00:41:12  *** cryptapus has joined #bitcoin-core-dev
 19 2016-08-18T00:44:10  <sipa> phantomcircuit: every commit must compile and run tests
 20 2016-08-18T00:44:33  <sipa> phantomcircuit: that's not something a manually verify when reviewing, but i won't ack a PR if i know it isn't the case
 21 2016-08-18T00:47:06  *** cryptapus has quit IRC
 22 2016-08-18T00:48:48  *** Chris_Stewart_5 has quit IRC
 23 2016-08-18T00:52:28  <phantomcircuit> sipa: sure... but there's things where they compile and pass tests and we know them to be broken
 24 2016-08-18T00:54:58  <sipa> ah, that shouldn't be
 25 2016-08-18T00:59:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 26 2016-08-18T01:05:29  *** jrayhawk has joined #bitcoin-core-dev
 27 2016-08-18T01:10:23  *** Chris_Stewart_5 has quit IRC
 28 2016-08-18T01:14:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 29 2016-08-18T01:27:07  *** Alopex has quit IRC
 30 2016-08-18T01:28:12  *** Alopex has joined #bitcoin-core-dev
 31 2016-08-18T01:35:52  *** Ylbam has quit IRC
 32 2016-08-18T01:50:26  *** PaulCapestany has quit IRC
 33 2016-08-18T01:51:04  *** Chris_Stewart_5 has quit IRC
 34 2016-08-18T01:52:07  *** PaulCapestany has joined #bitcoin-core-dev
 35 2016-08-18T02:09:26  *** justanotheruser has quit IRC
 36 2016-08-18T02:11:04  *** justanotheruser has joined #bitcoin-core-dev
 37 2016-08-18T02:15:12  *** dstadulis has joined #bitcoin-core-dev
 38 2016-08-18T02:26:43  *** pero has joined #bitcoin-core-dev
 39 2016-08-18T02:28:23  *** pero has quit IRC
 40 2016-08-18T02:32:51  *** jcorgan has quit IRC
 41 2016-08-18T02:32:51  *** jcorgan has joined #bitcoin-core-dev
 42 2016-08-18T03:30:11  *** Alopex has quit IRC
 43 2016-08-18T03:31:16  *** Alopex has joined #bitcoin-core-dev
 44 2016-08-18T04:11:50  *** btcdrak has joined #bitcoin-core-dev
 45 2016-08-18T04:12:02  *** Alopex has quit IRC
 46 2016-08-18T04:13:07  *** Alopex has joined #bitcoin-core-dev
 47 2016-08-18T04:23:26  *** Alopex has quit IRC
 48 2016-08-18T04:24:31  *** Alopex has joined #bitcoin-core-dev
 49 2016-08-18T04:38:21  *** Alopex has quit IRC
 50 2016-08-18T04:39:26  *** Alopex has joined #bitcoin-core-dev
 51 2016-08-18T04:42:42  *** kadoban has quit IRC
 52 2016-08-18T04:59:06  *** Alopex has quit IRC
 53 2016-08-18T05:00:12  *** Alopex has joined #bitcoin-core-dev
 54 2016-08-18T05:10:12  *** Alopex has quit IRC
 55 2016-08-18T05:11:17  *** Alopex has joined #bitcoin-core-dev
 56 2016-08-18T05:23:17  *** Alopex has quit IRC
 57 2016-08-18T05:24:22  *** Alopex has joined #bitcoin-core-dev
 58 2016-08-18T05:29:27  *** dstadulis has quit IRC
 59 2016-08-18T05:34:02  *** Alopex has quit IRC
 60 2016-08-18T05:35:07  *** Alopex has joined #bitcoin-core-dev
 61 2016-08-18T06:38:59  <wumpus> travis is extremely broken
 62 2016-08-18T06:44:02  <GitHub150> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/733035bdb755...a78f95a976de
 63 2016-08-18T06:44:03  <GitHub150> bitcoin/master fa64306 MarcoFalke: [qa] abandonconflict: Use assert_equal
 64 2016-08-18T06:44:03  <GitHub150> bitcoin/master a78f95a Wladimir J. van der Laan: Merge #8531: [qa] abandonconflict: Use assert_equal...
 65 2016-08-18T06:44:12  <GitHub90> [bitcoin] laanwj closed pull request #8531: [qa] abandonconflict: Use assert_equal (master...Mf1608-qaAssert) https://github.com/bitcoin/bitcoin/pull/8531
 66 2016-08-18T06:55:01  *** Alopex has quit IRC
 67 2016-08-18T06:56:06  *** Alopex has joined #bitcoin-core-dev
 68 2016-08-18T06:57:10  *** BashCo has quit IRC
 69 2016-08-18T06:59:21  <jonasschnelli> For the binary verification problem, we should have a verification process in Bitcoin-Qt/bitcoin-cli (or maybe an additional tool) that can verify a downloaded binary by downloading the gitian.sigs
 70 2016-08-18T06:59:46  <jonasschnelli> It would require to also produce ECDSA sigs per assets file
 71 2016-08-18T07:00:08  <jonasschnelli> And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git
 72 2016-08-18T07:00:24  <wumpus> the idea with adding ecdsa signatures in addition to gpg signatures, which can be easier to verify by an external program that doesn't want to embed the entire gpg shebang
 73 2016-08-18T07:00:34  <wumpus> yes
 74 2016-08-18T07:01:02  <wumpus> a user friendly gitian verifyer could be useful
 75 2016-08-18T07:01:32  <jonasschnelli> Built into an already verified binary would be nice
 76 2016-08-18T07:02:03  <wumpus> well it doesn't so much need to be part of the binary, could be a separate tool part of the distribution
 77 2016-08-18T07:02:08  <jonasschnelli> Once you have verified with the gitian-verifier, you have a trusted chain of updates
 78 2016-08-18T07:02:21  <jonasschnelli> Yes. Could be seperated...
 79 2016-08-18T07:02:23  <jcorgan> it would also be useful to have the current release signature depend on the previous one, to form a hash chain of sorts
 80 2016-08-18T07:02:37  <jonasschnelli> but should be built from the git repo where the ECDSA pubkeys are and also built over gitian
 81 2016-08-18T07:03:04  <wumpus> jonasschnelli: agreed
 82 2016-08-18T07:03:33  <wumpus> jcorgan: does that improve security? attackers can just as easily include a link to the previous signature
 83 2016-08-18T07:04:16  <GitHub31> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a78f95a976de...671fdae5f5b3
 84 2016-08-18T07:04:17  <GitHub31> bitcoin/master fa0afde MarcoFalke: [travis] Drop java
 85 2016-08-18T07:04:17  <GitHub31> bitcoin/master 671fdae Wladimir J. van der Laan: Merge #8534: [travis] Drop java...
 86 2016-08-18T07:04:29  <GitHub13> [bitcoin] laanwj closed pull request #8534: [travis] Drop java (master...Mf1608-qaJava) https://github.com/bitcoin/bitcoin/pull/8534
 87 2016-08-18T07:05:45  <jcorgan> sure. it would just demonstrate an unbroken chain of release binaries, for those willing to verify current vs. prior.
 88 2016-08-18T07:06:04  <jcorgan> admittedly, that seems like a very few people nowadays.
 89 2016-08-18T07:06:58  <wumpus> right, although otoh people may be better off looking for the prior release themselves, then blindly trusting the (potentially faked) link
 90 2016-08-18T07:11:36  <jcorgan> hard to ensure other's choices, only possible to give them the information needed to make good ones
 91 2016-08-18T07:13:02  <wumpus> the segwit.py test is very broken in travis
 92 2016-08-18T07:13:39  <wumpus> somehow not locally though
 93 2016-08-18T07:15:26  <btcdrak> wumpus: travis randomly fails tests atm
 94 2016-08-18T07:15:47  <wumpus> random tests?
 95 2016-08-18T07:16:13  <btcdrak> look at jl2012 PR yesterday https://travis-ci.org/bitcoin/bitcoin/builds/153047455
 96 2016-08-18T07:16:41  <wumpus> that's also segwit.py failing
 97 2016-08-18T07:16:45  <btcdrak> the same build fails different tests
 98 2016-08-18T07:16:56  <wumpus> and txn_doublespend
 99 2016-08-18T07:17:08  <wumpus> looks like I reported the issue correct then here https://github.com/bitcoin/bitcoin/issues/8532
100 2016-08-18T07:17:32  <jl2012> I suspect that's related to the low s patch by sipa
101 2016-08-18T07:17:38  <wumpus> "Looks like with the reduced delay from fa2d68f, the nodes sync up before the txns all make it into the wallet"
102 2016-08-18T07:17:44  <wumpus> according to cfields
103 2016-08-18T07:17:55  <sipa> that failing segwit test was introduced in #8489 iirc
104 2016-08-18T07:18:04  *** BashCo has joined #bitcoin-core-dev
105 2016-08-18T07:18:25  <btcdrak> i think Cory nailed it
106 2016-08-18T07:18:36  <jl2012> Without his patch, bip164-p2p.py will fail
107 2016-08-18T07:19:20  <sipa> btcdrak, wumpus: but if shorter delays trigger errors, the tests are wrong
108 2016-08-18T07:19:30  <sipa> they shouldn't rely on timings
109 2016-08-18T07:19:43  *** MarcoFalke has joined #bitcoin-core-dev
110 2016-08-18T07:20:27  <wumpus> that's a good point, but we need to do something to make the travis failures go away, that could be fixing the tests, but reverting the timeout change may be quicker
111 2016-08-18T07:20:59  <wumpus> if fixing the tests is straightforward (it's always those two) then I'm all for fixing them immediately, of course
112 2016-08-18T07:21:34  <wumpus> the alternative would be temporarily disabling them in travis
113 2016-08-18T07:21:54  <jl2012> By the way, they never fail on my mac
114 2016-08-18T07:21:54  <wumpus> but I prefer reverting the timeout change to that, as at least something gets tested then
115 2016-08-18T07:22:01  <wumpus> jl2012: I can't reproduce it locally either
116 2016-08-18T07:22:45  <MarcoFalke> wumpus: Agree on temp. revert. I will try to look into this now but there is no eta for tha acutal fix
117 2016-08-18T07:22:49  *** Lysanders has joined #bitcoin-core-dev
118 2016-08-18T07:23:55  <GitHub68> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/35f64e45c207960078eef58ccc50d91e4abc2c55
119 2016-08-18T07:23:55  <GitHub68> bitcoin/master 35f64e4 Wladimir J. van der Laan: Revert "[qa] Adjust timeouts for micro-optimization of run time"...
120 2016-08-18T07:29:37  <MarcoFalke> Thanks
121 2016-08-18T07:33:04  <GitHub32> [bitcoin] MarcoFalke opened pull request #8536: [WIP] [qa] Adjust timeouts for micro-optimization of run time (master...Mf1608-qaOptSync) https://github.com/bitcoin/bitcoin/pull/8536
122 2016-08-18T07:45:01  *** arowser has quit IRC
123 2016-08-18T08:08:27  *** Ylbam has joined #bitcoin-core-dev
124 2016-08-18T08:16:47  *** Giszmo has joined #bitcoin-core-dev
125 2016-08-18T08:31:18  *** Guyver2 has joined #bitcoin-core-dev
126 2016-08-18T09:25:58  *** Guyver2_ has joined #bitcoin-core-dev
127 2016-08-18T09:28:56  *** Guyver2 has quit IRC
128 2016-08-18T09:29:01  *** Guyver2_ is now known as Guyver2
129 2016-08-18T09:30:18  *** JZA has quit IRC
130 2016-08-18T09:47:10  *** rubensayshi has joined #bitcoin-core-dev
131 2016-08-18T10:20:28  *** laurentmt has joined #bitcoin-core-dev
132 2016-08-18T10:21:17  *** laurentmt has quit IRC
133 2016-08-18T10:26:32  *** moli has quit IRC
134 2016-08-18T10:41:41  *** harrymm has quit IRC
135 2016-08-18T10:50:37  *** MarcoFalke has left #bitcoin-core-dev
136 2016-08-18T10:57:52  *** harrymm has joined #bitcoin-core-dev
137 2016-08-18T11:13:21  *** harrymm has quit IRC
138 2016-08-18T11:24:29  <GitHub88> [bitcoin] mcccs opened pull request #8537: Trivial: little typos (master...litttle-typos) https://github.com/bitcoin/bitcoin/pull/8537
139 2016-08-18T11:29:27  *** harrymm has joined #bitcoin-core-dev
140 2016-08-18T11:42:32  *** harrymm has quit IRC
141 2016-08-18T11:54:05  <GitHub188> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/35f64e45c207...8250de13587e
142 2016-08-18T11:54:06  <GitHub188> bitcoin/master b213535 Wladimir J. van der Laan: Squashed 'src/secp256k1/' changes from 6c527ec..7a49cac...
143 2016-08-18T11:54:06  <GitHub188> bitcoin/master 0237096 Wladimir J. van der Laan: Merge commit 'b2135359b3ad37cf2ac09b008079ddb237eff2c9'
144 2016-08-18T11:54:07  <GitHub188> bitcoin/master 8250de1 Pieter Wuille: Merge #8453: Bring secp256k1 subtree up to date with master...
145 2016-08-18T11:54:15  <GitHub62> [bitcoin] sipa closed pull request #8453: Bring secp256k1 subtree up to date with master (master...2016_08_update_secp256k1) https://github.com/bitcoin/bitcoin/pull/8453
146 2016-08-18T12:01:53  *** harrymm has joined #bitcoin-core-dev
147 2016-08-18T12:06:34  *** AaronvanW has quit IRC
148 2016-08-18T12:25:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
149 2016-08-18T12:25:52  *** Ylbam has quit IRC
150 2016-08-18T12:33:27  *** YOU-JI has joined #bitcoin-core-dev
151 2016-08-18T12:36:32  *** Chris_Stewart_5 has quit IRC
152 2016-08-18T12:46:26  *** fengling has quit IRC
153 2016-08-18T12:47:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
154 2016-08-18T12:58:38  *** YOU-JI_ has joined #bitcoin-core-dev
155 2016-08-18T12:58:44  *** kadoban has joined #bitcoin-core-dev
156 2016-08-18T12:59:52  *** YOU-JI has quit IRC
157 2016-08-18T13:03:29  *** YOU-JI_ has quit IRC
158 2016-08-18T13:04:54  <GitHub101> [bitcoin] mcccs opened pull request #8538: Remove IP transaction check (master...Ip-check) https://github.com/bitcoin/bitcoin/pull/8538
159 2016-08-18T13:06:28  *** AaronvanW has joined #bitcoin-core-dev
160 2016-08-18T13:10:50  *** JZA has joined #bitcoin-core-dev
161 2016-08-18T13:14:27  *** Ylbam has joined #bitcoin-core-dev
162 2016-08-18T13:22:13  *** moli has joined #bitcoin-core-dev
163 2016-08-18T13:43:29  *** fengling has joined #bitcoin-core-dev
164 2016-08-18T13:47:46  *** fengling has quit IRC
165 2016-08-18T14:07:39  *** arubi has quit IRC
166 2016-08-18T14:09:29  *** arubi has joined #bitcoin-core-dev
167 2016-08-18T14:23:09  *** laurentmt has joined #bitcoin-core-dev
168 2016-08-18T14:24:01  *** Chris_Stewart_5 has quit IRC
169 2016-08-18T14:25:31  *** TomMc has joined #bitcoin-core-dev
170 2016-08-18T14:25:39  *** laurentmt has quit IRC
171 2016-08-18T14:31:31  <GitHub121> [bitcoin] mcccs closed pull request #8537: Trivial: little typos (master...litttle-typos) https://github.com/bitcoin/bitcoin/pull/8537
172 2016-08-18T14:32:07  *** cryptapus has joined #bitcoin-core-dev
173 2016-08-18T14:32:19  *** rubensayshi has quit IRC
174 2016-08-18T14:42:45  <jl2012> sipa: the rpc-test for https://github.com/bitcoin/bitcoin/pull/8533 seems ok now. I replaced you low_s signature hack with actually transforming the S value
175 2016-08-18T14:43:16  <jl2012> probably because your patch takes longer to sign and it timeouts?
176 2016-08-18T14:44:14  *** fengling has joined #bitcoin-core-dev
177 2016-08-18T14:49:06  *** fengling has quit IRC
178 2016-08-18T14:50:31  <jl2012> i think your patch double the signing time on average; and could take much longer with bad luck
179 2016-08-18T14:54:39  <GitHub165> [bitcoin] crowning- opened pull request #8539: CDB: fix debug output (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8539
180 2016-08-18T15:02:30  <GitHub103> [bitcoin] laanwj opened pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (master...2016_08_qt_choosedatadir_crash) https://github.com/bitcoin/bitcoin/pull/8540
181 2016-08-18T15:03:11  *** Kexkey has joined #bitcoin-core-dev
182 2016-08-18T15:07:00  *** rubensayshi has joined #bitcoin-core-dev
183 2016-08-18T15:20:22  *** BashCo has quit IRC
184 2016-08-18T15:22:30  *** mkarrer has quit IRC
185 2016-08-18T15:29:38  *** mkarrer has joined #bitcoin-core-dev
186 2016-08-18T15:36:15  *** zerobit has joined #bitcoin-core-dev
187 2016-08-18T15:40:31  *** BashCo has joined #bitcoin-core-dev
188 2016-08-18T15:45:45  *** fengling has joined #bitcoin-core-dev
189 2016-08-18T15:47:03  *** aalex has quit IRC
190 2016-08-18T15:48:19  *** billotronic has joined #bitcoin-core-dev
191 2016-08-18T15:50:46  *** fengling has quit IRC
192 2016-08-18T15:58:12  *** jujumax has joined #bitcoin-core-dev
193 2016-08-18T16:06:34  *** TomMc has quit IRC
194 2016-08-18T16:09:28  *** zooko has joined #bitcoin-core-dev
195 2016-08-18T16:19:32  *** spudowiar has joined #bitcoin-core-dev
196 2016-08-18T16:20:08  *** JZA has quit IRC
197 2016-08-18T16:29:41  <cfields> jonasschnelli: ping. what's the easiest way to atomically retrieve the NodeId for the selected row in the peertable?
198 2016-08-18T16:30:55  <cfields> jonasschnelli: for context, I'm moving the ban functionality around a bit, and to prevent ambiguity, i'd like to ban based on NodeId rather than address
199 2016-08-18T16:32:23  <cfields> as a quick hack, I impelemented it by adding the NodeId as the first column in the table, so there's a quick path for lookup. But I'm not sure everyone would agree with the usefulness there.
200 2016-08-18T16:41:25  *** rubensayshi has quit IRC
201 2016-08-18T16:42:58  *** MarcoFalke has joined #bitcoin-core-dev
202 2016-08-18T16:46:05  *** aalex has joined #bitcoin-core-dev
203 2016-08-18T16:47:18  *** fengling has joined #bitcoin-core-dev
204 2016-08-18T16:52:06  *** fengling has quit IRC
205 2016-08-18T16:56:00  *** GreenIsMyPepper has quit IRC
206 2016-08-18T16:56:08  *** GreenIsMyPepper has joined #bitcoin-core-dev
207 2016-08-18T17:02:53  *** TomMc has joined #bitcoin-core-dev
208 2016-08-18T17:08:23  <btcdrak> Regarding MS/APPL codesigning certificates. What about getting one issued in the name of MIT DCI?
209 2016-08-18T17:14:02  <GitHub128> [bitcoin] leijurv opened pull request #8541: Trivial: Fix typos in various files (master...various-typos) https://github.com/bitcoin/bitcoin/pull/8541
210 2016-08-18T17:22:32  *** jujumax has quit IRC
211 2016-08-18T17:31:20  *** adiabat has quit IRC
212 2016-08-18T17:31:39  *** aalex_ has joined #bitcoin-core-dev
213 2016-08-18T17:34:09  *** aalex has quit IRC
214 2016-08-18T17:38:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
215 2016-08-18T17:40:19  *** aalex_ has quit IRC
216 2016-08-18T17:40:26  *** aalex has joined #bitcoin-core-dev
217 2016-08-18T17:48:48  *** fengling has joined #bitcoin-core-dev
218 2016-08-18T17:53:46  *** fengling has quit IRC
219 2016-08-18T18:02:36  *** laurentmt has joined #bitcoin-core-dev
220 2016-08-18T18:02:41  *** laurentmt has quit IRC
221 2016-08-18T18:05:56  <Chris_Stewart_5> In a merkle block it says we should never have two nodes with the same child hashes, however in a merkle tree if we have a an odd amount of txs we duplicate the last txid
222 2016-08-18T18:06:04  <Chris_Stewart_5> isn't this conflicting?
223 2016-08-18T18:07:03  <Chris_Stewart_5> 'However, if you find a node whose left and right children both have the same hash, fail. This is related to CVE-2012-2459.' wrt to Merkle blocks
224 2016-08-18T18:10:55  <sipa> Chris_Stewart_5: if you have *two* subnodes, their hashes should be different
225 2016-08-18T18:11:27  <sipa> because if that was the case, it would be indistinguishable from the case where there was only one subnode
226 2016-08-18T18:21:24  *** aalex has quit IRC
227 2016-08-18T18:27:32  <jonasschnelli> cfields: could you solve the Qt table nodeid problem?
228 2016-08-18T18:38:37  *** molz has joined #bitcoin-core-dev
229 2016-08-18T18:41:09  *** moli has quit IRC
230 2016-08-18T18:41:22  <cfields> jonasschnelli: no further along, wanted to get your preferred approach first
231 2016-08-18T18:41:39  <jonasschnelli> okay... let me have a loog
232 2016-08-18T18:41:41  <jonasschnelli> look
233 2016-08-18T18:42:31  <cfields> jonasschnelli: great, thanks
234 2016-08-18T18:42:58  <cfields> jonasschnelli: i can point you to my changes, if you'll promise to ignore the stuff happening around it :)
235 2016-08-18T18:43:13  <cfields> (i'm trying to break out this part for its own PR)
236 2016-08-18T18:43:53  *** molly has joined #bitcoin-core-dev
237 2016-08-18T18:44:45  <cfields> jonasschnelli: my attempt: https://github.com/theuni/bitcoin/commit/cfc8f2b6533e241258167af0da966cbe2e5e4d10#diff-a9100e8bfc1122159ae47eb2d2f3e6cf
238 2016-08-18T18:44:50  *** laurentmt has joined #bitcoin-core-dev
239 2016-08-18T18:45:55  <jonasschnelli> cfields: I like your approach,.. I just wanted to propose the same thing.
240 2016-08-18T18:46:19  <jonasschnelli> maybe rename PeerTableModel::Id to PeerTableModel::NodeId
241 2016-08-18T18:46:33  <cfields> jonasschnelli: ah, great. I'll break it out and PR then. Thanks!
242 2016-08-18T18:46:34  <jonasschnelli> Id seems to generic (could imply a table row id or somethig)
243 2016-08-18T18:46:36  <cfields> sure
244 2016-08-18T18:46:45  <cfields> yes, makes sense
245 2016-08-18T18:47:09  *** molz has quit IRC
246 2016-08-18T18:50:26  *** fengling has joined #bitcoin-core-dev
247 2016-08-18T18:50:39  *** JackH has quit IRC
248 2016-08-18T18:52:07  <cfields> jonasschnelli: hmm, is there still a need for mapNodeRows, then?
249 2016-08-18T18:52:42  <cfields> (I have no clue how fast searching rows is)
250 2016-08-18T18:52:48  <jonasschnelli> depends if you still call int detailNodeRow = clientModel->getPeerTableModel()->getRowByNodeId(cachedNodeid);
251 2016-08-18T18:53:11  <jonasschnelli> which is the "invers" function of row->nodeId
252 2016-08-18T18:53:25  <jonasschnelli> it's nodeid->row
253 2016-08-18T18:54:38  <cfields> jonasschnelli: right. Any reason not to just iterate all rows and look for the id rather than keeping a parallel map?
254 2016-08-18T18:55:09  <jonasschnelli> Not sure how performant a iteration over all rows could be in a 128 connection situation
255 2016-08-18T18:55:11  <cfields> or am i oversimplifying that?
256 2016-08-18T18:55:19  <jonasschnelli> Maybe keep the map for now.
257 2016-08-18T18:55:22  <cfields> ok, np. will keep it
258 2016-08-18T18:55:23  <jonasschnelli> Can be evicted later
259 2016-08-18T18:55:26  *** fengling has quit IRC
260 2016-08-18T18:56:25  <sipa> connection count can go up to 900 or so if you raise maxconnections
261 2016-08-18T18:57:33  *** Cory has quit IRC
262 2016-08-18T18:57:38  <jonasschnelli> Indeed...
263 2016-08-18T18:57:50  *** JZA has joined #bitcoin-core-dev
264 2016-08-18T18:58:12  <jonasschnelli> removing the map would probably require someone to test the performance in a 900connection environment...
265 2016-08-18T18:58:34  <sipa> i expect it to still be perfectly fine
266 2016-08-18T18:58:47  *** laurentmt has quit IRC
267 2016-08-18T18:59:55  <btcdrak> meeting time
268 2016-08-18T18:59:59  <jonasschnelli> Yes. Me 2. But I mostly follow the pradigm, only change what's necessary (especially if the diff is already large enought)
269 2016-08-18T19:00:01  <MarcoFalke> meeting time!
270 2016-08-18T19:00:02  <sipa> *ding*
271 2016-08-18T19:00:07  <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
272 2016-08-18T19:00:16  <wumpus> #meetingstart
273 2016-08-18T19:00:18  <kanzure> how do i know the ping is the real ping?
274 2016-08-18T19:00:19  <wumpus> #startmeeting
275 2016-08-18T19:00:19  <lightningbot> Meeting started Thu Aug 18 19:00:19 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
276 2016-08-18T19:00:19  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
277 2016-08-18T19:00:39  <jonasschnelli> proposed topic: core internal binary signing and verification tool
278 2016-08-18T19:00:40  <sipa> kanzure: its twitter handle is therealping
279 2016-08-18T19:00:45  <wumpus> kanzure: it comes from gmaxwell, who the offical meeting-pinger, and he is authenticated with freenode
280 2016-08-18T19:01:11  <btcdrak> how do we know freenode is still free?
281 2016-08-18T19:01:30  <wumpus> because otherwise it would be renamed to restrictednode
282 2016-08-18T19:01:32  <luke-jr> jonasschnelli: a tool would be nice, but there is no reason for it to be internal
283 2016-08-18T19:01:40  <jonasschnelli> there are
284 2016-08-18T19:01:50  <jonasschnelli> (to be covered under gitian)
285 2016-08-18T19:01:57  <wumpus> #topic core internal binary signing and verification tool
286 2016-08-18T19:02:01  <luke-jr> you can gitian-build things besides Bitcoin
287 2016-08-18T19:02:21  *** Cory has joined #bitcoin-core-dev
288 2016-08-18T19:02:26  <jonasschnelli> I propose to add to cli tools to the bitcoin-core package
289 2016-08-18T19:02:34  <kanzure> off-topic, but does anyone know the status of deterministic debian efforts?
290 2016-08-18T19:02:34  <jonasschnelli> bitcoin-core-verify and bitcoin-core-sign
291 2016-08-18T19:02:44  <jonasschnelli> The later will not be shipped
292 2016-08-18T19:02:47  <jonasschnelli> bitcoin-core-verify <folder-or-file> -> 1) hashes file(s) 2) download gitian assets files together with ECDSA sigs 3) verify hashed against downloaded assets files 4) verify assets ECDSA sigs against in-binary-pubkeys (dev-name/pubkey)
293 2016-08-18T19:02:51  <jonasschnelli> bitcoin-core-verify will list valid signatues of devs by listing devs name.
294 2016-08-18T19:02:55  <wumpus> I suppose it will be a separate executable within the bitcoin core distribution, other software can also include it if they want, but that's not initially very important
295 2016-08-18T19:02:57  <btcdrak> jonasschnelli I think it needs to be GUI for wider adoption.
296 2016-08-18T19:03:07  <jonasschnelli> Yes. It would be a Qt tool for one major reason
297 2016-08-18T19:03:08  <gmaxwell> Please don't do design in the meeting.
298 2016-08-18T19:03:10  <jonasschnelli> https downloads
299 2016-08-18T19:03:23  *** harrymm has quit IRC
300 2016-08-18T19:03:25  <jonasschnelli> gmaxwell: okay. fair enought...
301 2016-08-18T19:03:29  <gmaxwell> I'm planning on having someone work on that.
302 2016-08-18T19:03:49  <btcdrak> jonas is already building something afaik
303 2016-08-18T19:03:51  <wumpus> yes it needs https support to get at the signatures from github
304 2016-08-18T19:03:56  <jonasschnelli> Yes. But happy to pause.
305 2016-08-18T19:04:06  <gmaxwell> If it does https I will nak it so hard keys will fall  of the keyboard.
306 2016-08-18T19:04:07  <jonasschnelli> Qt would have https support built in
307 2016-08-18T19:04:21  <jonasschnelli> the gitian sigs come over https
308 2016-08-18T19:04:22  <gmaxwell> We _cannot_ ship some downloading tool that is going to require frequent CVEs itself.
309 2016-08-18T19:04:27  <wumpus> it's not a downloading tool
310 2016-08-18T19:04:28  <jonasschnelli> either with git or with https
311 2016-08-18T19:04:29  <MarcoFalke> So how do you verify bitcoin-core-verify?
312 2016-08-18T19:04:30  <wumpus> just a verification tool
313 2016-08-18T19:04:41  <wumpus> MarcoFalke: it'd be part of the distribution
314 2016-08-18T19:04:45  <btcdrak> no need for https when you have cryptographic verification
315 2016-08-18T19:04:51  <gmaxwell> What btcdrak said.
316 2016-08-18T19:04:58  <jonasschnelli> I guess even if https is broken, nobody can upload valid EC sigs
317 2016-08-18T19:05:05  <btcdrak> https _is_ broken
318 2016-08-18T19:05:12  <jonasschnelli> https is required to download from github I guess
319 2016-08-18T19:05:16  <wumpus> well if you can get information from github through http that would work too
320 2016-08-18T19:05:39  <jonasschnelli> Yes. TLS is not required for security.
321 2016-08-18T19:05:46  <luke-jr> the git protocol isn't encrypted I think
322 2016-08-18T19:05:55  <btcdrak> actually I think it's impossible to fetch from github without https, you'd have to use the git:// ptrotocol
323 2016-08-18T19:05:59  <wumpus> you seriously wouldn't want to implement the git protocol
324 2016-08-18T19:06:02  <cfields> wumpus: distribution == our release? Or OS?
325 2016-08-18T19:06:10  <jonasschnelli> he. yes. no git:// please
326 2016-08-18T19:06:10  <wumpus> cfields: yes, our releases
327 2016-08-18T19:06:46  <jonasschnelli> The only concern is – and this is why i borugh it up – the ec-pubkeys together with dev-name should be placed in bitcoin/bitcoin
328 2016-08-18T19:06:55  <wumpus> otherwise you'd have to host the signatures somewhere else than github, which is possible of course, but is a change in the release process
329 2016-08-18T19:06:57  <jonasschnelli> somewhere where it could be used in cpp source code (probably in a header)
330 2016-08-18T19:07:24  <wumpus> well the gpg keys are already in the respository
331 2016-08-18T19:07:25  <jonasschnelli> this would allow to build a "trusted-chain" of bitcoin-core binaries
332 2016-08-18T19:07:27  <cfields> mm. Can we back up then and address what this is aiming to solve? What protects against someone re-packaging a malicious release along with a clone "verification tool" that always passes?
333 2016-08-18T19:07:40  <kanzure> an email to the mailing list about verification procedures seems prudent at some point, as a general reminder. i'm sure there's existing content somewhere that can be copied for these purposes.
334 2016-08-18T19:07:44  <jonasschnelli> cfields: Sure. Thats always possible
335 2016-08-18T19:07:54  <btcdrak> just confirmed github forces https redirection
336 2016-08-18T19:07:58  <MarcoFalke> So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular?
337 2016-08-18T19:07:58  <wumpus> cfields: yes, it only works for chaining, if the first link in the chain is broken it solves nothing...
338 2016-08-18T19:08:05  <jonasschnelli> But not if you have verified the first download (assume with gitian verify), then verify with the new tool
339 2016-08-18T19:08:10  <gmaxwell> cfields: well if something competent were being done, the setup would be the last version you got provides a tool to get/verify the next version.
340 2016-08-18T19:08:14  <wumpus> MarcoFalke: it'd be used to check the *next* release downloaded
341 2016-08-18T19:08:32  <kanzure> bikeshedding for a sec, but "next" seems important enough to be part of the name ;)
342 2016-08-18T19:08:33  <jonasschnelli> people could still gitian-verify our new verification tool
343 2016-08-18T19:08:36  <wumpus> MarcoFalke: having it verify itself would be sillly
344 2016-08-18T19:08:37  <cfields> right.
345 2016-08-18T19:08:44  <gmaxwell> cfields: so if you previously got a good release, then you'll have good releases foreverafter (or at least until the signing keys were compromised :) )
346 2016-08-18T19:08:47  <MarcoFalke> ok, I see
347 2016-08-18T19:08:55  <kanzure> s/compromised/revoked?
348 2016-08-18T19:09:00  <kanzure> +revoked, at least?
349 2016-08-18T19:09:16  <cfields> kanzure: +1. that wasn't clear to me until now :)
350 2016-08-18T19:09:17  <jonasschnelli> key revoking is possible over our release-management
351 2016-08-18T19:09:23  <wumpus> kanzure: well it be N-out-of-M ,so could tolerate some revoked or compromised keys Iguess..
352 2016-08-18T19:09:26  <gmaxwell> kanzure: without an uncensorable communications medium or expiration there is no sense for revocation.
353 2016-08-18T19:09:33  <kanzure> hm.
354 2016-08-18T19:09:41  <wumpus> then they'd just be removed in the next release
355 2016-08-18T19:09:59  <jonasschnelli> I just wanted to hear if it's ackable to continue to work on this... if so, I'll come up with something for 0.14.
356 2016-08-18T19:10:25  <gmaxwell> n of m is close to an uncensorable communicatoins medium subject to an honest threshold assumption.
357 2016-08-18T19:10:29  <luke-jr> gmaxwell: well, if you're looking at the list of people/keys who *didn't* sign, it might help to know they revoked their key rater than simply didn't-sign
358 2016-08-18T19:10:32  <btcdrak> gmaxwell: what if you got a good release, but were later infected with malware which changed the verifier tool?
359 2016-08-18T19:10:43  <gmaxwell> btcdrak: oh well.
360 2016-08-18T19:10:50  <wumpus> btcdrak: if you are infected, it's end of story really
361 2016-08-18T19:10:53  *** skyraider has joined #bitcoin-core-dev
362 2016-08-18T19:10:55  <wumpus> btcdrak: it can already steal your coins
363 2016-08-18T19:10:55  <jonasschnelli> indeed
364 2016-08-18T19:10:55  <gmaxwell> btcdrak: if you're infected with malware you're hosed at that point.
365 2016-08-18T19:10:57  <sipa> btcdrak: you are eaten by a frue
366 2016-08-18T19:11:00  <sipa> *grue
367 2016-08-18T19:11:03  <jonasschnelli> you can't protect from malware on that layer
368 2016-08-18T19:11:11  <kanzure> perhaps the malware would be kind enough to at least inform you of your infection
369 2016-08-18T19:11:17  *** aalex has joined #bitcoin-core-dev
370 2016-08-18T19:11:20  <wumpus> that's another story entirely (hardaware wallets / security modules)
371 2016-08-18T19:11:20  <jonasschnelli> impossible
372 2016-08-18T19:11:47  <jonasschnelli> At least, the EC binary sig tool would allow hardware wallets to sign the binaries
373 2016-08-18T19:11:53  *** anchow101 has joined #bitcoin-core-dev
374 2016-08-18T19:11:58  <wumpus> that's an interesting idea
375 2016-08-18T19:12:03  <jonasschnelli> (though you can do this with GPG smartcard)
376 2016-08-18T19:12:13  <wumpus> there are smartcards running GPG?
377 2016-08-18T19:12:20  <jonasschnelli> Yes.
378 2016-08-18T19:12:22  <wumpus> is there some micro-gpg implementation?
379 2016-08-18T19:12:22  <btcdrak> yes
380 2016-08-18T19:12:34  <jonasschnelli> but a big mess
381 2016-08-18T19:12:39  <gmaxwell> A number of people around here use gpg via yubikey3.
382 2016-08-18T19:12:39  <wumpus> yeah...
383 2016-08-18T19:12:41  <btcdrak> petertodd has one with pin entry. sounds like he's at the cash register when sending emails
384 2016-08-18T19:12:50  <gmaxwell> wumpus: it's not really gpg on the smartcard, it's a rsa signer on a stick. :)
385 2016-08-18T19:13:20  <btcdrak> Ledger Nano S could be programmed to do signing. It also has a GPG module coming. It uses an ST31 secure element afaik
386 2016-08-18T19:13:34  <wumpus> gmaxwell: oh right, just the rsa signing, the ugly thing about gpg is all the packet parsing and interpretation etc
387 2016-08-18T19:13:52  <instagibbs> btcdrak, I have a pgp key from mine
388 2016-08-18T19:14:04  <instagibbs> (just playing around with it)
389 2016-08-18T19:14:19  <gmaxwell> There is a terrible complex standard for supporting it. In any case, it's a good thing to have.
390 2016-08-18T19:14:21  *** yep444 has joined #bitcoin-core-dev
391 2016-08-18T19:14:22  <wumpus> same problem as TLS really, the crypto algorithms themselves are reasonably elegant and bug-free, but all the parsing mess around it...
392 2016-08-18T19:14:47  <kanzure> should we move on?
393 2016-08-18T19:14:49  <wumpus> anyhow, I think we agree that we'd want to use secp256k1 signatures
394 2016-08-18T19:14:55  <wumpus> if we can agree on one thing
395 2016-08-18T19:15:00  <btcdrak> Just a separate note, I think everyone here should be using some kind of smartcard/hardware device for GPG signing. There are plenty inexpensive options like Yubikeys and etc.
396 2016-08-18T19:15:14  <jonasschnelli> Okay. I'll work on a short design and post it to bitcoin-core-dev ML
397 2016-08-18T19:15:29  <wumpus> btcdrak: I just use old computers, but I agree that's the more practical option :-)
398 2016-08-18T19:15:34  <kanzure> should we be complaining about hkp to the bitcoin.org people?
399 2016-08-18T19:15:44  <gmaxwell> jonasschnelli: can you spend some time and talk to mr or sipa before you post?
400 2016-08-18T19:16:03  <jonasschnelli> gmaxwell: Yes. Will do... thanks for offering that.
401 2016-08-18T19:16:35  <wumpus> kanzure: hkp?
402 2016-08-18T19:17:19  <kanzure> HPKP
403 2016-08-18T19:17:52  <kanzure> public key pinning
404 2016-08-18T19:17:58  *** harrymm has joined #bitcoin-core-dev
405 2016-08-18T19:18:18  <btcdrak> they also dont enforce HSTS
406 2016-08-18T19:18:29  <kanzure> does bitcoincore.org?
407 2016-08-18T19:18:32  <btcdrak> yes
408 2016-08-18T19:18:35  <kanzure> both?
409 2016-08-18T19:18:36  <jonasschnelli> Another short topic proposal that is near to the signing: code-signing (OSX/WIN).
410 2016-08-18T19:18:48  <wumpus> sure, why not, if anything can be done to improve site security we should encourag that
411 2016-08-18T19:19:00  <btcdrak> no, just HSTS and certificate origin
412 2016-08-18T19:19:37  <gmaxwell> HPKP is pretty easy to mess up. TBH it's a lot more useful for parties that are their own CA.
413 2016-08-18T19:20:02  <btcdrak> sorry, i mean authenticated origin pulls
414 2016-08-18T19:20:25  <btcdrak> HSTS is important to prevent https downgrade attacks imo
415 2016-08-18T19:20:27  <kanzure> okay well i'm eagerly awaiting for the delivery of the complimentary ips containers
416 2016-08-18T19:20:35  <wumpus> yes, HSTS is important, and trivial to implement
417 2016-08-18T19:20:57  <wumpus> never even heard of HPKP before
418 2016-08-18T19:21:09  <kanzure> jonasschnelli: iirc there was some detail about code signing and windows - something about a buggy state?
419 2016-08-18T19:21:17  <kadoban> HPKP is key-pinning. It's to prevent attacks like rogue CAs
420 2016-08-18T19:21:21  <wumpus> #topic code-signing (OSX/WIN)
421 2016-08-18T19:21:32  <jonasschnelli> We still sign with "Bitcoin Foundation"
422 2016-08-18T19:21:32  <btcdrak> while we are on the topic of releases and so on, wumpus could you please start posting the hashes with the release announcement too. that will ensure wide distribution of the hashes.
423 2016-08-18T19:21:42  <jonasschnelli> On OSX, its not very visible... on Windows I guess a bit more.
424 2016-08-18T19:21:51  <wumpus> kadoban: then gmaxwell's comment makes sense - sounds like a risky thing to do if you're depenent on someone else's CA
425 2016-08-18T19:22:04  <jonasschnelli> Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core".
426 2016-08-18T19:22:18  <gmaxwell> (I'm not saying that it shouldn't be done for that site, just that it's not a no brainer.)
427 2016-08-18T19:22:20  <jonasschnelli> The question is, if we should. :)
428 2016-08-18T19:22:23  <instagibbs> jonasschnelli, that's a statement :P
429 2016-08-18T19:22:27  <btcdrak> jonaschnelli: that would be great. do you have a company that can do it?
430 2016-08-18T19:22:29  <kadoban> wumpus: It's a little risky. You can pin any piece of the chain, like you can pin *your* private key(s). But then if you do it and screw it up ... you're *really* screwed.
431 2016-08-18T19:22:33  <kanzure> re: posting hashes, i also suggest we consider posting hashes and maybe sigs on bitcoincore.org -- we can also ask bitcoin.org to do the same if they feel up to that
432 2016-08-18T19:22:34  <wumpus> btcdrak: sure, I could paste sha256sums.asc into the announcement email
433 2016-08-18T19:22:39  <luke-jr> jonasschnelli: cfields was looking into this, but I am not sure his status
434 2016-08-18T19:22:47  <kadoban> Like, your website is unusable for 6 months screwed.
435 2016-08-18T19:22:47  <btcdrak> wumpus: thank you.
436 2016-08-18T19:22:57  <wumpus> kadoban: right - what if you want to switch CAs for some reason
437 2016-08-18T19:23:16  <wumpus> #action sha256sums in release email
438 2016-08-18T19:23:19  <jonasschnelli> btcdrak: I have serval code signing certificates.. but we don't want to use these company names...
439 2016-08-18T19:23:24  <gmaxwell> kanzure: I think thats not going in a useful direction. Posting hashes and stuff is fine, if people want to do it-- but its mostly security theater because virutally no one will check, and you can tell they don't check.
440 2016-08-18T19:23:28  <kadoban> wumpus: You can, if you do it right. You can reuse the same private keys with a different CA (and you can set multiple possible pins, so you can have backups)
441 2016-08-18T19:23:35  <cfields> luke-jr: didn't get anywhere with it. My best suggestion was to see if MIT would be interested in helping with a cert
442 2016-08-18T19:23:36  <wumpus> (do note that release emails are signed with *my* key, not the release signing key)
443 2016-08-18T19:23:59  <sipa> sorry i fell asleep
444 2016-08-18T19:24:47  <gmaxwell> Thats a sign to move on. :)
445 2016-08-18T19:24:51  <btcdrak> wumpus: We should also publish the hashes on bitcoincore.org with the release announcements there. Tempted to suggest we aim at mirroring downloads somewhere as well, like the github repo which supports release binaries and maybe bitcoincore.org
446 2016-08-18T19:25:06  <instagibbs> brainstorming can continue later imo
447 2016-08-18T19:25:08  <kanzure> wasn't github sunsetting hosted release binaries?
448 2016-08-18T19:25:16  <luke-jr> is there some organization name that people would be comfortable having sign both Core and Knots releases? would be nice to consolidate in that regard
449 2016-08-18T19:25:20  <wumpus> btcdrak: we already provide torrents for people that don't want to download from bitcoin.org - it solves nothing of the verification problems ofc
450 2016-08-18T19:25:29  <luke-jr> kanzure: I think they re-introduced them
451 2016-08-18T19:25:42  <kanzure> yes it makes sense to not use "Bitcoin Foundation" -- perhaps chaincode would be a good org to blame instead? :D (kidding- let's be nice)
452 2016-08-18T19:25:48  <wumpus> yes, github has the option to host release binaries
453 2016-08-18T19:25:53  <kanzure> luke-jr: got it
454 2016-08-18T19:26:04  <wumpus> but having the binaries in more places means more places to check wether they are compromised too
455 2016-08-18T19:26:05  <anchow101> Why not host binaries on GitHub and move completely off of bitcoin.orgs system
456 2016-08-18T19:26:16  <btcdrak> wumpus: we should do it there as a mirror at least.
457 2016-08-18T19:26:25  <wumpus> also it gives another reason to want to compromise our github
458 2016-08-18T19:26:59  * jonasschnelli is not sure if we should place the binaries on the same host at the source code
459 2016-08-18T19:27:00  <wumpus> I'm not comfortable with everyting in one place
460 2016-08-18T19:27:15  <sipa> let's use sourceforge *ducks*
461 2016-08-18T19:27:16  <wumpus> yea, exactly, feels like putting a lot of eggs inone basket
462 2016-08-18T19:27:20  <wumpus> hah
463 2016-08-18T19:27:23  * jonasschnelli stabs sipa 
464 2016-08-18T19:27:27  <warren> The more mirrors, the better.  Although the value of mirroring for diversity is wiped out by automated rsync which is how most people demand to keep mirrors updated.
465 2016-08-18T19:27:29  <gmaxwell> you don't think github isn't fully compromised already, come one? :)
466 2016-08-18T19:27:34  <gmaxwell> er come on
467 2016-08-18T19:27:46  <btcdrak> regarding bitcoincore.org I have a promising offer of sponsorship for around 5 years of hosting/infrastructure from Pindar, so we could setup a download server for example.
468 2016-08-18T19:27:54  <wumpus> well at least sudden code changes are fairly detectable
469 2016-08-18T19:28:07  <wumpus> (and we sign all top-level commits)
470 2016-08-18T19:28:16  <gmaxwell> please can we move on?
471 2016-08-18T19:28:18  <anchow101> What about Amazon s3 for binary hosting?
472 2016-08-18T19:28:18  <wumpus> so there is very little gain in compromising our github right now
473 2016-08-18T19:28:19  <btcdrak> The issue is less about being compromised and more about early warning.
474 2016-08-18T19:28:30  <wumpus> any other topics?
475 2016-08-18T19:28:41  <instagibbs> 0.13.0 final?
476 2016-08-18T19:28:42  <sipa> 0.13.0?
477 2016-08-18T19:28:45  <btcdrak> having multiple places makes it more likely a compromise would be spotted earlier
478 2016-08-18T19:29:02  <wumpus> btcdrak:  I disagree; it doesn't solve the problem of peopel not verifying at all
479 2016-08-18T19:29:07  <wumpus> #topic 0.13.0
480 2016-08-18T19:29:12  <kanzure> does anyone have details about the large quantity of revoked 'malicious' (fake) gpg short id matching keys from the other day? i saw this somewhere but didn't keep a reference.
481 2016-08-18T19:29:31  <instagibbs> kanzure, greg told me it was some academic paper's work
482 2016-08-18T19:29:32  <wumpus> I have only one thing to say on this topic: there have been no critical reported issues with rc3, in principle it could be tagged final at any time
483 2016-08-18T19:29:35  <MarcoFalke> I think the last doc change was merged. We can start gitian after the meeting?
484 2016-08-18T19:29:50  <kanzure> instagibbs: well i didn't hear it from greg. i did hear somewhere that it was a 'researcher'. but i have no idea where i saw this.
485 2016-08-18T19:29:54  <MarcoFalke> Or did anyone hear of critical problems?
486 2016-08-18T19:30:09  <btcdrak> MarcoFalke: it's all good from what I can see.
487 2016-08-18T19:30:17  <gmaxwell> kanzure: I'll provide citations after the meeting.
488 2016-08-18T19:30:18  <instagibbs> there was one report of stalled segwit ibd on testnet
489 2016-08-18T19:30:20  <sipa> kanzure: https://twitter.com/bcrypt/status/765615853488316416
490 2016-08-18T19:30:29  <wumpus> however the announcement of cobra this morning felt like someone dropped a bomb on the release process, and 'infected' 0.13.0 in people's minds before it is even released, so I feel really grumpy about this topic right now
491 2016-08-18T19:30:30  <instagibbs> but not sure if that's one-off or what
492 2016-08-18T19:30:42  <gmaxwell> instagibbs: I've been trying to reproduce marco's stalls with testnet. synced and caught up a few hosts.. so far nothing.
493 2016-08-18T19:31:07  <jonasschnelli> wumpus: agree, that was a imprudent move..
494 2016-08-18T19:31:07  <sipa> gmaxwell: do you have multiple header chains extending your active branch?
495 2016-08-18T19:31:08  <btcdrak> wumpus: maybe tag on Friday evening, let the gitian builders process over the weekend and we can release on Monday/tues/
496 2016-08-18T19:31:16  <MarcoFalke> I can upload my 8.5 gig datadir *ducks*
497 2016-08-18T19:31:33  <cfields> wumpus: tag it as 0.13.0.1 :)
498 2016-08-18T19:31:34  <gmaxwell> sipa: no I've just tried varrious things. I thought we already fixed the big with multiple header chains?
499 2016-08-18T19:31:39  <wumpus> cfields: lol :)
500 2016-08-18T19:31:49  <sipa> gmaxwell: i thought so too
501 2016-08-18T19:31:51  <btcdrak> cfields: lol
502 2016-08-18T19:32:05  <instagibbs> gmaxwell, me neither *shrug*
503 2016-08-18T19:32:05  <MarcoFalke> Able to reproduce consistently here, but this is something for 13.1
504 2016-08-18T19:32:06  <sipa> gmaxwell: but that was something i noticed in MarcoFalke's roc output
505 2016-08-18T19:32:16  <sipa> rpc
506 2016-08-18T19:32:38  <gmaxwell> MarcoFalke: if you have a sync failure that is reproducably consistently it may be a release blocker.
507 2016-08-18T19:32:40  <btcdrak> you mean 0.13.1
508 2016-08-18T19:32:43  <kanzure> wumpus: yeah, there should be a peer review process for posts to bitcoincore.org -- and bitcoin.org would be wise to adopt a similar practice.
509 2016-08-18T19:33:01  <gmaxwell> Please can we stop with the prior topic?
510 2016-08-18T19:33:05  <kanzure> okay.
511 2016-08-18T19:33:18  <btcdrak> last calls for review of the 0.13.0 blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199
512 2016-08-18T19:33:32  * btcdrak has been asking for two weeks....
513 2016-08-18T19:33:43  <sipa> btcdrak: i reviewed!
514 2016-08-18T19:33:45  <wumpus> yes we're slipping incredibly, for no really good reason, I know
515 2016-08-18T19:33:48  <wumpus> I feel bad about it too
516 2016-08-18T19:34:00  * btcdrak gives sipa a gold star!
517 2016-08-18T19:34:10  <wumpus> oh you mean the blog post, I'll take a look at it
518 2016-08-18T19:34:23  <gmaxwell> btcdrak: sorry, I missed that completely, will look.
519 2016-08-18T19:34:25  <wumpus> #action review https://github.com/bitcoin-core/bitcoincore.org/pull/199
520 2016-08-18T19:34:26  <instagibbs> I'll review today
521 2016-08-18T19:35:01  <btcdrak> wumpus: so tag friday evening, and release ~monday?
522 2016-08-18T19:35:11  <sipa> sounds fine be me
523 2016-08-18T19:35:14  <wumpus> any rationale for friday evening, and not, right now?
524 2016-08-18T19:35:21  <sipa> also fine by me
525 2016-08-18T19:35:25  <sdaftuar> sipa: is marco's issue that the stalling detection doesn't make sense if there are some outbound NODE_NETWORK peers you don't download blocks from?
526 2016-08-18T19:35:31  <gmaxwell> I am concerned that we have a reproducable candidate release blocker.
527 2016-08-18T19:35:55  <gmaxwell> we should become confident that it's segwit only.
528 2016-08-18T19:36:02  <wumpus> bah
529 2016-08-18T19:36:08  <btcdrak> wumpus: to give time for the cobra announcement to fade
530 2016-08-18T19:36:11  <gmaxwell> perhaps by having marco backup his state, and then disable segwit.
531 2016-08-18T19:36:16  <wumpus> I'm about to give up on 0.13 completely :p
532 2016-08-18T19:36:25  <wumpus> and focus on 0.14 from now on
533 2016-08-18T19:36:26  <sipa> wumpus: what, and release 0
534 2016-08-18T19:36:28  <btcdrak> 13 is unlucky number!
535 2016-08-18T19:36:31  <sipa> qe.1 instead?
536 2016-08-18T19:36:34  <wumpus> btcdrak: yes. exactly.
537 2016-08-18T19:36:38  <kanzure> one rationale for not right now is to give time for review on bitcoincore.org pull 199
538 2016-08-18T19:36:46  <btcdrak> ^
539 2016-08-18T19:36:47  <kanzure> so maybe like... whatever average review time is. heh.
540 2016-08-18T19:36:59  <wumpus> gitian building takes time too
541 2016-08-18T19:37:03  <gmaxwell> If the issue is segwit only-- and only rarely triggered, then I'm fine with it being 0.13.1, but I don't know if we know that.
542 2016-08-18T19:37:10  <instagibbs> wumpus, skip 0.12.1, go straight to 1.0, come on
543 2016-08-18T19:37:12  <wumpus> we can delay the uploading until your blog post is finished, sure
544 2016-08-18T19:37:36  <wumpus> instagibbs: skipping numbers doesn't work if we don't feel confident about the code, though
545 2016-08-18T19:37:38  <gmaxwell> I don't think there is a reason to hold off from what wumpus was suggesting, but we do need to make a determination on marco's sync bug.
546 2016-08-18T19:37:49  <sipa> gmaxwell: ok, i will prioritize reviewing marco's situation
547 2016-08-18T19:38:09  <wumpus> no one else reported it though
548 2016-08-18T19:38:21  <wumpus> I've done tons of syncs with this code
549 2016-08-18T19:38:23  <gmaxwell> I reported a similar one in the past, but we thought we fixed it.
550 2016-08-18T19:38:32  <kanzure> is it reproducible?
551 2016-08-18T19:38:36  <MarcoFalke> locally
552 2016-08-18T19:38:57  <gmaxwell> and at the time that was hit by a number of people. some of those reports might have been people actually hitting what marco is hitting now.
553 2016-08-18T19:39:00  <wumpus> but ok,anyhow, I guess we'll talk about this topic again next week
554 2016-08-18T19:39:12  <gmaxwell> pft.
555 2016-08-18T19:39:13  <wumpus> I've given uptrying to push for a release soon
556 2016-08-18T19:39:18  <warren> MarcoFalke: are you able to reproduce it on other platforms?  what kind of build are you using (gitian vs local on fedora?)
557 2016-08-18T19:39:22  <sipa> i hope 0.13.0 is released next week
558 2016-08-18T19:39:32  <sipa> wumpus: ok, i'll push
559 2016-08-18T19:39:34  <MarcoFalke> local on fedora
560 2016-08-18T19:39:41  <gmaxwell> wumpus: don't be fatalistic, in the next day or so we'll determine if marco's issue is segwit only. If it is, then continue as you suggested.
561 2016-08-18T19:39:42  <jonasschnelli> Do we delay then the final 0.13.0 only because of cobras post?
562 2016-08-18T19:39:43  <MarcoFalke> Can we do this trouble shooting after the meeting?
563 2016-08-18T19:39:55  <wumpus> sipa: thanks. I'm done being the person chasing people peonting at his watch for one
564 2016-08-18T19:40:09  <sipa> wumpus: ok
565 2016-08-18T19:40:17  <MarcoFalke> gmaxwell: I never saw it on main
566 2016-08-18T19:40:27  <wumpus> so should this delay setting up the release schedule for 0.14?
567 2016-08-18T19:40:53  <wumpus> that's kind of in limbo now, too
568 2016-08-18T19:40:55  <MarcoFalke> imo no. 0.14 can be less features. less rcs
569 2016-08-18T19:41:02  <gmaxwell> MarcoFalke: yes, but in three tries so far on rc3 I have not been able to reproduce your condition. So just because you didn't hit it on mainnet doesn't mean it isn't an issue there.
570 2016-08-18T19:41:38  <gmaxwell> Keep in mind the behavior you're seeing would potentially cause a consensus divergence if it happened to miners. It is a high criticality issue unless we know conditions that reduce its risk.
571 2016-08-18T19:41:54  <MarcoFalke> wumpus: There is some value in doing releases regular (c.f. firefox)
572 2016-08-18T19:42:03  <anchow101> Can someone link me to the issue?
573 2016-08-18T19:42:11  <wumpus> we have toruble doing the releases in the currently planne dschedule
574 2016-08-18T19:42:18  <wumpus> I don't even want to think about more regular releases
575 2016-08-18T19:42:20  <jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8518
576 2016-08-18T19:42:39  <sipa> wumpus: i disagree, your pushing to stick to a schedule was very valuable
577 2016-08-18T19:42:49  <wumpus> firefox has a completely different situation
578 2016-08-18T19:42:56  <gmaxwell> My impression is that we haven't really suffered any delay for 0.13 related to the general size. The rcs have not been horribly buggy or anything.
579 2016-08-18T19:43:11  <sipa> wumpus: i understand if you're worn out about it, but that does not make it a bad idea
580 2016-08-18T19:43:12  <sipa> we are still very close to on schedule for 0.13
581 2016-08-18T19:43:27  <jonasschnelli> Yes. Thanks to wumpus'es RC buffer
582 2016-08-18T19:43:47  <wumpus> sipa: sure! I'm still okay with the current release schedule (try to do a release every 6 months), but not in releases more often
583 2016-08-18T19:43:52  <sipa> so i would vote we schedule 0.14 as soon as 0.13.0 is out
584 2016-08-18T19:43:56  <jonasschnelli> I'm normally used to delay of *1.5 in software projects
585 2016-08-18T19:44:27  <wumpus> jonasschnelli: agree, it could be much worse :)
586 2016-08-18T19:44:39  <sipa> wumpus: it *used to be* much worse
587 2016-08-18T19:44:47  <sipa> for us.
588 2016-08-18T19:44:47  <jonasschnelli> 6 month seems to be perfectly fine. Just +6 month after the (possible) delayed last release
589 2016-08-18T19:44:50  <wumpus> jonasschnelli: then again, we have time-based releases, we don't wait for any feature, just for bug fixes
590 2016-08-18T19:45:14  <jonasschnelli> Yes. This seems to follow most agile development practices.
591 2016-08-18T19:45:38  <wumpus> in any case, any other topics?
592 2016-08-18T19:46:16  <zooko> Do y'all know about "binary transparency"?
593 2016-08-18T19:46:25  <jonasschnelli> tell us
594 2016-08-18T19:46:33  *** spudowiar has quit IRC
595 2016-08-18T19:46:41  <btcdrak> zooko: please explain
596 2016-08-18T19:46:42  <zooko> https://groups.google.com/forum/#!forum/binary-transparency
597 2016-08-18T19:46:54  <zooko> It's a project from Ben Laurie, as a follow-on to "certificate transparency".
598 2016-08-18T19:47:25  <zooko> There is a redundant set of servers which are claiming to do append-only logging of things published to them.
599 2016-08-18T19:47:53  <zooko> When you publish a binary, you submit its hash to these servers.
600 2016-08-18T19:48:16  <zooko> Clients should refrain from running a binary if the hash of that binary hasn't been broadcast by those servers.
601 2016-08-18T19:48:24  <jl2012> proposed topic: BIP146.
602 2016-08-18T19:48:36  *** gmaxwell has left #bitcoin-core-dev
603 2016-08-18T19:48:40  <zooko> This is a detection technique, more than a prevention technique, for people distributing different binaries to different users.
604 2016-08-18T19:49:07  <jonasschnelli> example: https://github.com/FreeBSDFoundation/binary-transparency-notes
605 2016-08-18T19:49:13  <jl2012> It is proposed to do the LOW_S and NULLDUMMY softfork at the same time as segwit
606 2016-08-18T19:50:07  <jonasschnelli> thanks zooko! I think we should take a closer look at the binary-transparency project.
607 2016-08-18T19:50:13  <wumpus> thanks zooko, it sounds interesting, although I'm not sure it is on topic for anything in the meeting. I don't think it can solve the concrete problem of people running binaries without verifying anything at all, unless OSes would build in support for that
608 2016-08-18T19:50:35  <wumpus> #topic BIP146
609 2016-08-18T19:50:38  <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki
610 2016-08-18T19:50:47  <warren> (OSX does prevent running unsigned binaries unless the user disables a default option.)
611 2016-08-18T19:51:09  <zooko> wumpus: good point. I think of it as primarily for detecting if someone is replacing binaries with alternate binaries, thinking that nobody will notice.
612 2016-08-18T19:51:13  <wumpus> warren: yes, but that only checks whether the binary is signed, not by whom, and not whether it's the same file other people gt
613 2016-08-18T19:51:17  <btcdrak> warren: but anyone can sign.
614 2016-08-18T19:51:22  <zooko> But not for preventing people from running the alternate binaries so much, because like you say…
615 2016-08-18T19:51:24  <wumpus> (the latter being the point of the binary transparency)
616 2016-08-18T19:51:24  <btcdrak> jl2012: speak up
617 2016-08-18T19:51:25  <warren> btcdrak: true
618 2016-08-18T19:51:28  <jonasschnelli> warren: In which case you fully have to trust apple
619 2016-08-18T19:51:34  <sipa> idea: LOW_S and NULLDUMMY have been nonstandard on the network for a long time, and do not appear on the chain (did anyone check they really do not appear?)
620 2016-08-18T19:51:48  *** fengling has joined #bitcoin-core-dev
621 2016-08-18T19:52:10  <sipa> together they would make *normal* transactions free from known malleability in segwit
622 2016-08-18T19:53:15  <jl2012> NULLDUMMY is a bigger problem than LOW_S, as an attacker may put anything as the dummy value
623 2016-08-18T19:53:41  <sipa> and they are both trivial
624 2016-08-18T19:54:00  <adam3us> zooko i was thinking another way to do this is by committing to a sequence of R=kG values.in the public key, so P=H(R1,R2,...,Q) and define a mapping from version numbers to R value. now signing two different binaries for the same version will likely leak your private key.
625 2016-08-18T19:54:22  <sipa> adam3us, zooko: can you wait until the meeting is ove
626 2016-08-18T19:54:32  <kanzure> is the request re: bip146 for more review?
627 2016-08-18T19:54:34  <btcdrak> for the record there was some discussion on the ML https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013006.html
628 2016-08-18T19:54:43  <kanzure> what is the request about bip146 about?
629 2016-08-18T19:54:54  <sipa> please discuss :)
630 2016-08-18T19:55:14  <jonasschnelli> jl2012: Would the NULLDUMMY affect current mainnet transaction
631 2016-08-18T19:55:14  <jl2012> LOW_S was discussed in last meeting but not NULLDUMMY
632 2016-08-18T19:55:18  <btcdrak> ha! I think we discussed LowS already, it's just the addition of NULLDUMMY that is new.
633 2016-08-18T19:55:20  <sipa> do we think it is doable in 0.13.1 / together with segwit
634 2016-08-18T19:55:48  <jl2012> jonasschnelli: yes in the current BIP146
635 2016-08-18T19:55:49  <btcdrak> sipa: I agree. it is a trivial addition.
636 2016-08-18T19:56:35  *** anchow101 has quit IRC
637 2016-08-18T19:56:45  <wumpus> yes, ack on LowS already, I don't know enough about NULLDUMMY to usefully comment
638 2016-08-18T19:56:46  *** fengling has quit IRC
639 2016-08-18T19:56:55  <btcdrak> 4 minute bell
640 2016-08-18T19:57:11  <luke-jr> wumpus: NULLDUMMY is just "the ignored value popped by CHECKMULTISIG must be zero"
641 2016-08-18T19:57:12  <sipa> nulldummy is liteeally: the ignored input to checkmultisig has to be the eempty vector
642 2016-08-18T19:57:16  <jonasschnelli> So, worst case, there are some non-NULLDUMMY producers/miners out there that would need to adjust to the new rule?
643 2016-08-18T19:57:38  <sipa> we should check if they are being included in the chain
644 2016-08-18T19:57:40  <wumpus> okay that seems harmless and easy to check
645 2016-08-18T19:57:44  <luke-jr> jonasschnelli: nobody sends these, so it's hard to know if anyone mines them
646 2016-08-18T19:57:54  <btcdrak> it's already nonstandard
647 2016-08-18T19:58:09  <wumpus> makes sense to include that with the LOWS cleanup then
648 2016-08-18T19:58:12  <luke-jr> oh, and since all miners MUST be on 0.12.1 now, nobody should mine these
649 2016-08-18T19:58:24  <sipa> why must they be on 0
650 2016-08-18T19:58:29  <sipa> why must they be on 0.12.1?
651 2016-08-18T19:58:29  <luke-jr> sipa: CSV?
652 2016-08-18T19:58:36  <btcdrak> last softfork
653 2016-08-18T19:59:02  <sipa> ah.
654 2016-08-18T19:59:03  <btcdrak> since we didnt release a 0.11.x they upgraded to 0.12.1
655 2016-08-18T19:59:28  <jonasschnelli> LOW_S & NULLDUMMY seems to make sense to include in the SW SF.
656 2016-08-18T19:59:30  <btcdrak> I think luke-jr's grammar has a bug or two :-p
657 2016-08-18T19:59:41  <wumpus> let's not have a new thing creep into SW every week though :p
658 2016-08-18T19:59:43  <BlueMatt> I'm not a huge fan of bundling them :/
659 2016-08-18T19:59:43  <luke-jr> btcdrak: ?
660 2016-08-18T19:59:55  <BlueMatt> though not against a separate sf that is also in 0.13.1, though thats also gross
661 2016-08-18T20:00:10  <btcdrak> BlueMatt: it's a trivial one liner (modulo tests)
662 2016-08-18T20:00:10  <luke-jr> the only reason to bundle IMO is if we want to add new non-VERIFY opcodes to segwit.
663 2016-08-18T20:00:19  <BlueMatt> btcdrak: I'm aware, doesnt mean I like it
664 2016-08-18T20:00:21  <wumpus> we discussed that last week BlueMatt, the disadvantage of not bundling is that no one would care about a separete softfork for them
665 2016-08-18T20:00:23  <wumpus> they're just a cleanup
666 2016-08-18T20:00:27  <luke-jr> but LOWS/NULLDUMMY are just softforks, so no need to bundle IMO
667 2016-08-18T20:00:35  <luke-jr> (no harm either)
668 2016-08-18T20:00:47  <BlueMatt> wumpus: ok, fair enough, though in same version...anyway, I'll hold my tounge
669 2016-08-18T20:01:00  <wumpus> #endmeeting
670 2016-08-18T20:01:00  <lightningbot> Meeting ended Thu Aug 18 20:01:00 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
671 2016-08-18T20:01:00  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.html
672 2016-08-18T20:01:00  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.txt
673 2016-08-18T20:01:00  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.log.html
674 2016-08-18T20:01:04  <btcdrak> fwiw, miners dont like to have to upgrade so frequently.
675 2016-08-18T20:01:28  <BlueMatt> btcdrak: yes, also if we had mempool-on-disk they'd care marginally less
676 2016-08-18T20:01:31  <BlueMatt> but still not fans
677 2016-08-18T20:01:47  <jonasschnelli> Removing all known sources of malleability in the initial SW SF should be achievable?
678 2016-08-18T20:01:47  <btcdrak> BlueMatt: there is a PR for that
679 2016-08-18T20:01:50  <BlueMatt> I'm aware
680 2016-08-18T20:01:52  <wumpus> there's a pull open to persist mempool to disk right?
681 2016-08-18T20:01:57  <BlueMatt> yes
682 2016-08-18T20:02:00  <sipa> yes, it's buggy thougg
683 2016-08-18T20:02:06  <sipa> i'll work on it again
684 2016-08-18T20:02:07  <btcdrak> is there an echo in here?
685 2016-08-18T20:02:08  <wumpus> that's 0.14 at first though
686 2016-08-18T20:02:23  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8448
687 2016-08-18T20:02:27  <jl2012> jonasschnelli: OP_IF/NOTIF is still a problem
688 2016-08-18T20:02:50  <btcdrak> jl2012: you were going to make that nonstandard for now iirc?
689 2016-08-18T20:03:34  <BlueMatt> re: re: low-s: I still run a node which malleates automatically and it still gets a lot of high-s txn
690 2016-08-18T20:03:51  <sipa> BlueMatt: wow, really :(
691 2016-08-18T20:03:52  <jl2012> btcdrak: yes
692 2016-08-18T20:04:09  <BlueMatt> sipa: I mean its not unlikely someone is malleating originally-low-s txn, though
693 2016-08-18T20:04:21  <sipa> BlueMatt: even while no recent releases relay high-s...
694 2016-08-18T20:04:22  <BlueMatt> sipa: I checked a month or so ago and it was like 1 per hour
695 2016-08-18T20:04:57  <btcdrak> they cant be getting mined though... all the miners are on 0.12.1
696 2016-08-18T20:05:34  <warren> maybe they are getting mined thanks to BlueMatt? =)
697 2016-08-18T20:06:18  <BlueMatt> btcdrak: the malleated versions can, though
698 2016-08-18T20:06:30  *** gmaxwell has joined #bitcoin-core-dev
699 2016-08-18T20:06:47  *** cryptapus has quit IRC
700 2016-08-18T20:07:06  <kanzure> gmaxwell: btw i found what i think is sufficient reference to my request about gpg short id happenings https://news.ycombinator.com/item?id=12298230 -- so nevermind
701 2016-08-18T20:09:06  <luke-jr> wumpus: minor detail, but I noticed the RCs were "0.13.0" internally; was the previous 0.12.99-ish scheme abandoned intentionally?
702 2016-08-18T20:09:34  <wumpus> luke-jr: IIRC rcs have always been the version internally
703 2016-08-18T20:09:46  <wumpus> rcs have never been 0.X.99
704 2016-08-18T20:09:47  <warren> luke-jr: IIRC rc's always were internally the version with "rcX" appended
705 2016-08-18T20:10:17  <wumpus> yes
706 2016-08-18T20:10:32  <sipa> long ago rcs were literally release candidates: the latest rc binary literally became the final binary
707 2016-08-18T20:10:47  <wumpus> right
708 2016-08-18T20:11:02  <sipa> though we'vdle gone through so many schemes that i can't say i'm sure anymore :)
709 2016-08-18T20:11:24  <wumpus> I've been entirely consistent the last few major releases
710 2016-08-18T20:11:47  * luke-jr questions his memory
711 2016-08-18T20:11:50  <warren> I joined around 0.8 and it was consistent since then at least.
712 2016-08-18T20:12:04  <sipa> the last release i did was 0.3.23
713 2016-08-18T20:15:02  <gmaxwell> So part of why I was deflecting on the endless rathole of the bitcoin.org stuff is because I had more to say that that I didn't fit in the scope of the meeting, and we had other things to accomplish that unfortunately we didn't have time for. :(
714 2016-08-18T20:15:08  <gmaxwell> Among the other things I wanted to say was this:
715 2016-08-18T20:15:10  <gmaxwell> Kanzure, achow101. Regarding your public comments on the bitcoin.org notice.
716 2016-08-18T20:15:13  <gmaxwell> https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/d6m1oqu
717 2016-08-18T20:15:16  <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw
718 2016-08-18T20:15:19  <gmaxwell> I think you've taken the wrong position, by pounding on process.
719 2016-08-18T20:15:22  <gmaxwell> If someone with privleged access is aware of a serious concern and believes
720 2016-08-18T20:15:25  <gmaxwell> they urgently need to tkae unilateral action to make a minimal statement
721 2016-08-18T20:15:28  <gmaxwell> simply to _notify_ people of the risk and encourage following an existing
722 2016-08-18T20:15:31  <gmaxwell> process to mitigate, they should do so. Pounding on procedure comes across
723 2016-08-18T20:15:34  <gmaxwell> as a denial which I don't believe you had the information to make.
724 2016-08-18T20:15:36  <gmaxwell> (and in fact, since achow101 did not talk to all the major developers, I
725 2016-08-18T20:15:39  <gmaxwell> _know_ you didn't have the information needed to make the claim you made.)
726 2016-08-18T20:15:42  <gmaxwell> And yes, someone doing something like that unilaterally is going to cause
727 2016-08-18T20:15:45  <gmaxwell> some pain. But that is okay, the security process should favor risk
728 2016-08-18T20:15:48  <gmaxwell> reduction, over creating a bit of pain here and there.
729 2016-08-18T20:15:50  <gmaxwell> [In fact, both of your messages could come across as expressing the view
730 2016-08-18T20:15:53  <gmaxwell> that we are skeptical that HTTPS MITM attacks are even a risk, when in fact
731 2016-08-18T20:15:56  <gmaxwell> we _know_ they are well documented to happen with some regularity.]
732 2016-08-18T20:15:59  <gmaxwell> We are at no real risk of tiring people out with a flood of false positives,
733 2016-08-18T20:16:02  <gmaxwell> otherwise I would take a different position, perhaps.
734 2016-08-18T20:16:04  <gmaxwell> Cobra isn't great at public relations, sure, but I notice none of the people
735 2016-08-18T20:16:07  <gmaxwell> complaining opened PRs to improve the language. His notice states the
736 2016-08-18T20:16:10  <gmaxwell> concern, the believed targets, and contains specific, conservative,
737 2016-08-18T20:16:12  <gmaxwell> mitigation instructions, it could be a lot worse.
738 2016-08-18T20:24:06  <kanzure> i hadn't considered some of that perspective, in particular that there is a benefit to being quick to make alerts. and downplaying alerts is probably not healthy either because it to some extent discourages others from making them in the future a little bit more.
739 2016-08-18T20:25:02  <kanzure> also, it's possible that achow101 was reading into my overly strong language. his comment was made after mine by a bit, after all.
740 2016-08-18T20:26:11  <gmaxwell> I don't think it's a big deal, but just like I'd encourage cobra to be more careful with presentation, I'd like to also ask y'all to try for a different handling here. :)
741 2016-08-18T20:31:12  <kanzure> yeah, got it.. plus, in rtrospect, it does seem a little silly that my first concern in that comment text is about process concerns... which is trivial for others to mistakenly read as "security concern denial". during incident response some other topics should probably be higher priority than that.
742 2016-08-18T20:46:32  *** cryptapus_afk has quit IRC
743 2016-08-18T20:53:19  *** fengling has joined #bitcoin-core-dev
744 2016-08-18T20:57:09  *** cryptapus_afk has joined #bitcoin-core-dev
745 2016-08-18T20:58:06  *** fengling has quit IRC
746 2016-08-18T21:01:12  *** cryptapus_afk is now known as cryptapus
747 2016-08-18T21:05:01  <achow101> gmaxwell: sorry about that. I was mostly reacting against the conspiracy theories and other idiotic claims that r/btc'ers make
748 2016-08-18T21:06:38  <gmaxwell> yea, that stuff was halarious.
749 2016-08-18T21:07:23  <kanzure> this seems like a good opportunity to show off a favorite tool of mine, https://mitmproxy.org/
750 2016-08-18T21:09:13  * luke-jr ponders hacking his email client to refuse to send to the old MLs :|
751 2016-08-18T21:09:46  <kanzure> send to both
752 2016-08-18T21:10:05  <luke-jr> kanzure: if I knew it was to the old ML, I'd just change it to the new one :P
753 2016-08-18T21:20:01  *** TomMc has quit IRC
754 2016-08-18T21:20:01  <cfields> jonasschnelli: i think i've decided against banning by id, as it introduces a possible failure if a node manages to disconnect just after you click "ban".
755 2016-08-18T21:20:16  <cfields> jonasschnelli: i can still PR the id addition to the table though, if you'd like
756 2016-08-18T21:25:40  *** zooko has quit IRC
757 2016-08-18T21:25:48  *** billotronic has quit IRC
758 2016-08-18T21:27:30  *** Guyver2 has quit IRC
759 2016-08-18T21:34:19  *** TomMc has joined #bitcoin-core-dev
760 2016-08-18T21:46:52  *** MarcoFalke has left #bitcoin-core-dev
761 2016-08-18T21:53:13  *** zooko has joined #bitcoin-core-dev
762 2016-08-18T21:54:48  *** fengling has joined #bitcoin-core-dev
763 2016-08-18T21:57:06  *** yep444 has quit IRC
764 2016-08-18T21:59:46  *** fengling has quit IRC
765 2016-08-18T22:00:44  *** aalex has quit IRC
766 2016-08-18T22:06:01  <midnightmagic> achow101: :-)
767 2016-08-18T22:32:20  *** JackH has joined #bitcoin-core-dev
768 2016-08-18T22:38:39  *** spudowiar has joined #bitcoin-core-dev
769 2016-08-18T22:45:32  *** TomMc has quit IRC
770 2016-08-18T22:49:57  *** JZA has quit IRC
771 2016-08-18T22:51:36  *** zooko has quit IRC
772 2016-08-18T22:52:12  <BashCo> fwiw, I've attempted a PR to improve the language of the binary safety alert. https://github.com/bitcoin-dot-org/bitcoin.org/pull/1344
773 2016-08-18T22:54:09  <BashCo> mostly focused on encouraging cross referencing keys from multiple sources, as well as signatures from multiple developers.
774 2016-08-18T22:55:48  *** netzin has joined #bitcoin-core-dev
775 2016-08-18T22:56:02  *** netzin is now known as n3tsin
776 2016-08-18T22:56:23  *** fengling has joined #bitcoin-core-dev
777 2016-08-18T22:58:50  *** JZA has joined #bitcoin-core-dev
778 2016-08-18T23:00:50  <GitHub168> [bitcoin] theuni opened pull request #8542: RFC: net: Pass best block known height into net (master...pass-in-height) https://github.com/bitcoin/bitcoin/pull/8542
779 2016-08-18T23:01:06  *** fengling has quit IRC
780 2016-08-18T23:25:50  <gmaxwell> Someone in #bitcoin had 17 BTC stolen from them today because they came for tech support (their wallet was a couple years behind and they were wondering why they hadn't seen a payment yet) and someone wumpus and I were talking to, "moldish", pulled them into PM and got them to do a dumpprivkey.  :(
781 2016-08-18T23:26:35  <midnightmagic> Is the money actually stolen?
782 2016-08-18T23:27:47  <gmaxwell> I believe there address was 1K35Q6BEkCvhE2k7SUeZXKDFTtZACEfNcn and its been cleaned out.
783 2016-08-18T23:28:49  <BlueMatt> ouch
784 2016-08-18T23:29:12  <BlueMatt> thats a bunch of cash, too
785 2016-08-18T23:34:57  <luke-jr> ugh, maybe we need more red lights on the debug window? :/
786 2016-08-18T23:35:57  <gmaxwell> We could make the dumpprivkey response include a # This is secret data which will allow anyone who knows it to steal your coins.
787 2016-08-18T23:36:12  <Lauda> +1
788 2016-08-18T23:37:29  <luke-jr> sounds easier than it probably is. stupid JSON has no comments
789 2016-08-18T23:41:34  <gmaxwell> I think that RPC doesn't return json?
790 2016-08-18T23:41:46  <gmaxwell> wait thats dumb, I guess it does.
791 2016-08-18T23:41:49  <gmaxwell> :-/
792 2016-08-18T23:43:20  <luke-jr> I suppose we could add some non-standard stuff to UniValue and strip it over real RPC (but not debug console)
793 2016-08-18T23:43:38  <gmaxwell> ugh. or make the debug console do something special.
794 2016-08-18T23:44:16  <luke-jr> but there's other unsafe things too - like importprivkey..
795 2016-08-18T23:44:27  <luke-jr> and a comment couldn't work for that case
796 2016-08-18T23:44:43  <gmaxwell> Yes, and I've seen someone robbed via that too. But it's less unsafe, I think.
797 2016-08-18T23:45:56  <luke-jr> is there anything not-unsafe normal users would ever use the debug window for? what's the downside of a generic red-flag in the initial message we have?
798 2016-08-18T23:46:53  <gmaxwell> lots of pure status things.
799 2016-08-18T23:47:01  <gmaxwell> getinfo/getchaintips/getmempoolinfo
800 2016-08-18T23:47:53  <gmaxwell> the only export/import privatekey and signraw transaction and sigmessage are really signficantly unsafe... and sigmessage is pretty hard to abuse, presuming the thing you have to sign is sensibly constructed.
801 2016-08-18T23:48:07  <luke-jr> signmessage has a proper GUI at least
802 2016-08-18T23:55:52  *** Ylbam has quit IRC
803 2016-08-18T23:57:52  *** fengling has joined #bitcoin-core-dev