12016-08-18T00:00:56  *** murch has quit IRC
  22016-08-18T00:01:32  *** FNinTak has quit IRC
  32016-08-18T00:12:12  *** fengling has joined #bitcoin-core-dev
  42016-08-18T00:17:06  *** fengling has quit IRC
  52016-08-18T00:23:13  *** fengling has joined #bitcoin-core-dev
  62016-08-18T00:23:26  *** spudowiar has quit IRC
  72016-08-18T00:28:32  <phantomcircuit> cfields: alrighty then
  82016-08-18T00:28:54  <phantomcircuit> gmaxwell: things have been a bit lax on that front recently actually
  92016-08-18T00:29:10  <phantomcircuit> personally i strongly prefer that each commit in a pr is itself functional
 102016-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
 112016-08-18T00:30:54  <jcorgan> it is nice to have all commits compile nicely to be able to use git bisect
 122016-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
 132016-08-18T00:31:26  <cfields> phantomcircuit: looking at the rpc tests, i'm not seeing how the caches don't stomp eachother
 142016-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
 152016-08-18T00:34:59  *** Samdney has quit IRC
 162016-08-18T00:40:54  *** Megaf has quit IRC
 172016-08-18T00:41:12  *** cryptapus has joined #bitcoin-core-dev
 182016-08-18T00:41:12  *** cryptapus has joined #bitcoin-core-dev
 192016-08-18T00:44:10  <sipa> phantomcircuit: every commit must compile and run tests
 202016-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
 212016-08-18T00:47:06  *** cryptapus has quit IRC
 222016-08-18T00:48:48  *** Chris_Stewart_5 has quit IRC
 232016-08-18T00:52:28  <phantomcircuit> sipa: sure... but there's things where they compile and pass tests and we know them to be broken
 242016-08-18T00:54:58  <sipa> ah, that shouldn't be
 252016-08-18T00:59:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 262016-08-18T01:05:29  *** jrayhawk has joined #bitcoin-core-dev
 272016-08-18T01:10:23  *** Chris_Stewart_5 has quit IRC
 282016-08-18T01:14:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 292016-08-18T01:27:07  *** Alopex has quit IRC
 302016-08-18T01:28:12  *** Alopex has joined #bitcoin-core-dev
 312016-08-18T01:35:52  *** Ylbam has quit IRC
 322016-08-18T01:50:26  *** PaulCapestany has quit IRC
 332016-08-18T01:51:04  *** Chris_Stewart_5 has quit IRC
 342016-08-18T01:52:07  *** PaulCapestany has joined #bitcoin-core-dev
 352016-08-18T02:09:26  *** justanotheruser has quit IRC
 362016-08-18T02:11:04  *** justanotheruser has joined #bitcoin-core-dev
 372016-08-18T02:15:12  *** dstadulis has joined #bitcoin-core-dev
 382016-08-18T02:26:43  *** pero has joined #bitcoin-core-dev
 392016-08-18T02:28:23  *** pero has quit IRC
 402016-08-18T02:32:51  *** jcorgan has quit IRC
 412016-08-18T02:32:51  *** jcorgan has joined #bitcoin-core-dev
 422016-08-18T03:30:11  *** Alopex has quit IRC
 432016-08-18T03:31:16  *** Alopex has joined #bitcoin-core-dev
 442016-08-18T04:11:50  *** btcdrak has joined #bitcoin-core-dev
 452016-08-18T04:12:02  *** Alopex has quit IRC
 462016-08-18T04:13:07  *** Alopex has joined #bitcoin-core-dev
 472016-08-18T04:23:26  *** Alopex has quit IRC
 482016-08-18T04:24:31  *** Alopex has joined #bitcoin-core-dev
 492016-08-18T04:38:21  *** Alopex has quit IRC
 502016-08-18T04:39:26  *** Alopex has joined #bitcoin-core-dev
 512016-08-18T04:42:42  *** kadoban has quit IRC
 522016-08-18T04:59:06  *** Alopex has quit IRC
 532016-08-18T05:00:12  *** Alopex has joined #bitcoin-core-dev
 542016-08-18T05:10:12  *** Alopex has quit IRC
 552016-08-18T05:11:17  *** Alopex has joined #bitcoin-core-dev
 562016-08-18T05:23:17  *** Alopex has quit IRC
 572016-08-18T05:24:22  *** Alopex has joined #bitcoin-core-dev
 582016-08-18T05:29:27  *** dstadulis has quit IRC
 592016-08-18T05:34:02  *** Alopex has quit IRC
 602016-08-18T05:35:07  *** Alopex has joined #bitcoin-core-dev
 612016-08-18T06:38:59  <wumpus> travis is extremely broken
 622016-08-18T06:44:02  <GitHub150> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/733035bdb755...a78f95a976de
 632016-08-18T06:44:03  <GitHub150> bitcoin/master fa64306 MarcoFalke: [qa] abandonconflict: Use assert_equal
 642016-08-18T06:44:03  <GitHub150> bitcoin/master a78f95a Wladimir J. van der Laan: Merge #8531: [qa] abandonconflict: Use assert_equal...
 652016-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
 662016-08-18T06:55:01  *** Alopex has quit IRC
 672016-08-18T06:56:06  *** Alopex has joined #bitcoin-core-dev
 682016-08-18T06:57:10  *** BashCo has quit IRC
 692016-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
 702016-08-18T06:59:46  <jonasschnelli> It would require to also produce ECDSA sigs per assets file
 712016-08-18T07:00:08  <jonasschnelli> And store ECDSA pubkeys of each gitian builder in our bitcoin/bitcoin git
 722016-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
 732016-08-18T07:00:34  <wumpus> yes
 742016-08-18T07:01:02  <wumpus> a user friendly gitian verifyer could be useful
 752016-08-18T07:01:32  <jonasschnelli> Built into an already verified binary would be nice
 762016-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
 772016-08-18T07:02:08  <jonasschnelli> Once you have verified with the gitian-verifier, you have a trusted chain of updates
 782016-08-18T07:02:21  <jonasschnelli> Yes. Could be seperated...
 792016-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
 802016-08-18T07:02:37  <jonasschnelli> but should be built from the git repo where the ECDSA pubkeys are and also built over gitian
 812016-08-18T07:03:04  <wumpus> jonasschnelli: agreed
 822016-08-18T07:03:33  <wumpus> jcorgan: does that improve security? attackers can just as easily include a link to the previous signature
 832016-08-18T07:04:16  <GitHub31> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a78f95a976de...671fdae5f5b3
 842016-08-18T07:04:17  <GitHub31> bitcoin/master fa0afde MarcoFalke: [travis] Drop java
 852016-08-18T07:04:17  <GitHub31> bitcoin/master 671fdae Wladimir J. van der Laan: Merge #8534: [travis] Drop java...
 862016-08-18T07:04:29  <GitHub13> [bitcoin] laanwj closed pull request #8534: [travis] Drop java (master...Mf1608-qaJava) https://github.com/bitcoin/bitcoin/pull/8534
 872016-08-18T07:05:45  <jcorgan> sure. it would just demonstrate an unbroken chain of release binaries, for those willing to verify current vs. prior.
 882016-08-18T07:06:04  <jcorgan> admittedly, that seems like a very few people nowadays.
 892016-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
 902016-08-18T07:11:36  <jcorgan> hard to ensure other's choices, only possible to give them the information needed to make good ones
 912016-08-18T07:13:02  <wumpus> the segwit.py test is very broken in travis
 922016-08-18T07:13:39  <wumpus> somehow not locally though
 932016-08-18T07:15:26  <btcdrak> wumpus: travis randomly fails tests atm
 942016-08-18T07:15:47  <wumpus> random tests?
 952016-08-18T07:16:13  <btcdrak> look at jl2012 PR yesterday https://travis-ci.org/bitcoin/bitcoin/builds/153047455
 962016-08-18T07:16:41  <wumpus> that's also segwit.py failing
 972016-08-18T07:16:45  <btcdrak> the same build fails different tests
 982016-08-18T07:16:56  <wumpus> and txn_doublespend
 992016-08-18T07:17:08  <wumpus> looks like I reported the issue correct then here https://github.com/bitcoin/bitcoin/issues/8532
