1 2016-03-25 05:05:46	0|cfields|sipa / jonasschnelli: i pushed a quick hack to libbtcnet that adds an option for chunked reads as opposed to header+message. It's clunky, but should be enough to test with
 2 2016-03-25 06:39:19	0|gmaxwell|yippie. mutation testing proves the existing tests are inadequate.
 3 2016-03-25 06:39:24	0|gmaxwell|(for ct aes)
 4 2016-03-25 07:38:28	0|jonasschnelli|gmaxwell: what do you mean with inadequate? IIRC, the tests included a subset of the NIST test vectors.
 5 2016-03-25 07:39:02	0|jonasschnelli|Or do you aim in particular for something to test the CT?
 6 2016-03-25 07:42:04	0|gmaxwell|I mean I can add plausable bugs to the implementation which pass the vectors.
 7 2016-03-25 07:42:47	0|gmaxwell|I'll create more vectors to resolve this, of course.
 8 2016-03-25 07:46:13	0|jonasschnelli|Okay. Yes. That would be good.
 9 2016-03-25 07:46:46	0|jonasschnelli|Is the CT behavior somehow testable in a test script that should be portable enought?
10 2016-03-25 07:57:12	0|gmaxwell|No, and not much reason to 'test' generally.. all the promises that can be given from C on that front are statically decidable.
11 2016-03-25 08:15:18	0|jonasschnelli|For ChaCha20-poly1305, would this require two keys? One for the chacha cipher and one for the poly1305 AED?
12 2016-03-25 08:15:34	0|jonasschnelli|*AEAD
13 2016-03-25 10:05:35	0|demaged|hi, have you guys seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=812275
14 2016-03-25 10:06:27	0|demaged|besideds, what's the reason bitcoin isn't migrating to testing, stuck in ustable for years now :/
15 2016-03-25 10:17:54	0|wumpus|I'm quite happy that bitcoin isn't packaged by distributions - we had some bad experiences in the past with ubuntu's bitcoin package being stuck at 0.3.x, for example.
16 2016-03-25 10:18:33	0|wumpus|distributions have their own pecularities in versioning, releases, etc. I think it'd be better to release our own packages for various distros, like we do with the ppa.
17 2016-03-25 10:22:24	0|GitHub14|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b88e0b0c610a...0b98dd793967
18 2016-03-25 10:22:25	0|GitHub14|13bitcoin/06master 144856f1d 15Jonas Schnelli: [Qt] Debug window: replace "Build date" with "Datadir"...
19 2016-03-25 10:22:25	0|GitHub14|13bitcoin/06master 14fc737d1 15Jonas Schnelli: [Qt] remove unused formatBuildDate method
20 2016-03-25 10:22:26	0|GitHub14|13bitcoin/06master 140b98dd7 15Wladimir J. van der Laan: Merge #7732: [Qt] Debug window: replace "Build date" with "Datadir"...
21 2016-03-25 10:22:34	0|GitHub39|[13bitcoin] 15laanwj closed pull request #7732: [Qt] Debug window: replace "Build date" with "Datadir" (06master...062016/03/qt_datadir) 02https://github.com/bitcoin/bitcoin/pull/7732
22 2016-03-25 10:38:08	0|demaged|wumpus, maybe though I think for the convenience of users, free auditing done by the maintaners, extra exposure and bug reporting, etc. is worth the cooperation
23 2016-03-25 10:38:28	0|wumpus|well, feel free to do so
24 2016-03-25 10:38:38	0|wumpus|I can say a lot of people have tried and failed :)
25 2016-03-25 10:39:31	0|wumpus|and for example it doesn't help bug reporting *at all* if some distribution, in its stable release, keeps shipping bitcoin 10.2 forever. We'd get tons of reports against old versions, for bugs that have probably been solved ages ago.
26 2016-03-25 10:40:41	0|wumpus|also philosophically, upgrading bitcoin core should be a conscioius decision. You may or may not agree with any consensus changes.
27 2016-03-25 10:41:05	0|wumpus|that's why there are no auto-upgraders nor even new version notification in the client
28 2016-03-25 10:47:45	0|demaged|wumpus, regarding your comment on bug reporting I disagree, imo it helps with the diversification of the ecosystem as it would be a disaster if all the nodes were on v0.12 for example
29 2016-03-25 10:49:13	0|demaged|just wondering, debian has what 50k+ packages  in its main repo, surely there's a way to cooperate otherewise the number wouldn't be so high
30 2016-03-25 10:52:25	0|demaged|i agree with you on the point of forced upgrades but I don't see distro updates as such
31 2016-03-25 10:53:35	0|demaged|anyway, I only wanted to point out that bug report in case it's interesting for devs as I don't have github account to report
32 2016-03-25 11:01:06	0|demaged|from personal experience, I'm a sys-admin and have been running non-wallet full nodes on multiple servers I maintaining for many years now to help the network and having bitcoind package in Debian was always my biggest wish... for convenience... one day.
33 2016-03-25 11:01:08	0|demaged|thanks
34 2016-03-25 11:03:44	0|wumpus|no, it wouldn't be a disaster if all nodes were 0.12
35 2016-03-25 11:04:17	0|wumpus|a group like debian indescriminately deciding what version a large part of the network runs is much more disastrous
36 2016-03-25 11:27:57	0|demaged|wumpus, I'm sorry but you're wrong. With no safe fallback to nodes running v0.10 or v0.11 one critical security bug could bring the whole network down or worse.
37 2016-03-25 11:28:13	0|demaged|Also, Debian is far from indiscriminate in their choices nor it would make up large part of the network. This would add to diversity and decentralisation of, for example, update channels, etc.
38 2016-03-25 11:28:19	0|wumpus|what makes you think v0.10 or v0.11 is any safer?
39 2016-03-25 11:28:33	0|wumpus|if anything, many security bugs get solved every release
40 2016-03-25 11:28:43	0|demaged|wumpus, it may not contain bu that was introduced in v0.12
41 2016-03-25 11:29:40	0|demaged|s/bu/bug
42 2016-03-25 11:29:55	0|demaged|What if your infrastructure is compromised? What you're proposing is very dangerous.
43 2016-03-25 11:30:07	0|wumpus|that's true, that is a reason why one would run multiple versions of bitcoin core, some people indeed do that
44 2016-03-25 11:30:14	0|wumpus|consciouisly, not because a distro forces them to
45 2016-03-25 11:30:37	0|wumpus|I'm not proposing anything but keeping the status quo, you are the one proposing something
46 2016-03-25 11:30:56	0|demaged|in practical terms distro dosn't force me to do anything, it makes things more convenient
47 2016-03-25 11:31:18	0|demaged|Decentralisation in terms of whether software can run on RasPi is  important but so is decentralisation of update channels, development, ideas. Just m y 2c.
48 2016-03-25 11:32:23	0|wumpus|the point is that distros are used by a lot of newbies, and for newbies the best choice is generally to use the latest and greatest version. Advanced users may indeed chose to run older versions for verious reasons, that's fine.
49 2016-03-25 11:33:49	0|wumpus|in any case, I'm done discussing this
50 2016-03-25 11:34:03	0|demaged|true, that's why different distros target different audience for example ubuntu and debian; diversification of bitoind for free :)
51 2016-03-25 11:34:18	0|demaged|I didn't mean to sound pushy
52 2016-03-25 12:55:47	0|wumpus|hm re: https://github.com/bitcoin/bitcoin/issues/7463, it seems that if bitcoind never spins up RPC (for example, if init failures) the successive bitcoin-cli -rpcwait getblockcount will wait forever
53 2016-03-25 12:56:48	0|wumpus|that's something of a race condition, I think I'm going to implement the getblockcount loop myself, each time checking if bitcoind is still alive, instead of relying on -rpcwait
54 2016-03-25 13:25:08	0|GitHub25|[13bitcoin] 15laanwj opened pull request #7744: test_framework: detect failure of bitcoind startup (06master...062016_03_detect_startup_failure) 02https://github.com/bitcoin/bitcoin/pull/7744
55 2016-03-25 13:33:58	0|wumpus|voila
56 2016-03-25 14:14:03	0|wumpus|heh "In fact one of the reasons given for OpenSSH's adoption of the chacha20-poly1305 crypto mechanisms (alongside Curve25519 and others) was that it finally allowed them to remove the last vestiges of OpenSSL from their code."
57 2016-03-25 15:59:43	0|instagibbs|does an empty vector being serialized using READWRITE end up being read correctly? I'm running tests and have read the code to the best of my ability, but want to check.
58 2016-03-25 16:04:27	0|sipa|it should
59 2016-03-25 16:10:03	0|instagibbs|ok thanks
60 2016-03-25 16:10:41	0|instagibbs|It appears you attach a size message of 0, then nothing else, which should be enough.
61 2016-03-25 19:08:07	0|gmaxwell|jonasschnelli: I see your updated encryption draft. It doesn't appear to specify a KDF. The output of ECDH should not be used directly. (also, you're going to need a 256 bit session ID for later auth, and two 512 bit keys for the authenticated encryption); so that will be needed.   I'm not sure if that ciphersuite negoiation procedure is sufficient to achieve the goal that if X is faster for bot
62 2016-03-25 19:08:13	0|gmaxwell|h peers, they'll pick it... but regardless, both of their ciphersuite sets also need to be included in the KDF.  Otherwise a MITM could force ciphersuite selection (say to a weaker cipher) without disrupting changing the session ID.  Personally I'd just suggest dropping the negoation; having it and avoiding introducing downgrading attacks is hard... also supporting many ciphers pushes people to
63 2016-03-25 19:08:19	0|gmaxwell|using kitchen soup crypto libraries, which is bad for attack surface.
64 2016-03-25 19:10:47	0|gmaxwell|the input to the KDF should probably be the ECDH value, one of the public keys (doesn't matter which of the two-- assuming the pubkeys are all valid), and the offered paramters of each side.
65 2016-03-25 21:14:29	0|jonasschnelli|gmaxwell: I'm kind of afk but will check you feedback and update the BIP. Thanks!
66 2016-03-25 21:26:26	0|sipa|jonasschnelli: typically what you'll do is take the ECDH result (an EC point), and use that to seed some PRNG, from which you then draw the session key, encryption keys, ...
67 2016-03-25 21:27:13	0|sipa|jonasschnelli: note that libsecp256k1 at this point does not return the ECDH result point directly, but it returns a SHA256 of it (which guarantees all its entropy is used)