1 2016-08-18 00:28:33	0|phantomcircuit|cfields: alrighty then
  2 2016-08-18 00:28:54	0|phantomcircuit|gmaxwell: things have been a bit lax on that front recently actually
  3 2016-08-18 00:29:11	0|phantomcircuit|personally i strongly prefer that each commit in a pr is itself functional
  4 2016-08-18 00:29:27	0|phantomcircuit|we've had a few where that's a commit at the end which fixes a bug in the first commit
  5 2016-08-18 00:30:54	0|jcorgan|it is nice to have all commits compile nicely to be able to use git bisect
  6 2016-08-18 00:31:11	0|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
  7 2016-08-18 00:31:27	0|cfields|phantomcircuit: looking at the rpc tests, i'm not seeing how the caches don't stomp eachother
  8 2016-08-18 00:34:09	0|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
  9 2016-08-18 00:44:10	0|sipa|phantomcircuit: every commit must compile and run tests
 10 2016-08-18 00:44:34	0|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
 11 2016-08-18 00:52:28	0|phantomcircuit|sipa: sure... but there's things where they compile and pass tests and we know them to be broken
 12 2016-08-18 00:54:58	0|sipa|ah, that shouldn't be
 13 2016-08-18 06:39:00	0|wumpus|travis is extremely broken
 14 2016-08-18 06:44:03	0|GitHub150|13bitcoin/06master 14fa64306 15MarcoFalke: [qa] abandonconflict: Use assert_equal
 15 2016-08-18 06:44:03	0|GitHub150|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/733035bdb755...a78f95a976de
 16 2016-08-18 06:44:04	0|GitHub150|13bitcoin/06master 14a78f95a 15Wladimir J. van der Laan: Merge #8531: [qa] abandonconflict: Use assert_equal...
 17 2016-08-18 06:44:13	0|GitHub90|[13bitcoin] 15laanwj closed pull request #8531: [qa] abandonconflict: Use assert_equal (06master...06Mf1608-qaAssert) 02https://github.com/bitcoin/bitcoin/pull/8531
 18 2016-08-18 06:59:21	0|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
 19 2016-08-18 06:59:46	0|jonasschnelli|It would require to also produce ECDSA sigs per assets file
 20 2016-08-18 07:00:08	0|jonasschnelli|And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git
 21 2016-08-18 07:00:25	0|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
 22 2016-08-18 07:00:34	0|wumpus|yes
 23 2016-08-18 07:01:03	0|wumpus|a user friendly gitian verifyer could be useful
 24 2016-08-18 07:01:33	0|jonasschnelli|Built into an already verified binary would be nice
 25 2016-08-18 07:02:03	0|wumpus|well it doesn't so much need to be part of the binary, could be a separate tool part of the distribution
 26 2016-08-18 07:02:08	0|jonasschnelli|Once you have verified with the gitian-verifier, you have a trusted chain of updates
 27 2016-08-18 07:02:22	0|jonasschnelli|Yes. Could be seperated...
 28 2016-08-18 07:02:23	0|jcorgan|it would also be useful to have the current release signature depend on the previous one, to form a hash chain of sorts
 29 2016-08-18 07:02:38	0|jonasschnelli|but should be built from the git repo where the ECDSA pubkeys are and also built over gitian
 30 2016-08-18 07:03:04	0|wumpus|jonasschnelli: agreed
 31 2016-08-18 07:03:34	0|wumpus|jcorgan: does that improve security? attackers can just as easily include a link to the previous signature
 32 2016-08-18 07:04:17	0|GitHub31|13bitcoin/06master 14fa0afde 15MarcoFalke: [travis] Drop java
 33 2016-08-18 07:04:17	0|GitHub31|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a78f95a976de...671fdae5f5b3
 34 2016-08-18 07:04:18	0|GitHub31|13bitcoin/06master 14671fdae 15Wladimir J. van der Laan: Merge #8534: [travis] Drop java...
 35 2016-08-18 07:04:29	0|GitHub13|[13bitcoin] 15laanwj closed pull request #8534: [travis] Drop java (06master...06Mf1608-qaJava) 02https://github.com/bitcoin/bitcoin/pull/8534
 36 2016-08-18 07:05:45	0|jcorgan|sure. it would just demonstrate an unbroken chain of release binaries, for those willing to verify current vs. prior.
 37 2016-08-18 07:06:04	0|jcorgan|admittedly, that seems like a very few people nowadays.
 38 2016-08-18 07:06:58	0|wumpus|right, although otoh people may be better off looking for the prior release themselves, then blindly trusting the (potentially faked) link
 39 2016-08-18 07:11:36	0|jcorgan|hard to ensure other's choices, only possible to give them the information needed to make good ones
 40 2016-08-18 07:13:02	0|wumpus|the segwit.py test is very broken in travis
 41 2016-08-18 07:13:40	0|wumpus|somehow not locally though
 42 2016-08-18 07:15:26	0|btcdrak|wumpus: travis randomly fails tests atm
 43 2016-08-18 07:15:47	0|wumpus|random tests?
 44 2016-08-18 07:16:13	0|btcdrak|look at jl2012 PR yesterday https://travis-ci.org/bitcoin/bitcoin/builds/153047455
 45 2016-08-18 07:16:42	0|wumpus|that's also segwit.py failing
 46 2016-08-18 07:16:45	0|btcdrak|the same build fails different tests
 47 2016-08-18 07:16:56	0|wumpus|and txn_doublespend
 48 2016-08-18 07:17:08	0|wumpus|looks like I reported the issue correct then here https://github.com/bitcoin/bitcoin/issues/8532
 49 2016-08-18 07:17:32	0|jl2012|I suspect that's related to the low s patch by sipa
 50 2016-08-18 07:17:38	0|wumpus|"Looks like with the reduced delay from fa2d68f, the nodes sync up before the txns all make it into the wallet"
 51 2016-08-18 07:17:44	0|wumpus|according to cfields
 52 2016-08-18 07:17:56	0|sipa|that failing segwit test was introduced in #8489 iirc
 53 2016-08-18 07:18:25	0|btcdrak|i think Cory nailed it
 54 2016-08-18 07:18:37	0|jl2012|Without his patch, bip164-p2p.py will fail
 55 2016-08-18 07:19:21	0|sipa|btcdrak, wumpus: but if shorter delays trigger errors, the tests are wrong
 56 2016-08-18 07:19:31	0|sipa|they shouldn't rely on timings
 57 2016-08-18 07:20:27	0|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
 58 2016-08-18 07:21:00	0|wumpus|if fixing the tests is straightforward (it's always those two) then I'm all for fixing them immediately, of course
 59 2016-08-18 07:21:35	0|wumpus|the alternative would be temporarily disabling them in travis
 60 2016-08-18 07:21:54	0|jl2012|By the way, they never fail on my mac
 61 2016-08-18 07:21:55	0|wumpus|but I prefer reverting the timeout change to that, as at least something gets tested then
 62 2016-08-18 07:22:01	0|wumpus|jl2012: I can't reproduce it locally either
 63 2016-08-18 07:22:45	0|MarcoFalke|wumpus: Agree on temp. revert. I will try to look into this now but there is no eta for tha acutal fix
 64 2016-08-18 07:23:55	0|GitHub68|13bitcoin/06master 1435f64e4 15Wladimir J. van der Laan: Revert "[qa] Adjust timeouts for micro-optimization of run time"...
 65 2016-08-18 07:23:55	0|GitHub68|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/35f64e45c207960078eef58ccc50d91e4abc2c55
 66 2016-08-18 07:29:37	0|MarcoFalke|Thanks
 67 2016-08-18 07:33:05	0|GitHub32|[13bitcoin] 15MarcoFalke opened pull request #8536: [WIP] [qa] Adjust timeouts for micro-optimization of run time (06master...06Mf1608-qaOptSync) 02https://github.com/bitcoin/bitcoin/pull/8536
 68 2016-08-18 11:24:30	0|GitHub88|[13bitcoin] 15mcccs opened pull request #8537: Trivial: little typos (06master...06litttle-typos) 02https://github.com/bitcoin/bitcoin/pull/8537
 69 2016-08-18 11:54:05	0|GitHub188|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/35f64e45c207...8250de13587e
 70 2016-08-18 11:54:06	0|GitHub188|13bitcoin/06master 140237096 15Wladimir J. van der Laan: Merge commit 'b2135359b3ad37cf2ac09b008079ddb237eff2c9'
 71 2016-08-18 11:54:06	0|GitHub188|13bitcoin/06master 14b213535 15Wladimir J. van der Laan: Squashed 'src/secp256k1/' changes from 6c527ec..7a49cac...
 72 2016-08-18 11:54:07	0|GitHub188|13bitcoin/06master 148250de1 15Pieter Wuille: Merge #8453: Bring secp256k1 subtree up to date with master...
 73 2016-08-18 11:54:15	0|GitHub62|[13bitcoin] 15sipa closed pull request #8453: Bring secp256k1 subtree up to date with master (06master...062016_08_update_secp256k1) 02https://github.com/bitcoin/bitcoin/pull/8453
 74 2016-08-18 13:04:55	0|GitHub101|[13bitcoin] 15mcccs opened pull request #8538: Remove IP transaction check (06master...06Ip-check) 02https://github.com/bitcoin/bitcoin/pull/8538
 75 2016-08-18 14:31:31	0|GitHub121|[13bitcoin] 15mcccs closed pull request #8537: Trivial: little typos (06master...06litttle-typos) 02https://github.com/bitcoin/bitcoin/pull/8537
 76 2016-08-18 14:42:45	0|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
 77 2016-08-18 14:43:16	0|jl2012|probably because your patch takes longer to sign and it timeouts?
 78 2016-08-18 14:50:31	0|jl2012|i think your patch double the signing time on average; and could take much longer with bad luck
 79 2016-08-18 14:54:39	0|GitHub165|[13bitcoin] 15crowning- opened pull request #8539: CDB: fix debug output (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8539
 80 2016-08-18 15:02:30	0|GitHub103|[13bitcoin] 15laanwj opened pull request #8540: qt: Fix random segfault when closing "Choose data directory" dialog (06master...062016_08_qt_choosedatadir_crash) 02https://github.com/bitcoin/bitcoin/pull/8540
 81 2016-08-18 16:29:41	0|cfields|jonasschnelli: ping. what's the easiest way to atomically retrieve the NodeId for the selected row in the peertable?
 82 2016-08-18 16:30:55	0|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
 83 2016-08-18 16:32:24	0|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.
 84 2016-08-18 17:08:23	0|btcdrak|Regarding MS/APPL codesigning certificates. What about getting one issued in the name of MIT DCI?
 85 2016-08-18 17:14:02	0|GitHub128|[13bitcoin] 15leijurv opened pull request #8541: Trivial: Fix typos in various files (06master...06various-typos) 02https://github.com/bitcoin/bitcoin/pull/8541
 86 2016-08-18 18:05:56	0|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
 87 2016-08-18 18:06:04	0|Chris_Stewart_5|isn't this conflicting?
 88 2016-08-18 18:07:04	0|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
 89 2016-08-18 18:10:56	0|sipa|Chris_Stewart_5: if you have *two* subnodes, their hashes should be different
 90 2016-08-18 18:11:27	0|sipa|because if that was the case, it would be indistinguishable from the case where there was only one subnode
 91 2016-08-18 18:27:32	0|jonasschnelli|cfields: could you solve the Qt table nodeid problem?
 92 2016-08-18 18:41:22	0|cfields|jonasschnelli: no further along, wanted to get your preferred approach first
 93 2016-08-18 18:41:39	0|jonasschnelli|okay... let me have a loog
 94 2016-08-18 18:41:41	0|jonasschnelli|look
 95 2016-08-18 18:42:31	0|cfields|jonasschnelli: great, thanks
 96 2016-08-18 18:42:58	0|cfields|jonasschnelli: i can point you to my changes, if you'll promise to ignore the stuff happening around it :)
 97 2016-08-18 18:43:13	0|cfields|(i'm trying to break out this part for its own PR)
 98 2016-08-18 18:44:46	0|cfields|jonasschnelli: my attempt: https://github.com/theuni/bitcoin/commit/cfc8f2b6533e241258167af0da966cbe2e5e4d10#diff-a9100e8bfc1122159ae47eb2d2f3e6cf
 99 2016-08-18 18:45:56	0|jonasschnelli|cfields: I like your approach,.. I just wanted to propose the same thing.
100 2016-08-18 18:46:19	0|jonasschnelli|maybe rename PeerTableModel::Id to PeerTableModel::NodeId
101 2016-08-18 18:46:34	0|cfields|jonasschnelli: ah, great. I'll break it out and PR then. Thanks!
102 2016-08-18 18:46:34	0|jonasschnelli|Id seems to generic (could imply a table row id or somethig)
103 2016-08-18 18:46:36	0|cfields|sure
104 2016-08-18 18:46:45	0|cfields|yes, makes sense
105 2016-08-18 18:52:08	0|cfields|jonasschnelli: hmm, is there still a need for mapNodeRows, then?
106 2016-08-18 18:52:43	0|cfields|(I have no clue how fast searching rows is)
107 2016-08-18 18:52:48	0|jonasschnelli|depends if you still call int detailNodeRow = clientModel->getPeerTableModel()->getRowByNodeId(cachedNodeid);
108 2016-08-18 18:53:11	0|jonasschnelli|which is the "invers" function of row->nodeId
109 2016-08-18 18:53:25	0|jonasschnelli|it's nodeid->row
110 2016-08-18 18:54:39	0|cfields|jonasschnelli: right. Any reason not to just iterate all rows and look for the id rather than keeping a parallel map?
111 2016-08-18 18:55:10	0|jonasschnelli|Not sure how performant a iteration over all rows could be in a 128 connection situation
112 2016-08-18 18:55:12	0|cfields|or am i oversimplifying that?
113 2016-08-18 18:55:20	0|jonasschnelli|Maybe keep the map for now.
114 2016-08-18 18:55:22	0|cfields|ok, np. will keep it
115 2016-08-18 18:55:24	0|jonasschnelli|Can be evicted later
116 2016-08-18 18:56:25	0|sipa|connection count can go up to 900 or so if you raise maxconnections
117 2016-08-18 18:57:38	0|jonasschnelli|Indeed...
118 2016-08-18 18:58:12	0|jonasschnelli|removing the map would probably require someone to test the performance in a 900connection environment...
119 2016-08-18 18:58:34	0|sipa|i expect it to still be perfectly fine
120 2016-08-18 18:59:56	0|btcdrak|meeting time
121 2016-08-18 19:00:00	0|jonasschnelli|Yes. Me 2. But I mostly follow the pradigm, only change what's necessary (especially if the diff is already large enought)
122 2016-08-18 19:00:02	0|MarcoFalke|meeting time!
123 2016-08-18 19:00:02	0|sipa|*ding*
124 2016-08-18 19:00:07	0|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
125 2016-08-18 19:00:16	0|wumpus|#meetingstart
126 2016-08-18 19:00:18	0|kanzure|how do i know the ping is the real ping?
127 2016-08-18 19:00:19	0|lightningbot|Meeting started Thu Aug 18 19:00:19 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
128 2016-08-18 19:00:19	0|wumpus|#startmeeting
129 2016-08-18 19:00:20	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
130 2016-08-18 19:00:39	0|jonasschnelli|proposed topic: core internal binary signing and verification tool
131 2016-08-18 19:00:40	0|sipa|kanzure: its twitter handle is therealping
132 2016-08-18 19:00:46	0|wumpus|kanzure: it comes from gmaxwell, who the offical meeting-pinger, and he is authenticated with freenode
133 2016-08-18 19:01:11	0|btcdrak|how do we know freenode is still free?
134 2016-08-18 19:01:30	0|wumpus|because otherwise it would be renamed to restrictednode
135 2016-08-18 19:01:32	0|luke-jr|jonasschnelli: a tool would be nice, but there is no reason for it to be internal
136 2016-08-18 19:01:41	0|jonasschnelli|there are
137 2016-08-18 19:01:51	0|jonasschnelli|(to be covered under gitian)
138 2016-08-18 19:01:57	0|wumpus|#topic core internal binary signing and verification tool
139 2016-08-18 19:02:02	0|luke-jr|you can gitian-build things besides Bitcoin
140 2016-08-18 19:02:27	0|jonasschnelli|I propose to add to cli tools to the bitcoin-core package
141 2016-08-18 19:02:34	0|kanzure|off-topic, but does anyone know the status of deterministic debian efforts?
142 2016-08-18 19:02:35	0|jonasschnelli|bitcoin-core-verify and bitcoin-core-sign
143 2016-08-18 19:02:44	0|jonasschnelli|The later will not be shipped
144 2016-08-18 19:02:47	0|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)
145 2016-08-18 19:02:51	0|jonasschnelli|bitcoin-core-verify will list valid signatues of devs by listing devs name.
146 2016-08-18 19:02:55	0|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
147 2016-08-18 19:02:57	0|btcdrak|jonasschnelli I think it needs to be GUI for wider adoption.
148 2016-08-18 19:03:08	0|jonasschnelli|Yes. It would be a Qt tool for one major reason
149 2016-08-18 19:03:09	0|gmaxwell|Please don't do design in the meeting.
150 2016-08-18 19:03:11	0|jonasschnelli|https downloads
151 2016-08-18 19:03:25	0|jonasschnelli|gmaxwell: okay. fair enought...
152 2016-08-18 19:03:29	0|gmaxwell|I'm planning on having someone work on that.
153 2016-08-18 19:03:49	0|btcdrak|jonas is already building something afaik
154 2016-08-18 19:03:52	0|wumpus|yes it needs https support to get at the signatures from github
155 2016-08-18 19:03:57	0|jonasschnelli|Yes. But happy to pause.
156 2016-08-18 19:04:07	0|gmaxwell|If it does https I will nak it so hard keys will fall  of the keyboard.
157 2016-08-18 19:04:07	0|jonasschnelli|Qt would have https support built in
158 2016-08-18 19:04:22	0|jonasschnelli|the gitian sigs come over https
159 2016-08-18 19:04:23	0|gmaxwell|We _cannot_ ship some downloading tool that is going to require frequent CVEs itself.
160 2016-08-18 19:04:28	0|wumpus|it's not a downloading tool
161 2016-08-18 19:04:29	0|jonasschnelli|either with git or with https
162 2016-08-18 19:04:30	0|MarcoFalke|So how do you verify bitcoin-core-verify?
163 2016-08-18 19:04:31	0|wumpus|just a verification tool
164 2016-08-18 19:04:41	0|wumpus|MarcoFalke: it'd be part of the distribution
165 2016-08-18 19:04:45	0|btcdrak|no need for https when you have cryptographic verification
166 2016-08-18 19:04:52	0|gmaxwell|What btcdrak said.
167 2016-08-18 19:04:58	0|jonasschnelli|I guess even if https is broken, nobody can upload valid EC sigs
168 2016-08-18 19:05:06	0|btcdrak|https _is_ broken
169 2016-08-18 19:05:13	0|jonasschnelli|https is required to download from github I guess
170 2016-08-18 19:05:17	0|wumpus|well if you can get information from github through http that would work too
171 2016-08-18 19:05:40	0|jonasschnelli|Yes. TLS is not required for security.
172 2016-08-18 19:05:46	0|luke-jr|the git protocol isn't encrypted I think
173 2016-08-18 19:05:55	0|btcdrak|actually I think it's impossible to fetch from github without https, you'd have to use the git:// ptrotocol
174 2016-08-18 19:05:59	0|wumpus|you seriously wouldn't want to implement the git protocol
175 2016-08-18 19:06:02	0|cfields|wumpus: distribution == our release? Or OS?
176 2016-08-18 19:06:10	0|jonasschnelli|he. yes. no git:// please
177 2016-08-18 19:06:11	0|wumpus|cfields: yes, our releases
178 2016-08-18 19:06:46	0|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
179 2016-08-18 19:06:55	0|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
180 2016-08-18 19:06:57	0|jonasschnelli|somewhere where it could be used in cpp source code (probably in a header)
181 2016-08-18 19:07:25	0|wumpus|well the gpg keys are already in the respository
182 2016-08-18 19:07:26	0|jonasschnelli|this would allow to build a "trusted-chain" of bitcoin-core binaries
183 2016-08-18 19:07:28	0|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?
184 2016-08-18 19:07:40	0|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.
185 2016-08-18 19:07:45	0|jonasschnelli|cfields: Sure. Thats always possible
186 2016-08-18 19:07:54	0|btcdrak|just confirmed github forces https redirection
187 2016-08-18 19:07:58	0|MarcoFalke|So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular?
188 2016-08-18 19:07:59	0|wumpus|cfields: yes, it only works for chaining, if the first link in the chain is broken it solves nothing...
189 2016-08-18 19:08:06	0|jonasschnelli|But not if you have verified the first download (assume with gitian verify), then verify with the new tool
190 2016-08-18 19:08:10	0|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.
191 2016-08-18 19:08:14	0|wumpus|MarcoFalke: it'd be used to check the *next* release downloaded
192 2016-08-18 19:08:32	0|kanzure|bikeshedding for a sec, but "next" seems important enough to be part of the name ;)
193 2016-08-18 19:08:33	0|jonasschnelli|people could still gitian-verify our new verification tool
194 2016-08-18 19:08:36	0|wumpus|MarcoFalke: having it verify itself would be sillly
195 2016-08-18 19:08:38	0|cfields|right.
196 2016-08-18 19:08:44	0|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 :) )
197 2016-08-18 19:08:47	0|MarcoFalke|ok, I see
198 2016-08-18 19:08:55	0|kanzure|s/compromised/revoked?
199 2016-08-18 19:09:00	0|kanzure|+revoked, at least?
200 2016-08-18 19:09:17	0|cfields|kanzure: +1. that wasn't clear to me until now :)
201 2016-08-18 19:09:17	0|jonasschnelli|key revoking is possible over our release-management
202 2016-08-18 19:09:23	0|wumpus|kanzure: well it be N-out-of-M ,so could tolerate some revoked or compromised keys Iguess..
203 2016-08-18 19:09:26	0|gmaxwell|kanzure: without an uncensorable communications medium or expiration there is no sense for revocation.
204 2016-08-18 19:09:34	0|kanzure|hm.
205 2016-08-18 19:09:41	0|wumpus|then they'd just be removed in the next release
206 2016-08-18 19:10:00	0|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.
207 2016-08-18 19:10:25	0|gmaxwell|n of m is close to an uncensorable communicatoins medium subject to an honest threshold assumption.
208 2016-08-18 19:10:30	0|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
209 2016-08-18 19:10:33	0|btcdrak|gmaxwell: what if you got a good release, but were later infected with malware which changed the verifier tool?
210 2016-08-18 19:10:44	0|gmaxwell|btcdrak: oh well.
211 2016-08-18 19:10:50	0|wumpus|btcdrak: if you are infected, it's end of story really
212 2016-08-18 19:10:55	0|gmaxwell|btcdrak: if you're infected with malware you're hosed at that point.
213 2016-08-18 19:10:55	0|jonasschnelli|indeed
214 2016-08-18 19:10:55	0|wumpus|btcdrak: it can already steal your coins
215 2016-08-18 19:10:58	0|sipa|btcdrak: you are eaten by a frue
216 2016-08-18 19:11:01	0|sipa|*grue
217 2016-08-18 19:11:03	0|jonasschnelli|you can't protect from malware on that layer
218 2016-08-18 19:11:12	0|kanzure|perhaps the malware would be kind enough to at least inform you of your infection
219 2016-08-18 19:11:20	0|jonasschnelli|impossible
220 2016-08-18 19:11:20	0|wumpus|that's another story entirely (hardaware wallets / security modules)
221 2016-08-18 19:11:47	0|jonasschnelli|At least, the EC binary sig tool would allow hardware wallets to sign the binaries
222 2016-08-18 19:11:58	0|wumpus|that's an interesting idea
223 2016-08-18 19:12:03	0|jonasschnelli|(though you can do this with GPG smartcard)
224 2016-08-18 19:12:14	0|wumpus|there are smartcards running GPG?
225 2016-08-18 19:12:21	0|jonasschnelli|Yes.
226 2016-08-18 19:12:22	0|wumpus|is there some micro-gpg implementation?
227 2016-08-18 19:12:23	0|btcdrak|yes
228 2016-08-18 19:12:34	0|jonasschnelli|but a big mess
229 2016-08-18 19:12:39	0|gmaxwell|A number of people around here use gpg via yubikey3.
230 2016-08-18 19:12:39	0|wumpus|yeah...
231 2016-08-18 19:12:41	0|btcdrak|petertodd has one with pin entry. sounds like he's at the cash register when sending emails
232 2016-08-18 19:12:50	0|gmaxwell|wumpus: it's not really gpg on the smartcard, it's a rsa signer on a stick. :)
233 2016-08-18 19:13:21	0|btcdrak|Ledger Nano S could be programmed to do signing. It also has a GPG module coming. It uses an ST31 secure element afaik
234 2016-08-18 19:13:35	0|wumpus|gmaxwell: oh right, just the rsa signing, the ugly thing about gpg is all the packet parsing and interpretation etc
235 2016-08-18 19:13:52	0|instagibbs|btcdrak, I have a pgp key from mine
236 2016-08-18 19:14:04	0|instagibbs|(just playing around with it)
237 2016-08-18 19:14:19	0|gmaxwell|There is a terrible complex standard for supporting it. In any case, it's a good thing to have.
238 2016-08-18 19:14:22	0|wumpus|same problem as TLS really, the crypto algorithms themselves are reasonably elegant and bug-free, but all the parsing mess around it...
239 2016-08-18 19:14:48	0|kanzure|should we move on?
240 2016-08-18 19:14:50	0|wumpus|anyhow, I think we agree that we'd want to use secp256k1 signatures
241 2016-08-18 19:14:55	0|wumpus|if we can agree on one thing
242 2016-08-18 19:15:00	0|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.
243 2016-08-18 19:15:15	0|jonasschnelli|Okay. I'll work on a short design and post it to bitcoin-core-dev ML
244 2016-08-18 19:15:29	0|wumpus|btcdrak: I just use old computers, but I agree that's the more practical option :-)
245 2016-08-18 19:15:35	0|kanzure|should we be complaining about hkp to the bitcoin.org people?
246 2016-08-18 19:15:44	0|gmaxwell|jonasschnelli: can you spend some time and talk to mr or sipa before you post?
247 2016-08-18 19:16:03	0|jonasschnelli|gmaxwell: Yes. Will do... thanks for offering that.
248 2016-08-18 19:16:35	0|wumpus|kanzure: hkp?
249 2016-08-18 19:17:19	0|kanzure|HPKP
250 2016-08-18 19:17:53	0|kanzure|public key pinning
251 2016-08-18 19:18:18	0|btcdrak|they also dont enforce HSTS
252 2016-08-18 19:18:29	0|kanzure|does bitcoincore.org?
253 2016-08-18 19:18:33	0|btcdrak|yes
254 2016-08-18 19:18:36	0|kanzure|both?
255 2016-08-18 19:18:37	0|jonasschnelli|Another short topic proposal that is near to the signing: code-signing (OSX/WIN).
256 2016-08-18 19:18:48	0|wumpus|sure, why not, if anything can be done to improve site security we should encourag that
257 2016-08-18 19:19:00	0|btcdrak|no, just HSTS and certificate origin
258 2016-08-18 19:19:38	0|gmaxwell|HPKP is pretty easy to mess up. TBH it's a lot more useful for parties that are their own CA.
259 2016-08-18 19:20:03	0|btcdrak|sorry, i mean authenticated origin pulls
260 2016-08-18 19:20:26	0|btcdrak|HSTS is important to prevent https downgrade attacks imo
261 2016-08-18 19:20:27	0|kanzure|okay well i'm eagerly awaiting for the delivery of the complimentary ips containers
262 2016-08-18 19:20:35	0|wumpus|yes, HSTS is important, and trivial to implement
263 2016-08-18 19:20:57	0|wumpus|never even heard of HPKP before
264 2016-08-18 19:21:09	0|kanzure|jonasschnelli: iirc there was some detail about code signing and windows - something about a buggy state?
265 2016-08-18 19:21:17	0|kadoban|HPKP is key-pinning. It's to prevent attacks like rogue CAs
266 2016-08-18 19:21:22	0|wumpus|#topic code-signing (OSX/WIN)
267 2016-08-18 19:21:32	0|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.
268 2016-08-18 19:21:32	0|jonasschnelli|We still sign with "Bitcoin Foundation"
269 2016-08-18 19:21:42	0|jonasschnelli|On OSX, its not very visible... on Windows I guess a bit more.
270 2016-08-18 19:21:52	0|wumpus|kadoban: then gmaxwell's comment makes sense - sounds like a risky thing to do if you're depenent on someone else's CA
271 2016-08-18 19:22:04	0|jonasschnelli|Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core".
272 2016-08-18 19:22:18	0|gmaxwell|(I'm not saying that it shouldn't be done for that site, just that it's not a no brainer.)
273 2016-08-18 19:22:20	0|jonasschnelli|The question is, if we should. :)
274 2016-08-18 19:22:23	0|instagibbs|jonasschnelli, that's a statement :P
275 2016-08-18 19:22:27	0|btcdrak|jonaschnelli: that would be great. do you have a company that can do it?
276 2016-08-18 19:22:30	0|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.
277 2016-08-18 19:22:34	0|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
278 2016-08-18 19:22:34	0|wumpus|btcdrak: sure, I could paste sha256sums.asc into the announcement email
279 2016-08-18 19:22:39	0|luke-jr|jonasschnelli: cfields was looking into this, but I am not sure his status
280 2016-08-18 19:22:47	0|kadoban|Like, your website is unusable for 6 months screwed.
281 2016-08-18 19:22:48	0|btcdrak|wumpus: thank you.
282 2016-08-18 19:22:57	0|wumpus|kadoban: right - what if you want to switch CAs for some reason
283 2016-08-18 19:23:16	0|wumpus|#action sha256sums in release email
284 2016-08-18 19:23:19	0|jonasschnelli|btcdrak: I have serval code signing certificates.. but we don't want to use these company names...
285 2016-08-18 19:23:24	0|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.
286 2016-08-18 19:23:29	0|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)
287 2016-08-18 19:23:35	0|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
288 2016-08-18 19:23:37	0|wumpus|(do note that release emails are signed with *my* key, not the release signing key)
289 2016-08-18 19:23:59	0|sipa|sorry i fell asleep
290 2016-08-18 19:24:48	0|gmaxwell|Thats a sign to move on. :)
291 2016-08-18 19:24:51	0|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
292 2016-08-18 19:25:07	0|instagibbs|brainstorming can continue later imo
293 2016-08-18 19:25:08	0|kanzure|wasn't github sunsetting hosted release binaries?
294 2016-08-18 19:25:16	0|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
295 2016-08-18 19:25:20	0|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
296 2016-08-18 19:25:30	0|luke-jr|kanzure: I think they re-introduced them
297 2016-08-18 19:25:42	0|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)
298 2016-08-18 19:25:48	0|wumpus|yes, github has the option to host release binaries
299 2016-08-18 19:25:53	0|kanzure|luke-jr: got it
300 2016-08-18 19:26:04	0|wumpus|but having the binaries in more places means more places to check wether they are compromised too
301 2016-08-18 19:26:06	0|anchow101|Why not host binaries on GitHub and move completely off of bitcoin.orgs system
302 2016-08-18 19:26:17	0|btcdrak|wumpus: we should do it there as a mirror at least.
303 2016-08-18 19:26:26	0|wumpus|also it gives another reason to want to compromise our github
304 2016-08-18 19:27:00	0|wumpus|I'm not comfortable with everyting in one place
305 2016-08-18 19:27:16	0|sipa|let's use sourceforge *ducks*
306 2016-08-18 19:27:16	0|wumpus|yea, exactly, feels like putting a lot of eggs inone basket
307 2016-08-18 19:27:20	0|wumpus|hah
308 2016-08-18 19:27:27	0|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.
309 2016-08-18 19:27:29	0|gmaxwell|you don't think github isn't fully compromised already, come one? :)
310 2016-08-18 19:27:35	0|gmaxwell|er come on
311 2016-08-18 19:27:46	0|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.
312 2016-08-18 19:27:55	0|wumpus|well at least sudden code changes are fairly detectable
313 2016-08-18 19:28:07	0|wumpus|(and we sign all top-level commits)
314 2016-08-18 19:28:17	0|gmaxwell|please can we move on?
315 2016-08-18 19:28:18	0|anchow101|What about Amazon s3 for binary hosting?
316 2016-08-18 19:28:18	0|wumpus|so there is very little gain in compromising our github right now
317 2016-08-18 19:28:20	0|btcdrak|The issue is less about being compromised and more about early warning.
318 2016-08-18 19:28:31	0|wumpus|any other topics?
319 2016-08-18 19:28:42	0|instagibbs|0.13.0 final?
320 2016-08-18 19:28:42	0|sipa|0.13.0?
321 2016-08-18 19:28:45	0|btcdrak|having multiple places makes it more likely a compromise would be spotted earlier
322 2016-08-18 19:29:02	0|wumpus|btcdrak:  I disagree; it doesn't solve the problem of peopel not verifying at all
323 2016-08-18 19:29:07	0|wumpus|#topic 0.13.0
324 2016-08-18 19:29:12	0|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.
325 2016-08-18 19:29:31	0|instagibbs|kanzure, greg told me it was some academic paper's work
326 2016-08-18 19:29:32	0|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
327 2016-08-18 19:29:36	0|MarcoFalke|I think the last doc change was merged. We can start gitian after the meeting?
328 2016-08-18 19:29:50	0|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.
329 2016-08-18 19:29:55	0|MarcoFalke|Or did anyone hear of critical problems?
330 2016-08-18 19:30:09	0|btcdrak|MarcoFalke: it's all good from what I can see.
331 2016-08-18 19:30:17	0|gmaxwell|kanzure: I'll provide citations after the meeting.
332 2016-08-18 19:30:19	0|instagibbs|there was one report of stalled segwit ibd on testnet
333 2016-08-18 19:30:20	0|sipa|kanzure: https://twitter.com/bcrypt/status/765615853488316416
334 2016-08-18 19:30:29	0|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
335 2016-08-18 19:30:30	0|instagibbs|but not sure if that's one-off or what
336 2016-08-18 19:30:42	0|gmaxwell|instagibbs: I've been trying to reproduce marco's stalls with testnet. synced and caught up a few hosts.. so far nothing.
337 2016-08-18 19:31:07	0|jonasschnelli|wumpus: agree, that was a imprudent move..
338 2016-08-18 19:31:08	0|sipa|gmaxwell: do you have multiple header chains extending your active branch?
339 2016-08-18 19:31:09	0|btcdrak|wumpus: maybe tag on Friday evening, let the gitian builders process over the weekend and we can release on Monday/tues/
340 2016-08-18 19:31:16	0|MarcoFalke|I can upload my 8.5 gig datadir *ducks*
341 2016-08-18 19:31:34	0|cfields|wumpus: tag it as 0.13.0.1 :)
342 2016-08-18 19:31:35	0|gmaxwell|sipa: no I've just tried varrious things. I thought we already fixed the big with multiple header chains?
343 2016-08-18 19:31:39	0|wumpus|cfields: lol :)
344 2016-08-18 19:31:50	0|sipa|gmaxwell: i thought so too
345 2016-08-18 19:31:51	0|btcdrak|cfields: lol
346 2016-08-18 19:32:05	0|instagibbs|gmaxwell, me neither *shrug*
347 2016-08-18 19:32:05	0|MarcoFalke|Able to reproduce consistently here, but this is something for 13.1
348 2016-08-18 19:32:06	0|sipa|gmaxwell: but that was something i noticed in MarcoFalke's roc output
349 2016-08-18 19:32:16	0|sipa|rpc
350 2016-08-18 19:32:39	0|gmaxwell|MarcoFalke: if you have a sync failure that is reproducably consistently it may be a release blocker.
351 2016-08-18 19:32:40	0|btcdrak|you mean 0.13.1
352 2016-08-18 19:32:43	0|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.
353 2016-08-18 19:33:02	0|gmaxwell|Please can we stop with the prior topic?
354 2016-08-18 19:33:05	0|kanzure|okay.
355 2016-08-18 19:33:18	0|btcdrak|last calls for review of the 0.13.0 blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199
356 2016-08-18 19:33:43	0|sipa|btcdrak: i reviewed!
357 2016-08-18 19:33:45	0|wumpus|yes we're slipping incredibly, for no really good reason, I know
358 2016-08-18 19:33:48	0|wumpus|I feel bad about it too
359 2016-08-18 19:34:11	0|wumpus|oh you mean the blog post, I'll take a look at it
360 2016-08-18 19:34:23	0|gmaxwell|btcdrak: sorry, I missed that completely, will look.
361 2016-08-18 19:34:26	0|instagibbs|I'll review today
362 2016-08-18 19:34:26	0|wumpus|#action review https://github.com/bitcoin-core/bitcoincore.org/pull/199
363 2016-08-18 19:35:01	0|btcdrak|wumpus: so tag friday evening, and release ~monday?
364 2016-08-18 19:35:12	0|sipa|sounds fine be me
365 2016-08-18 19:35:14	0|wumpus|any rationale for friday evening, and not, right now?
366 2016-08-18 19:35:21	0|sipa|also fine by me
367 2016-08-18 19:35:26	0|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?
368 2016-08-18 19:35:31	0|gmaxwell|I am concerned that we have a reproducable candidate release blocker.
369 2016-08-18 19:35:56	0|gmaxwell|we should become confident that it's segwit only.
370 2016-08-18 19:36:02	0|wumpus|bah
371 2016-08-18 19:36:08	0|btcdrak|wumpus: to give time for the cobra announcement to fade
372 2016-08-18 19:36:12	0|gmaxwell|perhaps by having marco backup his state, and then disable segwit.
373 2016-08-18 19:36:16	0|wumpus|I'm about to give up on 0.13 completely :p
374 2016-08-18 19:36:25	0|wumpus|and focus on 0.14 from now on
375 2016-08-18 19:36:27	0|sipa|wumpus: what, and release 0
376 2016-08-18 19:36:29	0|btcdrak|13 is unlucky number!
377 2016-08-18 19:36:31	0|sipa|qe.1 instead?
378 2016-08-18 19:36:34	0|wumpus|btcdrak: yes. exactly.
379 2016-08-18 19:36:38	0|kanzure|one rationale for not right now is to give time for review on bitcoincore.org pull 199
380 2016-08-18 19:36:46	0|btcdrak|^
381 2016-08-18 19:36:48	0|kanzure|so maybe like... whatever average review time is. heh.
382 2016-08-18 19:37:00	0|wumpus|gitian building takes time too
383 2016-08-18 19:37:03	0|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.
384 2016-08-18 19:37:11	0|instagibbs|wumpus, skip 0.12.1, go straight to 1.0, come on
385 2016-08-18 19:37:12	0|wumpus|we can delay the uploading until your blog post is finished, sure
386 2016-08-18 19:37:36	0|wumpus|instagibbs: skipping numbers doesn't work if we don't feel confident about the code, though
387 2016-08-18 19:37:38	0|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.
388 2016-08-18 19:37:49	0|sipa|gmaxwell: ok, i will prioritize reviewing marco's situation
389 2016-08-18 19:38:09	0|wumpus|no one else reported it though
390 2016-08-18 19:38:21	0|wumpus|I've done tons of syncs with this code
391 2016-08-18 19:38:23	0|gmaxwell|I reported a similar one in the past, but we thought we fixed it.
392 2016-08-18 19:38:32	0|kanzure|is it reproducible?
393 2016-08-18 19:38:37	0|MarcoFalke|locally
394 2016-08-18 19:38:58	0|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.
395 2016-08-18 19:39:01	0|wumpus|but ok,anyhow, I guess we'll talk about this topic again next week
396 2016-08-18 19:39:13	0|gmaxwell|pft.
397 2016-08-18 19:39:13	0|wumpus|I've given uptrying to push for a release soon
398 2016-08-18 19:39:18	0|warren|MarcoFalke: are you able to reproduce it on other platforms?  what kind of build are you using (gitian vs local on fedora?)
399 2016-08-18 19:39:22	0|sipa|i hope 0.13.0 is released next week
400 2016-08-18 19:39:32	0|sipa|wumpus: ok, i'll push
401 2016-08-18 19:39:35	0|MarcoFalke|local on fedora
402 2016-08-18 19:39:42	0|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.
403 2016-08-18 19:39:43	0|jonasschnelli|Do we delay then the final 0.13.0 only because of cobras post?
404 2016-08-18 19:39:43	0|MarcoFalke|Can we do this trouble shooting after the meeting?
405 2016-08-18 19:39:55	0|wumpus|sipa: thanks. I'm done being the person chasing people peonting at his watch for one
406 2016-08-18 19:40:09	0|sipa|wumpus: ok
407 2016-08-18 19:40:17	0|MarcoFalke|gmaxwell: I never saw it on main
408 2016-08-18 19:40:27	0|wumpus|so should this delay setting up the release schedule for 0.14?
409 2016-08-18 19:40:54	0|wumpus|that's kind of in limbo now, too
410 2016-08-18 19:40:55	0|MarcoFalke|imo no. 0.14 can be less features. less rcs
411 2016-08-18 19:41:02	0|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.
412 2016-08-18 19:41:38	0|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.
413 2016-08-18 19:41:54	0|MarcoFalke|wumpus: There is some value in doing releases regular (c.f. firefox)
414 2016-08-18 19:42:03	0|anchow101|Can someone link me to the issue?
415 2016-08-18 19:42:11	0|wumpus|we have toruble doing the releases in the currently planne dschedule
416 2016-08-18 19:42:18	0|wumpus|I don't even want to think about more regular releases
417 2016-08-18 19:42:21	0|jonasschnelli|https://github.com/bitcoin/bitcoin/issues/8518
418 2016-08-18 19:42:40	0|sipa|wumpus: i disagree, your pushing to stick to a schedule was very valuable
419 2016-08-18 19:42:49	0|wumpus|firefox has a completely different situation
420 2016-08-18 19:42:57	0|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.
421 2016-08-18 19:43:12	0|sipa|wumpus: i understand if you're worn out about it, but that does not make it a bad idea
422 2016-08-18 19:43:13	0|sipa|we are still very close to on schedule for 0.13
423 2016-08-18 19:43:27	0|jonasschnelli|Yes. Thanks to wumpus'es RC buffer
424 2016-08-18 19:43:48	0|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
425 2016-08-18 19:43:53	0|sipa|so i would vote we schedule 0.14 as soon as 0.13.0 is out
426 2016-08-18 19:43:56	0|jonasschnelli|I'm normally used to delay of *1.5 in software projects
427 2016-08-18 19:44:28	0|wumpus|jonasschnelli: agree, it could be much worse :)
428 2016-08-18 19:44:40	0|sipa|wumpus: it *used to be* much worse
429 2016-08-18 19:44:47	0|jonasschnelli|6 month seems to be perfectly fine. Just +6 month after the (possible) delayed last release
430 2016-08-18 19:44:47	0|sipa|for us.
431 2016-08-18 19:44:51	0|wumpus|jonasschnelli: then again, we have time-based releases, we don't wait for any feature, just for bug fixes
432 2016-08-18 19:45:15	0|jonasschnelli|Yes. This seems to follow most agile development practices.
433 2016-08-18 19:45:38	0|wumpus|in any case, any other topics?
434 2016-08-18 19:46:16	0|zooko|Do y'all know about "binary transparency"?
435 2016-08-18 19:46:25	0|jonasschnelli|tell us
436 2016-08-18 19:46:41	0|btcdrak|zooko: please explain
437 2016-08-18 19:46:43	0|zooko|https://groups.google.com/forum/#!forum/binary-transparency
438 2016-08-18 19:46:54	0|zooko|It's a project from Ben Laurie, as a follow-on to "certificate transparency".
439 2016-08-18 19:47:25	0|zooko|There is a redundant set of servers which are claiming to do append-only logging of things published to them.
440 2016-08-18 19:47:53	0|zooko|When you publish a binary, you submit its hash to these servers.
441 2016-08-18 19:48:16	0|zooko|Clients should refrain from running a binary if the hash of that binary hasn't been broadcast by those servers.
442 2016-08-18 19:48:24	0|jl2012|proposed topic: BIP146.
443 2016-08-18 19:48:40	0|zooko|This is a detection technique, more than a prevention technique, for people distributing different binaries to different users.
444 2016-08-18 19:49:07	0|jonasschnelli|example: https://github.com/FreeBSDFoundation/binary-transparency-notes
445 2016-08-18 19:49:13	0|jl2012|It is proposed to do the LOW_S and NULLDUMMY softfork at the same time as segwit
446 2016-08-18 19:50:08	0|jonasschnelli|thanks zooko! I think we should take a closer look at the binary-transparency project.
447 2016-08-18 19:50:14	0|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
448 2016-08-18 19:50:35	0|wumpus|#topic BIP146
449 2016-08-18 19:50:38	0|btcdrak|#link https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki
450 2016-08-18 19:50:48	0|warren|(OSX does prevent running unsigned binaries unless the user disables a default option.)
451 2016-08-18 19:51:09	0|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.
452 2016-08-18 19:51:13	0|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
453 2016-08-18 19:51:17	0|btcdrak|warren: but anyone can sign.
454 2016-08-18 19:51:22	0|zooko|But not for preventing people from running the alternate binaries so much, because like you say…
455 2016-08-18 19:51:24	0|btcdrak|jl2012: speak up
456 2016-08-18 19:51:24	0|wumpus|(the latter being the point of the binary transparency)
457 2016-08-18 19:51:26	0|warren|btcdrak: true
458 2016-08-18 19:51:28	0|jonasschnelli|warren: In which case you fully have to trust apple
459 2016-08-18 19:51:34	0|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?)
460 2016-08-18 19:52:10	0|sipa|together they would make *normal* transactions free from known malleability in segwit
461 2016-08-18 19:53:15	0|jl2012|NULLDUMMY is a bigger problem than LOW_S, as an attacker may put anything as the dummy value
462 2016-08-18 19:53:41	0|sipa|and they are both trivial
463 2016-08-18 19:54:00	0|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.
464 2016-08-18 19:54:22	0|sipa|adam3us, zooko: can you wait until the meeting is ove
465 2016-08-18 19:54:32	0|kanzure|is the request re: bip146 for more review?
466 2016-08-18 19:54:34	0|btcdrak|for the record there was some discussion on the ML https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013006.html
467 2016-08-18 19:54:43	0|kanzure|what is the request about bip146 about?
468 2016-08-18 19:54:54	0|sipa|please discuss :)
469 2016-08-18 19:55:14	0|jl2012|LOW_S was discussed in last meeting but not NULLDUMMY
470 2016-08-18 19:55:14	0|jonasschnelli|jl2012: Would the NULLDUMMY affect current mainnet transaction
471 2016-08-18 19:55:18	0|btcdrak|ha! I think we discussed LowS already, it's just the addition of NULLDUMMY that is new.
472 2016-08-18 19:55:21	0|sipa|do we think it is doable in 0.13.1 / together with segwit
473 2016-08-18 19:55:48	0|jl2012|jonasschnelli: yes in the current BIP146
474 2016-08-18 19:55:49	0|btcdrak|sipa: I agree. it is a trivial addition.
475 2016-08-18 19:56:45	0|wumpus|yes, ack on LowS already, I don't know enough about NULLDUMMY to usefully comment
476 2016-08-18 19:56:55	0|btcdrak|4 minute bell
477 2016-08-18 19:57:12	0|luke-jr|wumpus: NULLDUMMY is just "the ignored value popped by CHECKMULTISIG must be zero"
478 2016-08-18 19:57:12	0|sipa|nulldummy is liteeally: the ignored input to checkmultisig has to be the eempty vector
479 2016-08-18 19:57:16	0|jonasschnelli|So, worst case, there are some non-NULLDUMMY producers/miners out there that would need to adjust to the new rule?
480 2016-08-18 19:57:38	0|sipa|we should check if they are being included in the chain
481 2016-08-18 19:57:40	0|wumpus|okay that seems harmless and easy to check
482 2016-08-18 19:57:44	0|luke-jr|jonasschnelli: nobody sends these, so it's hard to know if anyone mines them
483 2016-08-18 19:57:55	0|btcdrak|it's already nonstandard
484 2016-08-18 19:58:10	0|wumpus|makes sense to include that with the LOWS cleanup then
485 2016-08-18 19:58:12	0|luke-jr|oh, and since all miners MUST be on 0.12.1 now, nobody should mine these
486 2016-08-18 19:58:24	0|sipa|why must they be on 0
487 2016-08-18 19:58:29	0|luke-jr|sipa: CSV?
488 2016-08-18 19:58:29	0|sipa|why must they be on 0.12.1?
489 2016-08-18 19:58:36	0|btcdrak|last softfork
490 2016-08-18 19:59:03	0|btcdrak|since we didnt release a 0.11.x they upgraded to 0.12.1
491 2016-08-18 19:59:03	0|sipa|ah.
492 2016-08-18 19:59:28	0|jonasschnelli|LOW_S & NULLDUMMY seems to make sense to include in the SW SF.
493 2016-08-18 19:59:31	0|btcdrak|I think luke-jr's grammar has a bug or two :-p
494 2016-08-18 19:59:42	0|wumpus|let's not have a new thing creep into SW every week though :p
495 2016-08-18 19:59:43	0|BlueMatt|I'm not a huge fan of bundling them :/
496 2016-08-18 19:59:43	0|luke-jr|btcdrak: ?
497 2016-08-18 19:59:56	0|BlueMatt|though not against a separate sf that is also in 0.13.1, though thats also gross
498 2016-08-18 20:00:10	0|btcdrak|BlueMatt: it's a trivial one liner (modulo tests)
499 2016-08-18 20:00:11	0|luke-jr|the only reason to bundle IMO is if we want to add new non-VERIFY opcodes to segwit.
500 2016-08-18 20:00:19	0|BlueMatt|btcdrak: I'm aware, doesnt mean I like it
501 2016-08-18 20:00:21	0|wumpus|we discussed that last week BlueMatt, the disadvantage of not bundling is that no one would care about a separete softfork for them
502 2016-08-18 20:00:24	0|wumpus|they're just a cleanup
503 2016-08-18 20:00:27	0|luke-jr|but LOWS/NULLDUMMY are just softforks, so no need to bundle IMO
504 2016-08-18 20:00:35	0|luke-jr|(no harm either)
505 2016-08-18 20:00:48	0|BlueMatt|wumpus: ok, fair enough, though in same version...anyway, I'll hold my tounge
506 2016-08-18 20:01:01	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.log.html
507 2016-08-18 20:01:01	0|lightningbot|Meeting ended Thu Aug 18 20:01:00 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
508 2016-08-18 20:01:01	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.html
509 2016-08-18 20:01:01	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-18-19.00.txt
510 2016-08-18 20:01:01	0|wumpus|#endmeeting
511 2016-08-18 20:01:05	0|btcdrak|fwiw, miners dont like to have to upgrade so frequently.
512 2016-08-18 20:01:28	0|BlueMatt|btcdrak: yes, also if we had mempool-on-disk they'd care marginally less
513 2016-08-18 20:01:31	0|BlueMatt|but still not fans
514 2016-08-18 20:01:47	0|btcdrak|BlueMatt: there is a PR for that
515 2016-08-18 20:01:47	0|jonasschnelli|Removing all known sources of malleability in the initial SW SF should be achievable?
516 2016-08-18 20:01:51	0|BlueMatt|I'm aware
517 2016-08-18 20:01:53	0|wumpus|there's a pull open to persist mempool to disk right?
518 2016-08-18 20:01:57	0|BlueMatt|yes
519 2016-08-18 20:02:00	0|sipa|yes, it's buggy thougg
520 2016-08-18 20:02:06	0|sipa|i'll work on it again
521 2016-08-18 20:02:07	0|btcdrak|is there an echo in here?
522 2016-08-18 20:02:08	0|wumpus|that's 0.14 at first though
523 2016-08-18 20:02:24	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8448
524 2016-08-18 20:02:27	0|jl2012|jonasschnelli: OP_IF/NOTIF is still a problem
525 2016-08-18 20:02:50	0|btcdrak|jl2012: you were going to make that nonstandard for now iirc?
526 2016-08-18 20:03:35	0|BlueMatt|re: re: low-s: I still run a node which malleates automatically and it still gets a lot of high-s txn
527 2016-08-18 20:03:51	0|sipa|BlueMatt: wow, really :(
528 2016-08-18 20:03:53	0|jl2012|btcdrak: yes
529 2016-08-18 20:04:09	0|BlueMatt|sipa: I mean its not unlikely someone is malleating originally-low-s txn, though
530 2016-08-18 20:04:22	0|BlueMatt|sipa: I checked a month or so ago and it was like 1 per hour
531 2016-08-18 20:04:22	0|sipa|BlueMatt: even while no recent releases relay high-s...
532 2016-08-18 20:04:58	0|btcdrak|they cant be getting mined though... all the miners are on 0.12.1
533 2016-08-18 20:05:34	0|warren|maybe they are getting mined thanks to BlueMatt? =)
534 2016-08-18 20:06:18	0|BlueMatt|btcdrak: the malleated versions can, though
535 2016-08-18 20:07:06	0|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
536 2016-08-18 20:09:07	0|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?
537 2016-08-18 20:09:35	0|wumpus|luke-jr: IIRC rcs have always been the version internally
538 2016-08-18 20:09:47	0|wumpus|rcs have never been 0.X.99
539 2016-08-18 20:09:48	0|warren|luke-jr: IIRC rc's always were internally the version with "rcX" appended
540 2016-08-18 20:10:17	0|wumpus|yes
541 2016-08-18 20:10:32	0|sipa|long ago rcs were literally release candidates: the latest rc binary literally became the final binary
542 2016-08-18 20:10:48	0|wumpus|right
543 2016-08-18 20:11:03	0|sipa|though we'vdle gone through so many schemes that i can't say i'm sure anymore :)
544 2016-08-18 20:11:24	0|wumpus|I've been entirely consistent the last few major releases
545 2016-08-18 20:11:51	0|warren|I joined around 0.8 and it was consistent since then at least.
546 2016-08-18 20:12:05	0|sipa|the last release i did was 0.3.23
547 2016-08-18 20:15:02	0|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. :(
548 2016-08-18 20:15:08	0|gmaxwell|Among the other things I wanted to say was this:
549 2016-08-18 20:15:10	0|gmaxwell|Kanzure, achow101. Regarding your public comments on the bitcoin.org notice.
550 2016-08-18 20:15:14	0|gmaxwell|https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/d6m1oqu
551 2016-08-18 20:15:17	0|gmaxwell|https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw
552 2016-08-18 20:15:20	0|gmaxwell|I think you've taken the wrong position, by pounding on process.
553 2016-08-18 20:15:22	0|gmaxwell|If someone with privleged access is aware of a serious concern and believes
554 2016-08-18 20:15:25	0|gmaxwell|they urgently need to tkae unilateral action to make a minimal statement
555 2016-08-18 20:15:28	0|gmaxwell|simply to _notify_ people of the risk and encourage following an existing
556 2016-08-18 20:15:31	0|gmaxwell|process to mitigate, they should do so. Pounding on procedure comes across
557 2016-08-18 20:15:34	0|gmaxwell|as a denial which I don't believe you had the information to make.
558 2016-08-18 20:15:37	0|gmaxwell|(and in fact, since achow101 did not talk to all the major developers, I
559 2016-08-18 20:15:40	0|gmaxwell|_know_ you didn't have the information needed to make the claim you made.)
560 2016-08-18 20:15:43	0|gmaxwell|And yes, someone doing something like that unilaterally is going to cause
561 2016-08-18 20:15:46	0|gmaxwell|some pain. But that is okay, the security process should favor risk
562 2016-08-18 20:15:48	0|gmaxwell|reduction, over creating a bit of pain here and there.
563 2016-08-18 20:15:51	0|gmaxwell|[In fact, both of your messages could come across as expressing the view
564 2016-08-18 20:15:54	0|gmaxwell|that we are skeptical that HTTPS MITM attacks are even a risk, when in fact
565 2016-08-18 20:15:57	0|gmaxwell|we _know_ they are well documented to happen with some regularity.]
566 2016-08-18 20:15:59	0|gmaxwell|We are at no real risk of tiring people out with a flood of false positives,
567 2016-08-18 20:16:02	0|gmaxwell|otherwise I would take a different position, perhaps.
568 2016-08-18 20:16:05	0|gmaxwell|Cobra isn't great at public relations, sure, but I notice none of the people
569 2016-08-18 20:16:08	0|gmaxwell|complaining opened PRs to improve the language. His notice states the
570 2016-08-18 20:16:10	0|gmaxwell|concern, the believed targets, and contains specific, conservative,
571 2016-08-18 20:16:13	0|gmaxwell|mitigation instructions, it could be a lot worse.
572 2016-08-18 20:24:07	0|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.
573 2016-08-18 20:25:03	0|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.
574 2016-08-18 20:26:11	0|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. :)
575 2016-08-18 20:31:13	0|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.
576 2016-08-18 21:05:01	0|achow101|gmaxwell: sorry about that. I was mostly reacting against the conspiracy theories and other idiotic claims that r/btc'ers make
577 2016-08-18 21:06:38	0|gmaxwell|yea, that stuff was halarious.
578 2016-08-18 21:07:24	0|kanzure|this seems like a good opportunity to show off a favorite tool of mine, https://mitmproxy.org/
579 2016-08-18 21:09:46	0|kanzure|send to both
580 2016-08-18 21:10:06	0|luke-jr|kanzure: if I knew it was to the old ML, I'd just change it to the new one :P
581 2016-08-18 21:20:02	0|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".
582 2016-08-18 21:20:16	0|cfields|jonasschnelli: i can still PR the id addition to the table though, if you'd like
583 2016-08-18 22:06:01	0|midnightmagic|achow101: :-)
584 2016-08-18 22:52:12	0|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
585 2016-08-18 22:54:09	0|BashCo|mostly focused on encouraging cross referencing keys from multiple sources, as well as signatures from multiple developers.
586 2016-08-18 23:00:50	0|GitHub168|[13bitcoin] 15theuni opened pull request #8542: RFC: net: Pass best block known height into net (06master...06pass-in-height) 02https://github.com/bitcoin/bitcoin/pull/8542
587 2016-08-18 23:25:50	0|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.  :(
588 2016-08-18 23:26:36	0|midnightmagic|Is the money actually stolen?
589 2016-08-18 23:27:48	0|gmaxwell|I believe there address was 1K35Q6BEkCvhE2k7SUeZXKDFTtZACEfNcn and its been cleaned out.
590 2016-08-18 23:28:49	0|BlueMatt|ouch
591 2016-08-18 23:29:12	0|BlueMatt|thats a bunch of cash, too
592 2016-08-18 23:34:57	0|luke-jr|ugh, maybe we need more red lights on the debug window? :/
593 2016-08-18 23:35:57	0|gmaxwell|We could make the dumpprivkey response include a # This is secret data which will allow anyone who knows it to steal your coins.
594 2016-08-18 23:36:12	0|Lauda|+1
595 2016-08-18 23:37:30	0|luke-jr|sounds easier than it probably is. stupid JSON has no comments
596 2016-08-18 23:41:34	0|gmaxwell|I think that RPC doesn't return json?
597 2016-08-18 23:41:47	0|gmaxwell|wait thats dumb, I guess it does.
598 2016-08-18 23:41:49	0|gmaxwell|:-/
599 2016-08-18 23:43:21	0|luke-jr|I suppose we could add some non-standard stuff to UniValue and strip it over real RPC (but not debug console)
600 2016-08-18 23:43:38	0|gmaxwell|ugh. or make the debug console do something special.
601 2016-08-18 23:44:17	0|luke-jr|but there's other unsafe things too - like importprivkey..
602 2016-08-18 23:44:27	0|luke-jr|and a comment couldn't work for that case
603 2016-08-18 23:44:44	0|gmaxwell|Yes, and I've seen someone robbed via that too. But it's less unsafe, I think.
604 2016-08-18 23:45:56	0|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?
605 2016-08-18 23:46:54	0|gmaxwell|lots of pure status things.
606 2016-08-18 23:47:02	0|gmaxwell|getinfo/getchaintips/getmempoolinfo
607 2016-08-18 23:47:53	0|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.
608 2016-08-18 23:48:07	0|luke-jr|signmessage has a proper GUI at least