1002016-08-18T07:17:32  <jl2012> I suspect that's related to the low s patch by sipa
1012016-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"
1022016-08-18T07:17:44  <wumpus> according to cfields
1032016-08-18T07:17:55  <sipa> that failing segwit test was introduced in #8489 iirc
1042016-08-18T07:18:04  *** BashCo has joined #bitcoin-core-dev
1052016-08-18T07:18:25  <btcdrak> i think Cory nailed it
1062016-08-18T07:18:36  <jl2012> Without his patch, bip164-p2p.py will fail
1072016-08-18T07:19:20  <sipa> btcdrak, wumpus: but if shorter delays trigger errors, the tests are wrong
1082016-08-18T07:19:30  <sipa> they shouldn't rely on timings
1092016-08-18T07:19:43  *** MarcoFalke has joined #bitcoin-core-dev
1102016-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
1112016-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
1122016-08-18T07:21:34  <wumpus> the alternative would be temporarily disabling them in travis
1132016-08-18T07:21:54  <jl2012> By the way, they never fail on my mac
1142016-08-18T07:21:54  <wumpus> but I prefer reverting the timeout change to that, as at least something gets tested then
1152016-08-18T07:22:01  <wumpus> jl2012: I can't reproduce it locally either
1162016-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
1172016-08-18T07:22:49  *** Lysanders has joined #bitcoin-core-dev
1182016-08-18T07:23:55  <GitHub68> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/35f64e45c207960078eef58ccc50d91e4abc2c55
1192016-08-18T07:23:55  <GitHub68> bitcoin/master 35f64e4 Wladimir J. van der Laan: Revert "[qa] Adjust timeouts for micro-optimization of run time"...
1202016-08-18T07:29:37  <MarcoFalke> Thanks
1212016-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
1222016-08-18T07:45:01  *** arowser has quit IRC
1232016-08-18T08:08:27  *** Ylbam has joined #bitcoin-core-dev
1242016-08-18T08:16:47  *** Giszmo has joined #bitcoin-core-dev
1252016-08-18T08:31:18  *** Guyver2 has joined #bitcoin-core-dev
1262016-08-18T09:25:58  *** Guyver2_ has joined #bitcoin-core-dev
1272016-08-18T09:28:56  *** Guyver2 has quit IRC
1282016-08-18T09:29:01  *** Guyver2_ is now known as Guyver2
1292016-08-18T09:30:18  *** JZA has quit IRC
1302016-08-18T09:47:10  *** rubensayshi has joined #bitcoin-core-dev
1312016-08-18T10:20:28  *** laurentmt has joined #bitcoin-core-dev
1322016-08-18T10:21:17  *** laurentmt has quit IRC
1332016-08-18T10:26:32  *** moli has quit IRC
1342016-08-18T10:41:41  *** harrymm has quit IRC
1352016-08-18T10:50:37  *** MarcoFalke has left #bitcoin-core-dev
1362016-08-18T10:57:52  *** harrymm has joined #bitcoin-core-dev
1372016-08-18T11:13:21  *** harrymm has quit IRC
1382016-08-18T11:24:29  <GitHub88> [bitcoin] mcccs opened pull request #8537: Trivial: little typos (master...litttle-typos) https://github.com/bitcoin/bitcoin/pull/8537
1392016-08-18T11:29:27  *** harrymm has joined #bitcoin-core-dev
1402016-08-18T11:42:32  *** harrymm has quit IRC
1412016-08-18T11:54:05  <GitHub188> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/35f64e45c207...8250de13587e
1422016-08-18T11:54:06  <GitHub188> bitcoin/master b213535 Wladimir J. van der Laan: Squashed 'src/secp256k1/' changes from 6c527ec..7a49cac...
1432016-08-18T11:54:06  <GitHub188> bitcoin/master 0237096 Wladimir J. van der Laan: Merge commit 'b2135359b3ad37cf2ac09b008079ddb237eff2c9'
1442016-08-18T11:54:07  <GitHub188> bitcoin/master 8250de1 Pieter Wuille: Merge #8453: Bring secp256k1 subtree up to date with master...
1452016-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
1462016-08-18T12:01:53  *** harrymm has joined #bitcoin-core-dev
1472016-08-18T12:06:34  *** AaronvanW has quit IRC
1482016-08-18T12:25:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1492016-08-18T12:25:52  *** Ylbam has quit IRC
1502016-08-18T12:33:27  *** YOU-JI has joined #bitcoin-core-dev
1512016-08-18T12:36:32  *** Chris_Stewart_5 has quit IRC
1522016-08-18T12:46:26  *** fengling has quit IRC
1532016-08-18T12:47:58  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1542016-08-18T12:58:38  *** YOU-JI_ has joined #bitcoin-core-dev
1552016-08-18T12:58:44  *** kadoban has joined #bitcoin-core-dev
1562016-08-18T12:59:52  *** YOU-JI has quit IRC
1572016-08-18T13:03:29  *** YOU-JI_ has quit IRC
1582016-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
1592016-08-18T13:06:28  *** AaronvanW has joined #bitcoin-core-dev
1602016-08-18T13:10:50  *** JZA has joined #bitcoin-core-dev
1612016-08-18T13:14:27  *** Ylbam has joined #bitcoin-core-dev
1622016-08-18T13:22:13  *** moli has joined #bitcoin-core-dev
1632016-08-18T13:43:29  *** fengling has joined #bitcoin-core-dev
1642016-08-18T13:47:46  *** fengling has quit IRC
1652016-08-18T14:07:39  *** arubi has quit IRC
1662016-08-18T14:09:29  *** arubi has joined #bitcoin-core-dev
1672016-08-18T14:23:09  *** laurentmt has joined #bitcoin-core-dev
1682016-08-18T14:24:01  *** Chris_Stewart_5 has quit IRC
1692016-08-18T14:25:31  *** TomMc has joined #bitcoin-core-dev
1702016-08-18T14:25:39  *** laurentmt has quit IRC
1712016-08-18T14:31:31  <GitHub121> [bitcoin] mcccs closed pull request #8537: Trivial: little typos (master...litttle-typos) https://github.com/bitcoin/bitcoin/pull/8537
1722016-08-18T14:32:07  *** cryptapus has joined #bitcoin-core-dev
1732016-08-18T14:32:19  *** rubensayshi has quit IRC
1742016-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
1752016-08-18T14:43:16  <jl2012> probably because your patch takes longer to sign and it timeouts?
1762016-08-18T14:44:14  *** fengling has joined #bitcoin-core-dev
1772016-08-18T14:49:06  *** fengling has quit IRC
1782016-08-18T14:50:31  <jl2012> i think your patch double the signing time on average; and could take much longer with bad luck
1792016-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
1802016-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
1812016-08-18T15:03:11  *** Kexkey has joined #bitcoin-core-dev
1822016-08-18T15:07:00  *** rubensayshi has joined #bitcoin-core-dev
1832016-08-18T15:20:22  *** BashCo has quit IRC
1842016-08-18T15:22:30  *** mkarrer has quit IRC
1852016-08-18T15:29:38  *** mkarrer has joined #bitcoin-core-dev
1862016-08-18T15:36:15  *** zerobit has joined #bitcoin-core-dev
1872016-08-18T15:40:31  *** BashCo has joined #bitcoin-core-dev
1882016-08-18T15:45:45  *** fengling has joined #bitcoin-core-dev
1892016-08-18T15:47:03  *** aalex has quit IRC
1902016-08-18T15:48:19  *** billotronic has joined #bitcoin-core-dev
1912016-08-18T15:50:46  *** fengling has quit IRC
1922016-08-18T15:58:12  *** jujumax has joined #bitcoin-core-dev
1932016-08-18T16:06:34  *** TomMc has quit IRC
1942016-08-18T16:09:28  *** zooko has joined #bitcoin-core-dev
1952016-08-18T16:19:32  *** spudowiar has joined #bitcoin-core-dev
1962016-08-18T16:20:08  *** JZA has quit IRC
1972016-08-18T16:29:41  <cfields> jonasschnelli: ping. what's the easiest way to atomically retrieve the NodeId for the selected row in the peertable?
1982016-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
1992016-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.
2002016-08-18T16:41:25  *** rubensayshi has quit IRC
2012016-08-18T16:42:58  *** MarcoFalke has joined #bitcoin-core-dev
2022016-08-18T16:46:05  *** aalex has joined #bitcoin-core-dev
2032016-08-18T16:47:18  *** fengling has joined #bitcoin-core-dev
2042016-08-18T16:52:06  *** fengling has quit IRC
2052016-08-18T16:56:00  *** GreenIsMyPepper has quit IRC
2062016-08-18T16:56:08  *** GreenIsMyPepper has joined #bitcoin-core-dev
2072016-08-18T17:02:53  *** TomMc has joined #bitcoin-core-dev
2082016-08-18T17:08:23  <btcdrak> Regarding MS/APPL codesigning certificates. What about getting one issued in the name of MIT DCI?
2092016-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
2102016-08-18T17:22:32  *** jujumax has quit IRC
2112016-08-18T17:31:20  *** adiabat has quit IRC
2122016-08-18T17:31:39  *** aalex_ has joined #bitcoin-core-dev
2132016-08-18T17:34:09  *** aalex has quit IRC
2142016-08-18T17:38:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2152016-08-18T17:40:19  *** aalex_ has quit IRC
2162016-08-18T17:40:26  *** aalex has joined #bitcoin-core-dev
2172016-08-18T17:48:48  *** fengling has joined #bitcoin-core-dev
2182016-08-18T17:53:46  *** fengling has quit IRC
2192016-08-18T18:02:36  *** laurentmt has joined #bitcoin-core-dev
2202016-08-18T18:02:41  *** laurentmt has quit IRC
2212016-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
2222016-08-18T18:06:04  <Chris_Stewart_5> isn't this conflicting?
2232016-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
2242016-08-18T18:10:55  <sipa> Chris_Stewart_5: if you have *two* subnodes, their hashes should be different
2252016-08-18T18:11:27  <sipa> because if that was the case, it would be indistinguishable from the case where there was only one subnode
2262016-08-18T18:21:24  *** aalex has quit IRC
2272016-08-18T18:27:32  <jonasschnelli> cfields: could you solve the Qt table nodeid problem?
2282016-08-18T18:38:37  *** molz has joined #bitcoin-core-dev
2292016-08-18T18:41:09  *** moli has quit IRC
2302016-08-18T18:41:22  <cfields> jonasschnelli: no further along, wanted to get your preferred approach first
2312016-08-18T18:41:39  <jonasschnelli> okay... let me have a loog
2322016-08-18T18:41:41  <jonasschnelli> look
2332016-08-18T18:42:31  <cfields> jonasschnelli: great, thanks
2342016-08-18T18:42:58  <cfields> jonasschnelli: i can point you to my changes, if you'll promise to ignore the stuff happening around it :)
2352016-08-18T18:43:13  <cfields> (i'm trying to break out this part for its own PR)
2362016-08-18T18:43:53  *** molly has joined #bitcoin-core-dev
2372016-08-18T18:44:45  <cfields> jonasschnelli: my attempt: https://github.com/theuni/bitcoin/commit/cfc8f2b6533e241258167af0da966cbe2e5e4d10#diff-a9100e8bfc1122159ae47eb2d2f3e6cf
2382016-08-18T18:44:50  *** laurentmt has joined #bitcoin-core-dev
2392016-08-18T18:45:55  <jonasschnelli> cfields: I like your approach,.. I just wanted to propose the same thing.
2402016-08-18T18:46:19  <jonasschnelli> maybe rename PeerTableModel::Id to PeerTableModel::NodeId
2412016-08-18T18:46:33  <cfields> jonasschnelli: ah, great. I'll break it out and PR then. Thanks!
2422016-08-18T18:46:34  <jonasschnelli> Id seems to generic (could imply a table row id or somethig)
2432016-08-18T18:46:36  <cfields> sure
2442016-08-18T18:46:45  <cfields> yes, makes sense
2452016-08-18T18:47:09  *** molz has quit IRC
2462016-08-18T18:50:26  *** fengling has joined #bitcoin-core-dev
2472016-08-18T18:50:39  *** JackH has quit IRC
2482016-08-18T18:52:07  <cfields> jonasschnelli: hmm, is there still a need for mapNodeRows, then?
2492016-08-18T18:52:42  <cfields> (I have no clue how fast searching rows is)
2502016-08-18T18:52:48  <jonasschnelli> depends if you still call int detailNodeRow = clientModel->getPeerTableModel()->getRowByNodeId(cachedNodeid);
2512016-08-18T18:53:11  <jonasschnelli> which is the "invers" function of row->nodeId
2522016-08-18T18:53:25  <jonasschnelli> it's nodeid->row
2532016-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?
2542016-08-18T18:55:09  <jonasschnelli> Not sure how performant a iteration over all rows could be in a 128 connection situation
2552016-08-18T18:55:11  <cfields> or am i oversimplifying that?
2562016-08-18T18:55:19  <jonasschnelli> Maybe keep the map for now.
2572016-08-18T18:55:22  <cfields> ok, np. will keep it
2582016-08-18T18:55:23  <jonasschnelli> Can be evicted later
2592016-08-18T18:55:26  *** fengling has quit IRC
2602016-08-18T18:56:25  <sipa> connection count can go up to 900 or so if you raise maxconnections
2612016-08-18T18:57:33  *** Cory has quit IRC
2622016-08-18T18:57:38  <jonasschnelli> Indeed...
2632016-08-18T18:57:50  *** JZA has joined #bitcoin-core-dev
2642016-08-18T18:58:12  <jonasschnelli> removing the map would probably require someone to test the performance in a 900connection environment...
2652016-08-18T18:58:34  <sipa> i expect it to still be perfectly fine
2662016-08-18T18:58:47  *** laurentmt has quit IRC
2672016-08-18T18:59:55  <btcdrak> meeting time
2682016-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)
2692016-08-18T19:00:01  <MarcoFalke> meeting time!
2702016-08-18T19:00:02  <sipa> *ding*
2712016-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
2722016-08-18T19:00:16  <wumpus> #meetingstart
2732016-08-18T19:00:18  <kanzure> how do i know the ping is the real ping?
2742016-08-18T19:00:19  <wumpus> #startmeeting
2752016-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.
2762016-08-18T19:00:19  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2772016-08-18T19:00:39  <jonasschnelli> proposed topic: core internal binary signing and verification tool
2782016-08-18T19:00:40  <sipa> kanzure: its twitter handle is therealping
2792016-08-18T19:00:45  <wumpus> kanzure: it comes from gmaxwell, who the offical meeting-pinger, and he is authenticated with freenode
2802016-08-18T19:01:11  <btcdrak> how do we know freenode is still free?
2812016-08-18T19:01:30  <wumpus> because otherwise it would be renamed to restrictednode
2822016-08-18T19:01:32  <luke-jr> jonasschnelli: a tool would be nice, but there is no reason for it to be internal
2832016-08-18T19:01:40  <jonasschnelli> there are
2842016-08-18T19:01:50  <jonasschnelli> (to be covered under gitian)
2852016-08-18T19:01:57  <wumpus> #topic core internal binary signing and verification tool
2862016-08-18T19:02:01  <luke-jr> you can gitian-build things besides Bitcoin
2872016-08-18T19:02:21  *** Cory has joined #bitcoin-core-dev
2882016-08-18T19:02:26  <jonasschnelli> I propose to add to cli tools to the bitcoin-core package
2892016-08-18T19:02:34  <kanzure> off-topic, but does anyone know the status of deterministic debian efforts?
2902016-08-18T19:02:34  <jonasschnelli> bitcoin-core-verify and bitcoin-core-sign
2912016-08-18T19:02:44  <jonasschnelli> The later will not be shipped
2922016-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)
2932016-08-18T19:02:51  <jonasschnelli> bitcoin-core-verify will list valid signatues of devs by listing devs name.
2942016-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
2952016-08-18T19:02:57  <btcdrak> jonasschnelli I think it needs to be GUI for wider adoption.
2962016-08-18T19:03:07  <jonasschnelli> Yes. It would be a Qt tool for one major reason
2972016-08-18T19:03:08  <gmaxwell> Please don't do design in the meeting.
2982016-08-18T19:03:10  <jonasschnelli> https downloads
2992016-08-18T19:03:23  *** harrymm has quit IRC
3002016-08-18T19:03:25  <jonasschnelli> gmaxwell: okay. fair enought...
3012016-08-18T19:03:29  <gmaxwell> I'm planning on having someone work on that.
3022016-08-18T19:03:49  <btcdrak> jonas is already building something afaik
3032016-08-18T19:03:51  <wumpus> yes it needs https support to get at the signatures from github
3042016-08-18T19:03:56  <jonasschnelli> Yes. But happy to pause.
3052016-08-18T19:04:06  <gmaxwell> If it does https I will nak it so hard keys will fall  of the keyboard.
3062016-08-18T19:04:07  <jonasschnelli> Qt would have https support built in
3072016-08-18T19:04:21  <jonasschnelli> the gitian sigs come over https
3082016-08-18T19:04:22  <gmaxwell> We _cannot_ ship some downloading tool that is going to require frequent CVEs itself.
3092016-08-18T19:04:27  <wumpus> it's not a downloading tool
3102016-08-18T19:04:28  <jonasschnelli> either with git or with https
3112016-08-18T19:04:29  <MarcoFalke> So how do you verify bitcoin-core-verify?
3122016-08-18T19:04:30  <wumpus> just a verification tool
3132016-08-18T19:04:41  <wumpus> MarcoFalke: it'd be part of the distribution
3142016-08-18T19:04:45  <btcdrak> no need for https when you have cryptographic verification
3152016-08-18T19:04:51  <gmaxwell> What btcdrak said.
3162016-08-18T19:04:58  <jonasschnelli> I guess even if https is broken, nobody can upload valid EC sigs
3172016-08-18T19:05:05  <btcdrak> https _is_ broken
3182016-08-18T19:05:12  <jonasschnelli> https is required to download from github I guess
3192016-08-18T19:05:16  <wumpus> well if you can get information from github through http that would work too
3202016-08-18T19:05:39  <jonasschnelli> Yes. TLS is not required for security.
3212016-08-18T19:05:46  <luke-jr> the git protocol isn't encrypted I think
3222016-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
3232016-08-18T19:05:59  <wumpus> you seriously wouldn't want to implement the git protocol
3242016-08-18T19:06:02  <cfields> wumpus: distribution == our release? Or OS?
3252016-08-18T19:06:10  <jonasschnelli> he. yes. no git:// please
3262016-08-18T19:06:10  <wumpus> cfields: yes, our releases
3272016-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
3282016-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
3292016-08-18T19:06:57  <jonasschnelli> somewhere where it could be used in cpp source code (probably in a header)
3302016-08-18T19:07:24  <wumpus> well the gpg keys are already in the respository
3312016-08-18T19:07:25  <jonasschnelli> this would allow to build a "trusted-chain" of bitcoin-core binaries
3322016-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?
3332016-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.
3342016-08-18T19:07:44  <jonasschnelli> cfields: Sure. Thats always possible
3352016-08-18T19:07:54  <btcdrak> just confirmed github forces https redirection
3362016-08-18T19:07:58  <MarcoFalke> So bitcoin-core-verify checks the release, but is part of the release... Isn't this circular?
3372016-08-18T19:07:58  <wumpus> cfields: yes, it only works for chaining, if the first link in the chain is broken it solves nothing...
3382016-08-18T19:08:05  <jonasschnelli> But not if you have verified the first download (assume with gitian verify), then verify with the new tool
3392016-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.
3402016-08-18T19:08:14  <wumpus> MarcoFalke: it'd be used to check the *next* release downloaded
3412016-08-18T19:08:32  <kanzure> bikeshedding for a sec, but "next" seems important enough to be part of the name ;)
3422016-08-18T19:08:33  <jonasschnelli> people could still gitian-verify our new verification tool
3432016-08-18T19:08:36  <wumpus> MarcoFalke: having it verify itself would be sillly
3442016-08-18T19:08:37  <cfields> right.
3452016-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 :) )
3462016-08-18T19:08:47  <MarcoFalke> ok, I see
3472016-08-18T19:08:55  <kanzure> s/compromised/revoked?
3482016-08-18T19:09:00  <kanzure> +revoked, at least?
3492016-08-18T19:09:16  <cfields> kanzure: +1. that wasn't clear to me until now :)
3502016-08-18T19:09:17  <jonasschnelli> key revoking is possible over our release-management
3512016-08-18T19:09:23  <wumpus> kanzure: well it be N-out-of-M ,so could tolerate some revoked or compromised keys Iguess..
3522016-08-18T19:09:26  <gmaxwell> kanzure: without an uncensorable communications medium or expiration there is no sense for revocation.
3532016-08-18T19:09:33  <kanzure> hm.
3542016-08-18T19:09:41  <wumpus> then they'd just be removed in the next release
3552016-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.
3562016-08-18T19:10:25  <gmaxwell> n of m is close to an uncensorable communicatoins medium subject to an honest threshold assumption.
3572016-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
3582016-08-18T19:10:32  <btcdrak> gmaxwell: what if you got a good release, but were later infected with malware which changed the verifier tool?
3592016-08-18T19:10:43  <gmaxwell> btcdrak: oh well.
3602016-08-18T19:10:50  <wumpus> btcdrak: if you are infected, it's end of story really
3612016-08-18T19:10:53  *** skyraider has joined #bitcoin-core-dev
3622016-08-18T19:10:55  <wumpus> btcdrak: it can already steal your coins
3632016-08-18T19:10:55  <jonasschnelli> indeed
3642016-08-18T19:10:55  <gmaxwell> btcdrak: if you're infected with malware you're hosed at that point.
3652016-08-18T19:10:57  <sipa> btcdrak: you are eaten by a frue
3662016-08-18T19:11:00  <sipa> *grue
3672016-08-18T19:11:03  <jonasschnelli> you can't protect from malware on that layer
3682016-08-18T19:11:11  <kanzure> perhaps the malware would be kind enough to at least inform you of your infection
3692016-08-18T19:11:17  *** aalex has joined #bitcoin-core-dev
3702016-08-18T19:11:20  <wumpus> that's another story entirely (hardaware wallets / security modules)
3712016-08-18T19:11:20  <jonasschnelli> impossible
3722016-08-18T19:11:47  <jonasschnelli> At least, the EC binary sig tool would allow hardware wallets to sign the binaries
3732016-08-18T19:11:53  *** anchow101 has joined #bitcoin-core-dev
3742016-08-18T19:11:58  <wumpus> that's an interesting idea
3752016-08-18T19:12:03  <jonasschnelli> (though you can do this with GPG smartcard)
3762016-08-18T19:12:13  <wumpus> there are smartcards running GPG?
3772016-08-18T19:12:20  <jonasschnelli> Yes.
3782016-08-18T19:12:22  <wumpus> is there some micro-gpg implementation?
3792016-08-18T19:12:22  <btcdrak> yes
3802016-08-18T19:12:34  <jonasschnelli> but a big mess
3812016-08-18T19:12:39  <gmaxwell> A number of people around here use gpg via yubikey3.
3822016-08-18T19:12:39  <wumpus> yeah...
3832016-08-18T19:12:41  <btcdrak> petertodd has one with pin entry. sounds like he's at the cash register when sending emails
3842016-08-18T19:12:50  <gmaxwell> wumpus: it's not really gpg on the smartcard, it's a rsa signer on a stick. :)
3852016-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
3862016-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
3872016-08-18T19:13:52  <instagibbs> btcdrak, I have a pgp key from mine
3882016-08-18T19:14:04  <instagibbs> (just playing around with it)
3892016-08-18T19:14:19  <gmaxwell> There is a terrible complex standard for supporting it. In any case, it's a good thing to have.
3902016-08-18T19:14:21  *** yep444 has joined #bitcoin-core-dev
3912016-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...
3922016-08-18T19:14:47  <kanzure> should we move on?
3932016-08-18T19:14:49  <wumpus> anyhow, I think we agree that we'd want to use secp256k1 signatures
3942016-08-18T19:14:55  <wumpus> if we can agree on one thing
3952016-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.
3962016-08-18T19:15:14  <jonasschnelli> Okay. I'll work on a short design and post it to bitcoin-core-dev ML
3972016-08-18T19:15:29  <wumpus> btcdrak: I just use old computers, but I agree that's the more practical option :-)
3982016-08-18T19:15:34  <kanzure> should we be complaining about hkp to the bitcoin.org people?
3992016-08-18T19:15:44  <gmaxwell> jonasschnelli: can you spend some time and talk to mr or sipa before you post?
4002016-08-18T19:16:03  <jonasschnelli> gmaxwell: Yes. Will do... thanks for offering that.
4012016-08-18T19:16:35  <wumpus> kanzure: hkp?
4022016-08-18T19:17:19  <kanzure> HPKP
4032016-08-18T19:17:52  <kanzure> public key pinning
4042016-08-18T19:17:58  *** harrymm has joined #bitcoin-core-dev
4052016-08-18T19:18:18  <btcdrak> they also dont enforce HSTS
4062016-08-18T19:18:29  <kanzure> does bitcoincore.org?
4072016-08-18T19:18:32  <btcdrak> yes
4082016-08-18T19:18:35  <kanzure> both?
4092016-08-18T19:18:36  <jonasschnelli> Another short topic proposal that is near to the signing: code-signing (OSX/WIN).
4102016-08-18T19:18:48  <wumpus> sure, why not, if anything can be done to improve site security we should encourag that
4112016-08-18T19:19:00  <btcdrak> no, just HSTS and certificate origin
4122016-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.
4132016-08-18T19:20:02  <btcdrak> sorry, i mean authenticated origin pulls
4142016-08-18T19:20:25  <btcdrak> HSTS is important to prevent https downgrade attacks imo
4152016-08-18T19:20:27  <kanzure> okay well i'm eagerly awaiting for the delivery of the complimentary ips containers
4162016-08-18T19:20:35  <wumpus> yes, HSTS is important, and trivial to implement
4172016-08-18T19:20:57  <wumpus> never even heard of HPKP before
4182016-08-18T19:21:09  <kanzure> jonasschnelli: iirc there was some detail about code signing and windows - something about a buggy state?
4192016-08-18T19:21:17  <kadoban> HPKP is key-pinning. It's to prevent attacks like rogue CAs
4202016-08-18T19:21:21  <wumpus> #topic code-signing (OSX/WIN)
4212016-08-18T19:21:32  <jonasschnelli> We still sign with "Bitcoin Foundation"
4222016-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.
4232016-08-18T19:21:42  <jonasschnelli> On OSX, its not very visible... on Windows I guess a bit more.
4242016-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
4252016-08-18T19:22:04  <jonasschnelli> Question: we should try to get new certificates for OSX/Win in the name of "Bitcoin Core".
4262016-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.)
4272016-08-18T19:22:20  <jonasschnelli> The question is, if we should. :)
4282016-08-18T19:22:23  <instagibbs> jonasschnelli, that's a statement :P
4292016-08-18T19:22:27  <btcdrak> jonaschnelli: that would be great. do you have a company that can do it?
4302016-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.
4312016-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
4322016-08-18T19:22:34  <wumpus> btcdrak: sure, I could paste sha256sums.asc into the announcement email
4332016-08-18T19:22:39  <luke-jr> jonasschnelli: cfields was looking into this, but I am not sure his status
4342016-08-18T19:22:47  <kadoban> Like, your website is unusable for 6 months screwed.
4352016-08-18T19:22:47  <btcdrak> wumpus: thank you.
4362016-08-18T19:22:57  <wumpus> kadoban: right - what if you want to switch CAs for some reason
4372016-08-18T19:23:16  <wumpus> #action sha256sums in release email
4382016-08-18T19:23:19  <jonasschnelli> btcdrak: I have serval code signing certificates.. but we don't want to use these company names...
4392016-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.
4402016-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)
4412016-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
4422016-08-18T19:23:36  <wumpus> (do note that release emails are signed with *my* key, not the release signing key)
4432016-08-18T19:23:59  <sipa> sorry i fell asleep
4442016-08-18T19:24:47  <gmaxwell> Thats a sign to move on. :)
4452016-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
4462016-08-18T19:25:06  <instagibbs> brainstorming can continue later imo
4472016-08-18T19:25:08  <kanzure> wasn't github sunsetting hosted release binaries?
4482016-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
4492016-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
4502016-08-18T19:25:29  <luke-jr> kanzure: I think they re-introduced them
4512016-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)
4522016-08-18T19:25:48  <wumpus> yes, github has the option to host release binaries
4532016-08-18T19:25:53  <kanzure> luke-jr: got it
4542016-08-18T19:26:04  <wumpus> but having the binaries in more places means more places to check wether they are compromised too
4552016-08-18T19:26:05  <anchow101> Why not host binaries on GitHub and move completely off of bitcoin.orgs system
4562016-08-18T19:26:16  <btcdrak> wumpus: we should do it there as a mirror at least.
4572016-08-18T19:26:25  <wumpus> also it gives another reason to want to compromise our github
4582016-08-18T19:26:59  * jonasschnelli is not sure if we should place the binaries on the same host at the source code
4592016-08-18T19:27:00  <wumpus> I'm not comfortable with everyting in one place
4602016-08-18T19:27:15  <sipa> let's use sourceforge *ducks*
4612016-08-18T19:27:16  <wumpus> yea, exactly, feels like putting a lot of eggs inone basket
4622016-08-18T19:27:20  <wumpus> hah
4632016-08-18T19:27:23  * jonasschnelli stabs sipa 
4642016-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.
4652016-08-18T19:27:29  <gmaxwell> you don't think github isn't fully compromised already, come one? :)
4662016-08-18T19:27:34  <gmaxwell> er come on
4672016-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.
4682016-08-18T19:27:54  <wumpus> well at least sudden code changes are fairly detectable
4692016-08-18T19:28:07  <wumpus> (and we sign all top-level commits)
4702016-08-18T19:28:16  <gmaxwell> please can we move on?
4712016-08-18T19:28:18  <anchow101> What about Amazon s3 for binary hosting?
4722016-08-18T19:28:18  <wumpus> so there is very little gain in compromising our github right now
4732016-08-18T19:28:19  <btcdrak> The issue is less about being compromised and more about early warning.
4742016-08-18T19:28:30  <wumpus> any other topics?
4752016-08-18T19:28:41  <instagibbs> 0.13.0 final?
4762016-08-18T19:28:42  <sipa> 0.13.0?
4772016-08-18T19:28:45  <btcdrak> having multiple places makes it more likely a compromise would be spotted earlier
4782016-08-18T19:29:02  <wumpus> btcdrak:  I disagree; it doesn't solve the problem of peopel not verifying at all
4792016-08-18T19:29:07  <wumpus> #topic 0.13.0
4802016-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.
4812016-08-18T19:29:31  <instagibbs> kanzure, greg told me it was some academic paper's work
4822016-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
4832016-08-18T19:29:35  <MarcoFalke> I think the last doc change was merged. We can start gitian after the meeting?
4842016-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.
4852016-08-18T19:29:54  <MarcoFalke> Or did anyone hear of critical problems?
4862016-08-18T19:30:09  <btcdrak> MarcoFalke: it's all good from what I can see.
4872016-08-18T19:30:17  <gmaxwell> kanzure: I'll provide citations after the meeting.
4882016-08-18T19:30:18  <instagibbs> there was one report of stalled segwit ibd on testnet
4892016-08-18T19:30:20  <sipa> kanzure: https://twitter.com/bcrypt/status/765615853488316416
4902016-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
4912016-08-18T19:30:30  <instagibbs> but not sure if that's one-off or what
4922016-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.
4932016-08-18T19:31:07  <jonasschnelli> wumpus: agree, that was a imprudent move..
4942016-08-18T19:31:07  <sipa> gmaxwell: do you have multiple header chains extending your active branch?
4952016-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/
4962016-08-18T19:31:16  <MarcoFalke> I can upload my 8.5 gig datadir *ducks*
4972016-08-18T19:31:33  <cfields> wumpus: tag it as 0.13.0.1 :)
4982016-08-18T19:31:34  <gmaxwell> sipa: no I've just tried varrious things. I thought we already fixed the big with multiple header chains?
4992016-08-18T19:31:39  <wumpus> cfields: lol :)
5002016-08-18T19:31:49  <sipa> gmaxwell: i thought so too
5012016-08-18T19:31:51  <btcdrak> cfields: lol
5022016-08-18T19:32:05  <instagibbs> gmaxwell, me neither *shrug*
5032016-08-18T19:32:05  <MarcoFalke> Able to reproduce consistently here, but this is something for 13.1
5042016-08-18T19:32:06  <sipa> gmaxwell: but that was something i noticed in MarcoFalke's roc output
5052016-08-18T19:32:16  <sipa> rpc
5062016-08-18T19:32:38  <gmaxwell> MarcoFalke: if you have a sync failure that is reproducably consistently it may be a release blocker.
5072016-08-18T19:32:40  <btcdrak> you mean 0.13.1
5082016-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.
5092016-08-18T19:33:01  <gmaxwell> Please can we stop with the prior topic?
5102016-08-18T19:33:05  <kanzure> okay.
5112016-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
5122016-08-18T19:33:32  * btcdrak has been asking for two weeks....
5132016-08-18T19:33:43  <sipa> btcdrak: i reviewed!
5142016-08-18T19:33:45  <wumpus> yes we're slipping incredibly, for no really good reason, I know
5152016-08-18T19:33:48  <wumpus> I feel bad about it too
5162016-08-18T19:34:00  * btcdrak gives sipa a gold star!
5172016-08-18T19:34:10  <wumpus> oh you mean the blog post, I'll take a look at it
5182016-08-18T19:34:23  <gmaxwell> btcdrak: sorry, I missed that completely, will look.
5192016-08-18T19:34:25  <wumpus> #action review https://github.com/bitcoin-core/bitcoincore.org/pull/199
5202016-08-18T19:34:26  <instagibbs> I'll review today
5212016-08-18T19:35:01  <btcdrak> wumpus: so tag friday evening, and release ~monday?
5222016-08-18T19:35:11  <sipa> sounds fine be me
5232016-08-18T19:35:14  <wumpus> any rationale for friday evening, and not, right now?
5242016-08-18T19:35:21  <sipa> also fine by me
5252016-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?
5262016-08-18T19:35:31  <gmaxwell> I am concerned that we have a reproducable candidate release blocker.
5272016-08-18T19:35:55  <gmaxwell> we should become confident that it's segwit only.
5282016-08-18T19:36:02  <wumpus> bah
5292016-08-18T19:36:08  <btcdrak> wumpus: to give time for the cobra announcement to fade
5302016-08-18T19:36:11  <gmaxwell> perhaps by having marco backup his state, and then disable segwit.
5312016-08-18T19:36:16  <wumpus> I'm about to give up on 0.13 completely :p
5322016-08-18T19:36:25  <wumpus> and focus on 0.14 from now on
5332016-08-18T19:36:26  <sipa> wumpus: what, and release 0
5342016-08-18T19:36:28  <btcdrak> 13 is unlucky number!
5352016-08-18T19:36:31  <sipa> qe.1 instead?
5362016-08-18T19:36:34  <wumpus> btcdrak: yes. exactly.
5372016-08-18T19:36:38  <kanzure> one rationale for not right now is to give time for review on bitcoincore.org pull 199
5382016-08-18T19:36:46  <btcdrak> ^
5392016-08-18T19:36:47  <kanzure> so maybe like... whatever average review time is. heh.
5402016-08-18T19:36:59  <wumpus> gitian building takes time too
5412016-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.
5422016-08-18T19:37:10  <instagibbs> wumpus, skip 0.12.1, go straight to 1.0, come on
5432016-08-18T19:37:12  <wumpus> we can delay the uploading until your blog post is finished, sure
5442016-08-18T19:37:36  <wumpus> instagibbs: skipping numbers doesn't work if we don't feel confident about the code, though
5452016-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.
5462016-08-18T19:37:49  <sipa> gmaxwell: ok, i will prioritize reviewing marco's situation
5472016-08-18T19:38:09  <wumpus> no one else reported it though
5482016-08-18T19:38:21  <wumpus> I've done tons of syncs with this code
5492016-08-18T19:38:23  <gmaxwell> I reported a similar one in the past, but we thought we fixed it.
5502016-08-18T19:38:32  <kanzure> is it reproducible?
5512016-08-18T19:38:36  <MarcoFalke> locally
5522016-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.
5532016-08-18T19:39:00  <wumpus> but ok,anyhow, I guess we'll talk about this topic again next week
5542016-08-18T19:39:12  <gmaxwell> pft.
5552016-08-18T19:39:13  <wumpus> I've given uptrying to push for a release soon
5562016-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?)
5572016-08-18T19:39:22  <sipa> i hope 0.13.0 is released next week
5582016-08-18T19:39:32  <sipa> wumpus: ok, i'll push
5592016-08-18T19:39:34  <MarcoFalke> local on fedora
5602016-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.
5612016-08-18T19:39:42  <jonasschnelli> Do we delay then the final 0.13.0 only because of cobras post?
5622016-08-18T19:39:43  <MarcoFalke> Can we do this trouble shooting after the meeting?
5632016-08-18T19:39:55  <wumpus> sipa: thanks. I'm done being the person chasing people peonting at his watch for one
5642016-08-18T19:40:09  <sipa> wumpus: ok
5652016-08-18T19:40:17  <MarcoFalke> gmaxwell: I never saw it on main
5662016-08-18T19:40:27  <wumpus> so should this delay setting up the release schedule for 0.14?
5672016-08-18T19:40:53  <wumpus> that's kind of in limbo now, too
5682016-08-18T19:40:55  <MarcoFalke> imo no. 0.14 can be less features. less rcs
5692016-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.
5702016-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.
5712016-08-18T19:41:54  <MarcoFalke> wumpus: There is some value in doing releases regular (c.f. firefox)
5722016-08-18T19:42:03  <anchow101> Can someone link me to the issue?
5732016-08-18T19:42:11  <wumpus> we have toruble doing the releases in the currently planne dschedule
5742016-08-18T19:42:18  <wumpus> I don't even want to think about more regular releases
5752016-08-18T19:42:20  <jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8518
5762016-08-18T19:42:39  <sipa> wumpus: i disagree, your pushing to stick to a schedule was very valuable
5772016-08-18T19:42:49  <wumpus> firefox has a completely different situation
5782016-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.
5792016-08-18T19:43:11  <sipa> wumpus: i understand if you're worn out about it, but that does not make it a bad idea
5802016-08-18T19:43:12  <sipa> we are still very close to on schedule for 0.13
5812016-08-18T19:43:27  <jonasschnelli> Yes. Thanks to wumpus'es RC buffer
5822016-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
5832016-08-18T19:43:52  <sipa> so i would vote we schedule 0.14 as soon as 0.13.0 is out
5842016-08-18T19:43:56  <jonasschnelli> I'm normally used to delay of *1.5 in software projects
5852016-08-18T19:44:27  <wumpus> jonasschnelli: agree, it could be much worse :)
5862016-08-18T19:44:39  <sipa> wumpus: it *used to be* much worse
5872016-08-18T19:44:47  <sipa> for us.
5882016-08-18T19:44:47  <jonasschnelli> 6 month seems to be perfectly fine. Just +6 month after the (possible) delayed last release
5892016-08-18T19:44:50  <wumpus> jonasschnelli: then again, we have time-based releases, we don't wait for any feature, just for bug fixes
5902016-08-18T19:45:14  <jonasschnelli> Yes. This seems to follow most agile development practices.
5912016-08-18T19:45:38  <wumpus> in any case, any other topics?
5922016-08-18T19:46:16  <zooko> Do y'all know about "binary transparency"?
5932016-08-18T19:46:25  <jonasschnelli> tell us
5942016-08-18T19:46:33  *** spudowiar has quit IRC
5952016-08-18T19:46:41  <btcdrak> zooko: please explain
5962016-08-18T19:46:42  <zooko> https://groups.google.com/forum/#!forum/binary-transparency
5972016-08-18T19:46:54  <zooko> It's a project from Ben Laurie, as a follow-on to "certificate transparency".
5982016-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.
5992016-08-18T19:47:53  <zooko> When you publish a binary, you submit its hash to these servers.
6002016-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.
6012016-08-18T19:48:24  <jl2012> proposed topic: BIP146.
6022016-08-18T19:48:36  *** gmaxwell has left #bitcoin-core-dev
6032016-08-18T19:48:40  <zooko> This is a detection technique, more than a prevention technique, for people distributing different binaries to different users.
6042016-08-18T19:49:07  <jonasschnelli> example: https://github.com/FreeBSDFoundation/binary-transparency-notes
6052016-08-18T19:49:13  <jl2012> It is proposed to do the LOW_S and NULLDUMMY softfork at the same time as segwit
6062016-08-18T19:50:07  <jonasschnelli> thanks zooko! I think we should take a closer look at the binary-transparency project.
6072016-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
6082016-08-18T19:50:35  <wumpus> #topic BIP146
6092016-08-18T19:50:38  <btcdrak> #link https://github.com/bitcoin/bips/blob/master/bip-0146.mediawiki
6102016-08-18T19:50:47  <warren> (OSX does prevent running unsigned binaries unless the user disables a default option.)
6112016-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.
6122016-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
6132016-08-18T19:51:17  <btcdrak> warren: but anyone can sign.
6142016-08-18T19:51:22  <zooko> But not for preventing people from running the alternate binaries so much, because like you say…
6152016-08-18T19:51:24  <wumpus> (the latter being the point of the binary transparency)
6162016-08-18T19:51:24  <btcdrak> jl2012: speak up
6172016-08-18T19:51:25  <warren> btcdrak: true
6182016-08-18T19:51:28  <jonasschnelli> warren: In which case you fully have to trust apple
6192016-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?)
6202016-08-18T19:51:48  *** fengling has joined #bitcoin-core-dev
6212016-08-18T19:52:10  <sipa> together they would make *normal* transactions free from known malleability in segwit
6222016-08-18T19:53:15  <jl2012> NULLDUMMY is a bigger problem than LOW_S, as an attacker may put anything as the dummy value
6232016-08-18T19:53:41  <sipa> and they are both trivial
6242016-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.
6252016-08-18T19:54:22  <sipa> adam3us, zooko: can you wait until the meeting is ove
6262016-08-18T19:54:32  <kanzure> is the request re: bip146 for more review?
6272016-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
6282016-08-18T19:54:43  <kanzure> what is the request about bip146 about?
6292016-08-18T19:54:54  <sipa> please discuss :)
6302016-08-18T19:55:14  <jonasschnelli> jl2012: Would the NULLDUMMY affect current mainnet transaction
6312016-08-18T19:55:14  <jl2012> LOW_S was discussed in last meeting but not NULLDUMMY
6322016-08-18T19:55:18  <btcdrak> ha! I think we discussed LowS already, it's just the addition of NULLDUMMY that is new.
6332016-08-18T19:55:20  <sipa> do we think it is doable in 0.13.1 / together with segwit
6342016-08-18T19:55:48  <jl2012> jonasschnelli: yes in the current BIP146
6352016-08-18T19:55:49  <btcdrak> sipa: I agree. it is a trivial addition.
6362016-08-18T19:56:35  *** anchow101 has quit IRC
6372016-08-18T19:56:45  <wumpus> yes, ack on LowS already, I don't know enough about NULLDUMMY to usefully comment
6382016-08-18T19:56:46  *** fengling has quit IRC
6392016-08-18T19:56:55  <btcdrak> 4 minute bell
6402016-08-18T19:57:11  <luke-jr> wumpus: NULLDUMMY is just "the ignored value popped by CHECKMULTISIG must be zero"
6412016-08-18T19:57:12  <sipa> nulldummy is liteeally: the ignored input to checkmultisig has to be the eempty vector
6422016-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?
6432016-08-18T19:57:38  <sipa> we should check if they are being included in the chain
6442016-08-18T19:57:40  <wumpus> okay that seems harmless and easy to check
6452016-08-18T19:57:44  <luke-jr> jonasschnelli: nobody sends these, so it's hard to know if anyone mines them
6462016-08-18T19:57:54  <btcdrak> it's already nonstandard
6472016-08-18T19:58:09  <wumpus> makes sense to include that with the LOWS cleanup then
6482016-08-18T19:58:12  <luke-jr> oh, and since all miners MUST be on 0.12.1 now, nobody should mine these
6492016-08-18T19:58:24  <sipa> why must they be on 0
6502016-08-18T19:58:29  <sipa> why must they be on 0.12.1?
6512016-08-18T19:58:29  <luke-jr> sipa: CSV?
6522016-08-18T19:58:36  <btcdrak> last softfork
6532016-08-18T19:59:02  <sipa> ah.
6542016-08-18T19:59:03  <btcdrak> since we didnt release a 0.11.x they upgraded to 0.12.1
6552016-08-18T19:59:28  <jonasschnelli> LOW_S & NULLDUMMY seems to make sense to include in the SW SF.
6562016-08-18T19:59:30  <btcdrak> I think luke-jr's grammar has a bug or two :-p
6572016-08-18T19:59:41  <wumpus> let's not have a new thing creep into SW every week though :p
6582016-08-18T19:59:43  <BlueMatt> I'm not a huge fan of bundling them :/
6592016-08-18T19:59:43  <luke-jr> btcdrak: ?
6602016-08-18T19:59:55  <BlueMatt> though not against a separate sf that is also in 0.13.1, though thats also gross
6612016-08-18T20:00:10  <btcdrak> BlueMatt: it's a trivial one liner (modulo tests)
6622016-08-18T20:00:10  <luke-jr> the only reason to bundle IMO is if we want to add new non-VERIFY opcodes to segwit.
6632016-08-18T20:00:19  <BlueMatt> btcdrak: I'm aware, doesnt mean I like it
6642016-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
6652016-08-18T20:00:23  <wumpus> they're just a cleanup
6662016-08-18T20:00:27  <luke-jr> but LOWS/NULLDUMMY are just softforks, so no need to bundle IMO
6672016-08-18T20:00:35  <luke-jr> (no harm either)
6682016-08-18T20:00:47  <BlueMatt> wumpus: ok, fair enough, though in same version...anyway, I'll hold my tounge
6692016-08-18T20:01:00  <wumpus> #endmeeting
6702016-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)
6712016-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
6722016-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
6732016-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
6742016-08-18T20:01:04  <btcdrak> fwiw, miners dont like to have to upgrade so frequently.
6752016-08-18T20:01:28  <BlueMatt> btcdrak: yes, also if we had mempool-on-disk they'd care marginally less
6762016-08-18T20:01:31  <BlueMatt> but still not fans
6772016-08-18T20:01:47  <jonasschnelli> Removing all known sources of malleability in the initial SW SF should be achievable?
6782016-08-18T20:01:47  <btcdrak> BlueMatt: there is a PR for that
6792016-08-18T20:01:50  <BlueMatt> I'm aware
6802016-08-18T20:01:52  <wumpus> there's a pull open to persist mempool to disk right?
6812016-08-18T20:01:57  <BlueMatt> yes
6822016-08-18T20:02:00  <sipa> yes, it's buggy thougg
6832016-08-18T20:02:06  <sipa> i'll work on it again
6842016-08-18T20:02:07  <btcdrak> is there an echo in here?
6852016-08-18T20:02:08  <wumpus> that's 0.14 at first though
6862016-08-18T20:02:23  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8448
6872016-08-18T20:02:27  <jl2012> jonasschnelli: OP_IF/NOTIF is still a problem
6882016-08-18T20:02:50  <btcdrak> jl2012: you were going to make that nonstandard for now iirc?
6892016-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
6902016-08-18T20:03:51  <sipa> BlueMatt: wow, really :(
6912016-08-18T20:03:52  <jl2012> btcdrak: yes
6922016-08-18T20:04:09  <BlueMatt> sipa: I mean its not unlikely someone is malleating originally-low-s txn, though
6932016-08-18T20:04:21  <sipa> BlueMatt: even while no recent releases relay high-s...
6942016-08-18T20:04:22  <BlueMatt> sipa: I checked a month or so ago and it was like 1 per hour
6952016-08-18T20:04:57  <btcdrak> they cant be getting mined though... all the miners are on 0.12.1
6962016-08-18T20:05:34  <warren> maybe they are getting mined thanks to BlueMatt? =)
6972016-08-18T20:06:18  <BlueMatt> btcdrak: the malleated versions can, though
6982016-08-18T20:06:30  *** gmaxwell has joined #bitcoin-core-dev
6992016-08-18T20:06:47  *** cryptapus has quit IRC
7002016-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
7012016-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?
7022016-08-18T20:09:34  <wumpus> luke-jr: IIRC rcs have always been the version internally
7032016-08-18T20:09:46  <wumpus> rcs have never been 0.X.99
7042016-08-18T20:09:47  <warren> luke-jr: IIRC rc's always were internally the version with "rcX" appended
7052016-08-18T20:10:17  <wumpus> yes
7062016-08-18T20:10:32  <sipa> long ago rcs were literally release candidates: the latest rc binary literally became the final binary
7072016-08-18T20:10:47  <wumpus> right
7082016-08-18T20:11:02  <sipa> though we'vdle gone through so many schemes that i can't say i'm sure anymore :)
7092016-08-18T20:11:24  <wumpus> I've been entirely consistent the last few major releases
7102016-08-18T20:11:47  * luke-jr questions his memory
7112016-08-18T20:11:50  <warren> I joined around 0.8 and it was consistent since then at least.
7122016-08-18T20:12:04  <sipa> the last release i did was 0.3.23
7132016-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. :(
7142016-08-18T20:15:08  <gmaxwell> Among the other things I wanted to say was this:
7152016-08-18T20:15:10  <gmaxwell> Kanzure, achow101. Regarding your public comments on the bitcoin.org notice.
7162016-08-18T20:15:13  <gmaxwell> https://www.reddit.com/r/btc/comments/4y8sk7/0130_binary_safety_warning_bitcoinorg/d6m1oqu
7172016-08-18T20:15:16  <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/4y8m76/0130_binary_safety_warning_bitcoinorg/d6luukw
7182016-08-18T20:15:19  <gmaxwell> I think you've taken the wrong position, by pounding on process.
7192016-08-18T20:15:22  <gmaxwell> If someone with privleged access is aware of a serious concern and believes
7202016-08-18T20:15:25  <gmaxwell> they urgently need to tkae unilateral action to make a minimal statement
7212016-08-18T20:15:28  <gmaxwell> simply to _notify_ people of the risk and encourage following an existing
7222016-08-18T20:15:31  <gmaxwell> process to mitigate, they should do so. Pounding on procedure comes across
7232016-08-18T20:15:34  <gmaxwell> as a denial which I don't believe you had the information to make.
7242016-08-18T20:15:36  <gmaxwell> (and in fact, since achow101 did not talk to all the major developers, I
7252016-08-18T20:15:39  <gmaxwell> _know_ you didn't have the information needed to make the claim you made.)
7262016-08-18T20:15:42  <gmaxwell> And yes, someone doing something like that unilaterally is going to cause
7272016-08-18T20:15:45  <gmaxwell> some pain. But that is okay, the security process should favor risk
7282016-08-18T20:15:48  <gmaxwell> reduction, over creating a bit of pain here and there.
7292016-08-18T20:15:50  <gmaxwell> [In fact, both of your messages could come across as expressing the view
7302016-08-18T20:15:53  <gmaxwell> that we are skeptical that HTTPS MITM attacks are even a risk, when in fact
7312016-08-18T20:15:56  <gmaxwell> we _know_ they are well documented to happen with some regularity.]
7322016-08-18T20:15:59  <gmaxwell> We are at no real risk of tiring people out with a flood of false positives,
7332016-08-18T20:16:02  <gmaxwell> otherwise I would take a different position, perhaps.
7342016-08-18T20:16:04  <gmaxwell> Cobra isn't great at public relations, sure, but I notice none of the people
7352016-08-18T20:16:07  <gmaxwell> complaining opened PRs to improve the language. His notice states the
7362016-08-18T20:16:10  <gmaxwell> concern, the believed targets, and contains specific, conservative,
7372016-08-18T20:16:12  <gmaxwell> mitigation instructions, it could be a lot worse.
7382016-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.
7392016-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.
7402016-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. :)
7412016-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.
7422016-08-18T20:46:32  *** cryptapus_afk has quit IRC
7432016-08-18T20:53:19  *** fengling has joined #bitcoin-core-dev
7442016-08-18T20:57:09  *** cryptapus_afk has joined #bitcoin-core-dev
7452016-08-18T20:58:06  *** fengling has quit IRC
7462016-08-18T21:01:12  *** cryptapus_afk is now known as cryptapus
7472016-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
7482016-08-18T21:06:38  <gmaxwell> yea, that stuff was halarious.
7492016-08-18T21:07:23  <kanzure> this seems like a good opportunity to show off a favorite tool of mine, https://mitmproxy.org/
7502016-08-18T21:09:13  * luke-jr ponders hacking his email client to refuse to send to the old MLs :|
7512016-08-18T21:09:46  <kanzure> send to both
7522016-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
7532016-08-18T21:20:01  *** TomMc has quit IRC
7542016-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".
7552016-08-18T21:20:16  <cfields> jonasschnelli: i can still PR the id addition to the table though, if you'd like
7562016-08-18T21:25:40  *** zooko has quit IRC
7572016-08-18T21:25:48  *** billotronic has quit IRC
7582016-08-18T21:27:30  *** Guyver2 has quit IRC
7592016-08-18T21:34:19  *** TomMc has joined #bitcoin-core-dev
7602016-08-18T21:46:52  *** MarcoFalke has left #bitcoin-core-dev
7612016-08-18T21:53:13  *** zooko has joined #bitcoin-core-dev
7622016-08-18T21:54:48  *** fengling has joined #bitcoin-core-dev
7632016-08-18T21:57:06  *** yep444 has quit IRC
7642016-08-18T21:59:46  *** fengling has quit IRC
7652016-08-18T22:00:44  *** aalex has quit IRC
7662016-08-18T22:06:01  <midnightmagic> achow101: :-)
7672016-08-18T22:32:20  *** JackH has joined #bitcoin-core-dev
7682016-08-18T22:38:39  *** spudowiar has joined #bitcoin-core-dev
7692016-08-18T22:45:32  *** TomMc has quit IRC
7702016-08-18T22:49:57  *** JZA has quit IRC
7712016-08-18T22:51:36  *** zooko has quit IRC
7722016-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
7732016-08-18T22:54:09  <BashCo> mostly focused on encouraging cross referencing keys from multiple sources, as well as signatures from multiple developers.
7742016-08-18T22:55:48  *** netzin has joined #bitcoin-core-dev
7752016-08-18T22:56:02  *** netzin is now known as n3tsin
7762016-08-18T22:56:23  *** fengling has joined #bitcoin-core-dev
7772016-08-18T22:58:50  *** JZA has joined #bitcoin-core-dev
7782016-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
7792016-08-18T23:01:06  *** fengling has quit IRC
7802016-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.  :(
7812016-08-18T23:26:35  <midnightmagic> Is the money actually stolen?
7822016-08-18T23:27:47  <gmaxwell> I believe there address was 1K35Q6BEkCvhE2k7SUeZXKDFTtZACEfNcn and its been cleaned out.
7832016-08-18T23:28:49  <BlueMatt> ouch
7842016-08-18T23:29:12  <BlueMatt> thats a bunch of cash, too
7852016-08-18T23:34:57  <luke-jr> ugh, maybe we need more red lights on the debug window? :/
7862016-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.
7872016-08-18T23:36:12  <Lauda> +1
7882016-08-18T23:37:29  <luke-jr> sounds easier than it probably is. stupid JSON has no comments
7892016-08-18T23:41:34  <gmaxwell> I think that RPC doesn't return json?
7902016-08-18T23:41:46  <gmaxwell> wait thats dumb, I guess it does.
7912016-08-18T23:41:49  <gmaxwell> :-/
7922016-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)
7932016-08-18T23:43:38  <gmaxwell> ugh. or make the debug console do something special.
7942016-08-18T23:44:16  <luke-jr> but there's other unsafe things too - like importprivkey..
7952016-08-18T23:44:27  <luke-jr> and a comment couldn't work for that case
7962016-08-18T23:44:43  <gmaxwell> Yes, and I've seen someone robbed via that too. But it's less unsafe, I think.
7972016-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?
7982016-08-18T23:46:53  <gmaxwell> lots of pure status things.
7992016-08-18T23:47:01  <gmaxwell> getinfo/getchaintips/getmempoolinfo
8002016-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.
8012016-08-18T23:48:07  <luke-jr> signmessage has a proper GUI at least
8022016-08-18T23:55:52  *** Ylbam has quit IRC
8032016-08-18T23:57:52  *** fengling has joined #bitcoin-core-dev