--- Day changed Thu Mar 24 2016
00:00 < sipax> gmaxwell: that is MitMable?
00:01 < gmaxwell> ... No.
00:01 < sipax> oh, no!
00:01 < jonasschnelli> gmaxwell: how would you pass the random generated symmetric cipher key to "the other side"? ECDH channel with the identity key?
00:03 < gmaxwell> Please please stop trying to use ecdh with long lived keys. This is almost always a severe design mistake.
00:04 < gmaxwell> Each side sends a new, randomly generated public key to the other side. The session keys (there will be more than one, likely four-- auth and encrypt in each direction) are the output of ECDH with those keys, fed through a KDF.
00:06 < jonasschnelli> gmaxwell: Okay. How would you protect from MITM. By auth with the identity key AFTER the encryption channel is setup?
00:08 < gmaxwell> if identification is in use, inside the encrypted channel you send a signature of the session id (a hash of the ephemerial key from ecdh which also commits to all the channel parameters) using the relevant identity.
00:09 < sipax> what do you mean by channel parameters?
00:09 < jonasschnelli> gmaxwell: how would you protect from attacking(DOSing) the encryption request (key generation!) if the auth is after the enc?
00:10 < jonasschnelli> Also fingerprinting
00:10 < jonasschnelli> (the later is probably fine if the 4 key are generated randomly)
00:10 < gmaxwell> key generation is very fast, faster then verifying your digital signatures you propose for authentication.
00:11 < gmaxwell> Fingerprinting what?
00:11  * jonasschnelli always though key generation is much more CPU intense then ecdsa verify.
00:11 < sipax> jonasschnelli: if you always use freshly generated ecdh keys, there is no fongerprinting
00:11 < jonasschnelli> gmaxwell: fingerprinting the node.
00:11 < jonasschnelli> Well,.. right. We could ban a node after a failed encryption request.
00:12 < sipax> i don't think it can fail
00:12 < jonasschnelli> sipax: I mean the identity check afterwards
00:13 < sipax> jonasschnelli: it's much cheaper for them to go ask us a bunch of random blocks, with far higher costs
00:13 < sipax> if they want to dos
00:13 < gmaxwell> jonasschnelli: no, it's fundimentally easier to generate a new keypair than to verify a ecdh signature. They're pretty close in timings, because we use a constant time implementation for the former. 
00:13 < jonasschnelli> But this would basically mean, every peer can request encrypted sessions... (which i'm not sure if its good or bad).
00:13 < gmaxwell> they should, and they should all be encrypted so as not to distingush the ones using authentication.
00:14 < gmaxwell> and this can be made faster than the existing transport (or at least not considerably worse).
00:14 < sipax> jonasschnelli: for ECDSA, verify > sign >>> keygen
00:15 < jonasschnelli> sipax: I see. Thanks!
00:15 < sipax> jonasschnelli: computing the pubkey for a generated private key is similar to signing
00:15 < gmaxwell> well if by keygen you mean generate a pubkey too, then sign == keygen, pretty much.
00:15 < gmaxwell> and this is faster than verify.
00:16 < sipax> same order of magnitude in any case
00:16 < jonasschnelli> gmaxwell: So. The peer would pass one pubkey for the dh secret calculation and the (static) identity pubkey (static) for auth to the other peer. Right?
00:16 < jonasschnelli> (doesn't the current[and most] ec keygen algos do a dummy sign/verify to ensure validity?)
00:17 < sipax> jonasschnelli: if by auth you mean the signing of the session key, indeed
00:17 < sipax> jonasschnelli: bitcoin does
00:17 < gmaxwell> the only software ever created that does that is bitcoin core.
00:17 < gmaxwell> as far as I can tell.
00:17 < gmaxwell> and it's only sensible to do that for payment addresses, it wouldn't be done here.
00:18 < gmaxwell> first an encrypted, authenticated channel would be brought up using a ephemeral pubkey sent in each direction.  Then _inside_ that channel, the participants could identify themselves by signing the session-id. 
00:18 < jonasschnelli> only signing the session key would not allow the remote peer to identify which identity is signing. Wouldn't it require at least the hash of the identity pubkey?
00:19 < gmaxwell> Techincally the signature and message its signing is enough, you can just get the pubkey from that. Though it could send the pubkey its using.
00:20 < jonasschnelli> Ah. Right pubkey recover.
00:20 < gmaxwell> but there are better protocols for identifying than just sending a signature-- ones that do not leak the identity of at least one participant.
00:20 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Read error: Connection reset by peer]
00:20 < jonasschnelli> 0-knowlage? 
00:21 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
00:21 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
00:22 < jonasschnelli> What about allowing auth without enc? We probably presume encryption when authenticating.
00:23  * gmaxwell looks through logs.
00:23 < gmaxwell> 13:14 < gmaxwell> There are protocols that avoid the fingerprinting; e.g. (the server protectng mode of) https://www.ietf.org/proceedings/54/I-D/draft-ietf-ipsec-jfk-04.txt
00:23 < gmaxwell> jonasschnelli: I think there is no utility to identifying without encryption. 
00:24 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 276 seconds]
00:24 < jonasschnelli> Agree. The current auth proposal would also require signing (auth) each message (which is resource hungry).
00:24 < gmaxwell> thats unacceptably slow.
00:24 < jonasschnelli> encryption before authentication allows to keep a auth-session.
00:25 < sipax> jonasschnelli: note that authentication is used in two meanings here; there is identification (done by signing the session key) and MAC (which you still need, but ks covered by using an authenticated mode of encryption such as AES-GCM)
00:25 < gmaxwell> (and signining indivigual messages provides non-repudiation, which is usually not what you want; except in specific instances where you do want it.)
00:25 -!- sipax is now known as sipa
00:26 < jonasschnelli> I see.
00:26 < sipa> jonasschnelli: so there is "auth" on each message, but it's done with a symmetric shared session key, rather than the identity key
00:26 < jonasschnelli> And I guess it would be acceptable if the remote peer can fingerprint the requesting peer because it reveals its identity after the encryption channel is established.
00:27 < gmaxwell> jonasschnelli: it's better than the other way around at least. preferably no one could fingerprint anyone; but it's not clear how possible that is.
00:27 < jonasschnelli> sipa: Right. But we just need to make sure the symmetric shared session key was shared between the right parties and not Mitmdled.
00:27 < sipa> jonasschnelli: i think you probably want a per-IP identity, or perhaps just randomly generated identities by default, and allow a peer to ask "hey, you're identity X, right? prove it"
00:27 < gmaxwell> Other than the "connect to my own server" case it's not clear to me exactly how the identification would be used.
00:28 < jonasschnelli> sipa: But that would not work for DHCP nodes (SPV)?
00:29 < sipa> jonasschnelli: so perhaps a separate private non-random configurable host key, which is only used if requested by the peer
00:29 < sipa> that means no TOFU, though
00:29 < gmaxwell> we don't want to create cases where nodes can be tracked easily, we've worked to remove identifying information from the protocol...  having a protocol where there is mutual auth, say between your own 'server' and 'client'  or between your own hosts,  having the requester leak something the allows them to be correlated, but only inside an encrypted channel which they think is to their trusted pe
00:29 < gmaxwell> er, would be minimally harmful.
00:30 < gmaxwell> sipa: I don't know what use tofu would have... and what happens when a node goes away (say, gets deleted) and a new one is at that address? now you need an expiration mechenism.
00:31 < jonasschnelli> gmaxwell: at least you could setup a honeypot-like peer that waits until other peers connect, request encryption and identify themself. You could than combine this data with other fingerprint possibilities (mempool and stuff like that).
00:32 < gmaxwell> jonasschnelli: the party initating authentication would be the only one to lose privacy, so a honey pot would not work; unless it also successfully mitmed hosts that clients were attempting to connect to.
00:32 < jonasschnelli> But somehow I think either you have a MITM attack possibility or you reveal ones identity. Maybe some zero knowledge prove method could be used here (not familiar with these)
00:32 < gmaxwell> There are probably multiple usecases which would identify the channel in different ways; but the same secure channel mechenism would work.
00:33 < gmaxwell> jonasschnelli: I linked a likely sutable identification protocol above. 
00:34  * jonasschnelli is reading the JFK proposal. Thanks to gmaxwell 
00:35 < gmaxwell> I am not suggesting we specifically use that, as much as pointing out that it's possible to do better... but even a very simple protocol does what we want, I think.
00:35 < sipa> jonasschnelli: you could also avoid the problem, and by default not have identification, and only have a "prove to me you're X before continuing" message inside the encryptee channel
00:36 < sipa> perhaps even using symmetric crypto, so it only works with a preshared symmetric key
00:36 < jonasschnelli> sipa: Yes. Agreed. Auth would only be necessary or useful if the both peers know each other (preshared key, same owner, SPV<->node stuff).
00:37 < gmaxwell> identification, when you say auth it easily gets confused with the authentication part of encryption which is necessary and cannot be omitted when encryption is used. :)
00:37 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
00:37 < jonasschnelli> A preshared preshared symmetric key would also work. Right. IMO its just easier to share two pubkeys instead of one "symmetric key".
00:39 < jonasschnelli> gmaxwell: Can you explain the differences between the identity authentication and the encryption authentication? Why would the later be required if both parties stay anonyme to each other?
00:39 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Ping timeout: 240 seconds]
00:39 < jonasschnelli> Once you exchanged encryption ephemeral pubkeys, MITM should no longer be possible?
00:40 < gmaxwell> jonasschnelli: any use of encryption _must_ come with symmetric-key authentication, or otherwise the encryption will be mallible and an attacker can corrupt the channel in ways that leak information about the content. 
00:41 < gmaxwell> e.g. they flip a bit, and instead of instantly hanging up, the application is fed some gibberish, and then based on exactly how it responseds/doesn't respond the attacker learns something about the state of the connection and the prior encrypted data.
00:42 < gmaxwell> so the encryption must comes with a message-authentication-code keyed at the same time as the encryption, so any corruption is detected and the connection terminated without revealing anything, ideally before even decrypting the data. 
00:42 < jonasschnelli> gmaxwell: sharing the encryption ephemeral pubkeys, calculate symmetric secret and hash the complete communication (starting with both pubkey in deterministic order), compare the hashes after decrypt..  
00:43 < gmaxwell> jonasschnelli: that isn't sufficient.
00:43 < sipa> jonasschnelli: encryption provides confidentiality, not integrity
00:44 < jonasschnelli> hmm....
00:44  * jonasschnelli is reading...
00:45 < Luke-Jr> jonasschnelli: it might or might not make sense to coordinate with the new payment protocol encryption stuff
00:45 < Luke-Jr> in BIP 75
00:47 < jonasschnelli> Luke-Jr: thanks. Will check. Agree on the p2p 16x num range.
00:49 < sipa> jonasschnelli, gmaxwell: the paper my const time aes is based on actually discusses aes-gcm (and easily has 4x the performance of the cbc case, as it can do 4 parallel encryption operations)
00:50 < jonasschnelli> gmaxwell sipa: hmm... (having a hard time to understand this correctly): so you would require to generate two keypairs at the same time, one for the encryption sym. cipher key, one for the MAC key. Then you sould sha256_hmac the complete message traffic on both sides and compare to validate the integrity?
00:50 < sipa> jonasschnelli: no, you use aes-gcm
00:51 < sipa> which does encryption and mac simultanelusly
00:51 < jonasschnelli> sipa: okay. I see. But the overall concept would be correct (just to understand the basics).
00:51 < jonasschnelli> s/./?
00:52 < sipa> though, conceptually, yes, you can use aes for encryption, and then do hmac-sha256 on the encrypted data for integrity
00:52 < gmaxwell> There should be two "keys" if using authenticated encryption (like AES-GCM, chacha20-poly, or things coming out of CAESAR) one key in each direction;  or four keys if constructing autenticated encryption from a cipher and hmac.
00:53 < jonasschnelli> What I have problems to understand is how attacks would be possible if you would take the encryption ephemeral publey calculated sym. key for the MAC...
00:53 < sipa> jonasschnelli: let's say you use aes-ctr
00:53 < sipa> you know ctr?
00:54  * jonasschnelli reading... got the essence. Yes.
00:54 < jonasschnelli> streaming.
00:55 < sipa> someone may not be able to decrypt without having the key, but if they can guess what the contents is of a particular message, they can modify it by xoring it with both what they think the decrypted data is, and xoring it with what they want the decrypted data to be
00:56 < sipa> there are more complex bad things you can do with other encryption schemes
00:56 < jonasschnelli> sipa: Got it! Thanks!
00:57 < sipa> but ctr is a nice example, because it perfectly covers confidentially, but provides almost nothing else
00:57 < sipa> so it clearly shows the distinction
00:58  * jonasschnelli is reading the details of AES-GCM
00:59 < jonasschnelli> sipa: But IIRC, your AES PR is CBC. So GCM would require another implementation while our codebase already supports SHA2 HMAC?
00:59 < sipa> jonasschnelli: GCM is easy :)
01:00 < jonasschnelli> sipa: for you or for all other lazy programmers.. :)
01:00 < gmaxwell> sha2 is slow.
01:01 < jonasschnelli> And I guess we could drop the message headers 4byte sha256 checksum once encrypted and MACed
01:01 < gmaxwell> (AES-GCM is also not astonishingly fast without hardware AES, but should be faster than sha2)
01:02 < gmaxwell> jonasschnelli: yes, and the result, with sutiable primitive selection would be _faster_ than the existing protocol, even though it was encrypted.
01:02 < jonasschnelli> hah. Thats an argument.
01:02 < gmaxwell> (faster in terms of cpu usage, it would likely have some more bandwidth overhead, but not a ton)
01:03 < jonasschnelli> But I'm mostly thinking "in implementations". So,... I could write a first implementation that drops the 4byte header sha and uses SHA2 HMAC for the MAC.. just to have an implementation basepoint.
01:03 < jonasschnelli> (in addition to the whole encryption keysharing stuff)
01:03 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
01:04 < jonasschnelli> I could be the guy that works on the code frontend while I require analysis and conceptual support from gmaxwell/sipa and others. This could lead to a pratical p2p encryption IMO.
01:06 < sipa> gmaxwell: my current const aes needs 270 cycles/byte; making it do 4 in parallel is trivial and would make it need 72; researchers claim they can do ~10 using simd
01:06 < sipa> and ~3 with aes-ni
01:06 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
01:06 < gmaxwell> sipa: I think with a.. right.
01:07 < gmaxwell> See also the motivationes behind the CAESAR competition.
01:11 -!- asdfdsas [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 250 seconds]
01:13 < gmaxwell> sipa: lol one of the CAESAR entries is based on keccak and is named "keyak". That totally isn't going to cause any confusion...
01:16 < GitHub117> [bitcoin] laanwj closed pull request #7694: Rename AcceptBlock/AcceptBlockHeader to StoreBlock/StoreBlockHeader (master...2016-03-15-naming) https://github.com/bitcoin/bitcoin/pull/7694
01:16 < sipa> gmaxwell: i was just reading the keyak v2 paper
01:18 < btcdrak> I've asked a cryptographer to look at #7689
01:23 < jonasschnelli> Could we ask apoelstra?
01:23 < jonasschnelli> I'm not sure if a standalone AES library (move sipas PR to a custom library) would make sense.
01:25 < jonasschnelli> Adding more non-consensus stuff there will very likely lead to a openssl clone?!
01:25 < jonasschnelli> And adding SHA512 but not SHA256?
01:25 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
01:25 < wumpus> jonasschnelli: correct
01:26 < wumpus> I don't think petertodd's concern is so much about the library, but more about 'how much review doees this get'
01:26 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
01:28 < jonasschnelli> wumpus: after thinking about it. maybe a simple C bases AES library could have a reason to exists.
01:28 < sipa> gmaxwell: what is the fastest authenticated encryption scheme implementation that you know? (assume no hardware support, but constant time)?
01:28 < wumpus> jonasschnelli: sure, it could, but this is specifically a constant-time AES for wallet encryption
01:29 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
01:29 < jonasschnelli> wumpus: Right. If the p2p encryption will be implemented once, it could be extended there (AES CGM).
01:29 < gmaxwell> sipa: people who want that are using chacha20-poly1305.  AES-GCM with hardware support is apparently somewhat faster (and much less power hungry); but without it the chacha20-poly1305 stuff is faster.
01:29 < wumpus> it's e.g. not the fastest way to implement AES, because we specifically don't need that. There may not be many projects that want to tuse it at all, and there's a long tradition of copy/pasting crypto code anyhow....
01:30 < gmaxwell> people who care about fast AES use hardware or use these parallel implementations which cannot be used for CBC mode, which compatiblity with the wallet encryption needs.
01:31 < wumpus> gmaxwell: yes, exactly
01:31 < wumpus> for the AES code I really have only one concern: is it correct
01:32 < wumpus> for the random code I'm more scared because of the platform dependence and other uglyness involved
01:32 < sipa> wumpus: agree
01:32 < gmaxwell> currently we don't care at all about fast AES. We should somewhat care that it doesn't have stupid sidechannels.  Later, if we care about fast AES for p2p encryption, it would be AES-GCM and end up with a CBC incompatible implementation in any case.
01:32 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
01:33 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Quit: AtashiCon]
01:33 < wumpus> yes, for P2P we could use a different implementation of AES, or not AES at all (chacha20 or so :p)
01:34 < gmaxwell> right or whatever CAESER selects, depending on what that happens.
01:34 < wumpus> yes
01:35 < sipa> gmaxwell: that's 2 years out
01:35 < gmaxwell> (most of the CAESER candidates are AES based in any case, mostly addressing security complaints about GCM, and expecting hardware support to address the obnoxiousness of constant time AES)
01:36  * wumpus really likes chacha20, it's so small, efficient, and seemingly simple
01:36 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
01:37 < gmaxwell> it has a mixed following, it's apparently enough faster on ARM and without AES-NI that many in the web world have considered it urgent to support... but apparently a lot of the datacenter folks are less than enthused since it ends up much more power hungry than hardware AES. 
01:39 < wumpus> yes, right, it's specifically efficient in sw, if there is a hw implementation of AES it'll win out
01:39 < jonasschnelli> What MAC AAD would make sense for the p2p encryption? hash of the pubkey&pubkey? IP/Port?
01:40 < wumpus> let's just wait for hw chacha20 *ducks*
01:41 < gmaxwell> wumpus: well, its not like they have anything better to do with the transistors...
01:41 < wumpus> gmaxwell: agree, the dark silicon problem
01:43 < wumpus> then again - for bitcoin nodes we need to worry about consumer hw, not so much big datacenters
01:43 < wumpus> I think it's safe to say there won't be so many bitcoin nodes in datacenters to rival the number of https implementations, let alone be a power usage concern
01:43 < gmaxwell> well a lot of 'consumer hardware' has hardware aes now too, just not phones so much. :)
01:44 < gmaxwell> but indeed.
01:44 < wumpus> power usage on the other hand is mostly a phone concern. But yeah.
01:46 < gmaxwell> in any case both, given good implementations, should be faster the current 'checksum' 
01:48 < sipa> jonasschnelli: the additional data is sent in every message
01:51 < sipa> jonasschnelli: you would include the message length there, for example
01:51 < jonasschnelli> sipa: hmm.. so hash would be too expansive?
01:51 < sipa> hash of what?
01:52 < jonasschnelli> hash of the encryption pubkeys or could also be a hash of the plaintext message.
01:54 < sipa> what are you trying to do?
01:55 < sipa> the additional data is a feature provided by authenticated encryption schemes; you don't need to use it if you have nk need for it
02:02 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
02:03 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
02:04 < jonasschnelli> sipa: So do I got this right? You could use something like the current protocol version "70012" as AAD. And during decryption, you feed the TAG (processed AAD) together with the AAD into the decryption method and get a true or false?
02:04 < jonasschnelli> And thanks for you time to explain that to me. :)
02:06 < gmaxwell> you could-- generally it's used for additional per message data that must be sent cleartext for protocol reasons, but which you'd still like included in the authentication.
02:06 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Remote host closed the connection]
02:07 < jonasschnelli> gmaxwell: Okay. Right. Message length would be ideal then.
02:10 < gmaxwell> that would be the kind of thing; even that may not be necessary, if the length was wrong, the auth would fail in any case-- wrong amount of data in it.
02:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
02:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
02:32 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
02:35 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
02:36 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
02:37 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
02:38 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
02:38 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
02:41 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
02:46 -!- cdecker [~cdecker@pc-10367.ethz.ch] has quit [Quit: Lost terminal]
02:55 -!- p15 [~p15@111.193.182.148] has joined #bitcoin-core-dev
03:11 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:15 < sipa> jonasschnelli: i guess you can include the network magic to the aad
03:16 < jonasschnelli> sipa: okay. Would that be much different then the encrypted message length?
03:18 < sipa> jonasschnelli: i mean both... but there is no strong reason
03:19 < jonasschnelli> okay.
03:19 < sipa> essentially it guarantees that the length/magic came from someone with the session key
03:20 < jonasschnelli> ok
03:22 -!- p15 [~p15@111.193.182.148] has quit [Ping timeout: 246 seconds]
03:36 < sipa> aes-gcm uses 96-bit IVs, but they only require being unique for a given key
03:36 < sipa> and the key is establishes through ecdh
03:37 < sipa> so they can just be the message number, and don't need to be transmitted
04:14 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Ping timeout: 244 seconds]
04:18 < GitHub140> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/597494f5a90c041945006b8f3eff8f7e482e0f2f
04:18 < GitHub140> bitcoin/0.12 597494f Jonas Schnelli: Remove openssl info from init/log and from Qt debug window...
04:20 < GitHub121> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/e5c35119e967...3ba07bdf7da4
04:20 < GitHub121> bitcoin/master 146746b Alice Wonder: All files related to my RPM spec file project in one commit
04:20 < GitHub121> bitcoin/master 0e4b50a Alice Wonder: Description of RPM directory
04:20 < GitHub121> bitcoin/master 3ba07bd Wladimir J. van der Laan: Merge #7609: All files related to my RPM spec file project in one commit...
04:20 < GitHub36> [bitcoin] laanwj closed pull request #7609: All files related to my RPM spec file project in one commit (master...master) https://github.com/bitcoin/bitcoin/pull/7609
04:21 < GitHub199> [bitcoin] laanwj closed pull request #7650: Cache CBlockIndex::GetMedianTimePast (master...enhancement/cache-getmediantimepast) https://github.com/bitcoin/bitcoin/pull/7650
04:28 < GitHub62> [bitcoin] laanwj closed pull request #6973: Compress Blocks before sending (master...compress) https://github.com/bitcoin/bitcoin/pull/6973
04:32 < sipa> jonasschnelli: i now want to go implement gcm or poly1305...
04:32  * sipa resists, and works on segwit instead
04:50 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
04:58 < jonasschnelli> sipa: hah. Yes. Work on segwit. The p2p encryption is not urgent.
04:59 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
05:02 < jonasschnelli> sipa: regarding GCM IV: «[...] For a fixed value of the key, each IV value must be distinct, but need not have equal lengths [...]»
05:03 < jonasschnelli> 96 bit is ideal though.
05:09 < sipa> jonasschnelli: you could get 64 bits of the iv out of ecdh, and then add a 32-bit message counter, but that shouldn't be needed
05:15 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
05:28 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev
05:38 < Chris_Stewart_5> is there a BIP66 post mortem some where about the hard fork?
05:39 < sipa> BIP66 was not a hard fork... there were some miners that mined invalid blocks, and kept going
05:39 -!- mihi [~mihi@p5B079232.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:40 < Chris_Stewart_5> sipa: Essentially the miners not enforcing this function right? https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L98
05:53 < jonasschnelli> sipa: ecdh produces a 256bit secret? right? How would you take 64bits for the iv if you need to 256bits for the symmetric key?
06:24 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
06:42 < jonasschnelli> sipa gmaxwell: I'm happy if you are interested in reviewing the authentication and the encryption BIP (https://github.com/jonasschnelli/bips/blob/7e8a9f6e6a06cec1e7842452c85a9dec3730771b/bip-undef-1.mediawiki   https://github.com/jonasschnelli/bips/blob/7e8a9f6e6a06cec1e7842452c85a9dec3730771b/bip-undef-0.mediawiki)
06:43 < jonasschnelli> Don't review the language/orthography, will overhaul that once the technical details are clear.
06:44  * jonasschnelli can't tell you how hard it is to talk and write english if its a complete foreign language
06:56 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
06:59 -!- mihi [~mihi@p5B079232.dip0.t-ipconnect.de] has quit [Quit: Leaving]
07:00 < GitHub55> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3ba07bdf7da4...b88e0b0c610a
07:00 < GitHub55> bitcoin/master d6cc6a1 João Barbosa: Use CCoinControl selection in CWallet::FundTransaction
07:00 < GitHub55> bitcoin/master b88e0b0 Wladimir J. van der Laan: Merge #7506: Use CCoinControl selection in CWallet::FundTransaction...
07:00 < GitHub17> [bitcoin] laanwj closed pull request #7506: Use CCoinControl selection in CWallet::FundTransaction (master...enhancement/use-coin-control-selection) https://github.com/bitcoin/bitcoin/pull/7506
07:18 < sipa> jonasschnelli: if you want to use a single negotiation to intialize encryption for both directions, you need to make sure that the IVs in bith directions are different, or you break the assumption that an attacker cannot see two different messages with the same key and iv
07:20 < sipa> jonasschnelli: my suggestion here would be to have an encinit ("if you want, you can start sending encrypted messages to me and this is my key") and an encack ("yeah, every message after this one will be encrypted, and this is my key"), which you both send in both directions
07:21 < sipa> jonasschnelli: that way, both directions have independent ECDH negotiations, and you also have no problems with synchronization
07:22 < sipa> jonasschnelli: an alternative is thinking hard about synchronization, and making sure that the initiator and accepter of the encryption connection use separate IVs
07:22 < sipa> jonasschnelli: reusing the key as IV is not very useful, i think
07:24 < sipa> jonasschnelli: you probably want to include some text about how this interacts with version/verack (does encinit have to be the first message entirely? can it be done at any time?
07:31 < sipa> jonasschnelli: your encrypted message protocol spec could make the authentication tag explicit (it's 16 bytes for aes-gcm, though we could decide to truncate it)
07:33 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 268 seconds]
07:38 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
07:40 < jonasschnelli> sipa: thanks for the review! Will "process" your points and come back to you with feedback.
07:44 -!- lysobit [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
07:44 -!- musalbas [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
07:54 -!- BCBot_ [~BCBot@pc-10236.ethz.ch] has joined #bitcoin-core-dev
08:02 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
08:05 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
08:08 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
08:08 -!- gmaxwell_ [greg@mf4-xiph.osuosl.org] has joined #bitcoin-core-dev
08:08 -!- gmaxwell_ is now known as Guest18913
08:11 -!- CyrusV` [~cyrus@unaffiliated/cyrusv] has joined #bitcoin-core-dev
08:13 -!- Netsplit *.net <-> *.split quits: ebfull, CyrusV, gmaxwell, windsok, Cory, goregrind, arubi
08:29 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
08:29 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
08:29 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev
08:30 -!- Cory [~C@unaffiliated/cory] has quit [Max SendQ exceeded]
08:31 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
08:33 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev
08:36 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
08:38 -!- CyrusV` is now known as CyrusV
09:03 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
09:04 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
09:51 -!- Aleph0 [~User@unaffiliated/amphetamine] has quit [Quit: leaving]
09:54 -!- Guest18913 [greg@mf4-xiph.osuosl.org] has quit [Changing host]
09:54 -!- Guest18913 [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev
09:54 -!- Guest18913 is now known as gmaxwell
10:01 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
10:03 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has quit [Max SendQ exceeded]
10:04 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
10:09 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
10:27 < sipa> jonasschnelli: this is interesting: https://github.com/jhcloos/openssh-chacha-poly1305/blob/master/PROTOCOL.chacha20poly1305
10:28 < sipa> openssh's chacha20-poly1305 aead at a high level
10:28 < sipa> they encrypt the packet sizes too, but with a separate key
10:29 < sipa> and then authenticate using the second key which is used for authentication and encryption of the data
10:29 < sipa> which means that an attacker can't even see the message sizes, except by traffic analysis
10:30 < btcdrak> Clever
10:48 < gmaxwell> a little sad to require 4 byte lenghts.
10:50 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
10:52 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
10:58 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
10:59 < gmaxwell> sipa: for identified links, we could do a nice thing with rekeying to make them strong against ECC breaks.
11:00 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:01 < sipa> cfields: if we'd want to use something like that, i guess we want an api that allows a client to tell the comnection manager "let me know when you have X bytes"
11:01 < sipa> cfields: which is oerhaps a cleaner abstraction than hardcoding a particular stream protocol?
11:04 -!- t800 [~t800@mail.werk1.at] has joined #bitcoin-core-dev
11:04 < sipa> jonasschnelli: another suggestion: i think we should drop the network magic... resynchronization after garbage hasn't been supported in a long time, it wastes (a tiny bit of) bandwidth, and makes the encrypted stream look decidedly identifiable (though if encrypted connections bootstrap as unencrypted ones, that isn't solvable)
11:05 < gmaxwell> Alice connects to Bob, Alice sends,  Nonce_a, and alice ephemeral pubky (AEP), bob sends nonce_b and BEP.   ECDH runs,  then a KDF that takes the two nonces, and ecdh output, and spits out a session id and two keys (one for each direction.   Then Alice proposes, "I think you have identity X=H(bob pubkey, session_id)", if this is true, bob responds with "I am rekeying with IDX"  and takes his cur
11:05 < gmaxwell> rent encryption key and changes it to H(bob pubkey|enckey).  When alice sees that message she updates her keys for the stream. Then also does the same herselve (sends a message, updates key). Then bob sends a signature with his pubkey.     Then this authentication procedure can just be repeated every so many bytes in order to rotate the stream cipher keys.
11:05 < gmaxwell> If the 'public keys' are kept private, the link has at least symmetric keyed integrity and confidentality, even with an ECC break.
11:08 -!- kx [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has joined #bitcoin-core-dev
11:14 -!- kx [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has quit [Quit: Page closed]
11:17 -!- kangx [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has joined #bitcoin-core-dev
11:23 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
11:25 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
11:27 -!- frankenmint [~frankenmi@174.25.22.102] has quit [Remote host closed the connection]
11:28 < wumpus> <sipa> which means that an attacker can't even see the message sizes, except by traffic analysis <- I think that would be quite essential for bitcoin, as so much can already be identified from the packet sizes
11:28 < wumpus> certain blocks, certain transactions, etc
11:30 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
11:31 < gmaxwell> I had assumed that the encrypted transport would encapsulate one or more length coded messages inside it... so mostly you'd just see the 'send units'.  Doing this would alow avoiding that extra layering, however... and thus decrease overhead.
11:32 < gmaxwell> though perhaps we should make the encoding support padding, so that messages can be padded up to particular size multiplies, to reduce the traffic analysis sidechannel.
11:34 < CodeShark> is there a meeting today?
11:34 < gmaxwell> yes, in about 20 minutes.
11:35 < gmaxwell> You've suffered DST. :)
11:36 < btcdrak> we dont suffer it over this side of the Atlantic until Sunday
11:38 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 244 seconds]
11:38 < btcdrak> gmaxwell: is it maybe worth adding a version byte to the encryption scheme to allow upgrades in the future?
11:38 < jonasschnelli> gmaxwell: +1 for padding to reduce sidechannel identification.
11:39 < jonasschnelli> sipa: do you mean dropping the network magic for all post-encryption-init messages?
11:39 < sipa> also +1 to allowing multiple messages in a packet
11:39 < jonasschnelli> You mean one header with a message count int followed by n payloads?
11:39 < sipa> jonasschnelli: yes, it serves no purpose other than detecting accidental connection to the wrong network
11:40 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:40 < sipa> jonasschnelli: or just a concatenation of payloads even
11:40 < jonasschnelli> Okay. size + payload + size + payload, etc. That makes sense.
11:41 < sipa> jonasschnelli: inside the aead
11:42 < gmaxwell> that cuts down on the authentication overhead.
11:42 < jonasschnelli> sipa: But I still try to understand your AES GCM 96bit IV solution. How would you create distinctable IV  without transmitting in in the message?
11:43 < sipa> jonasschnelli: use 0000 + counter for one side, use 1111 + counter for the other?
11:43 < jonasschnelli> sipa: Are predictable IVs not a problem?
11:43 < sipa> jonasschnelli: no, just no reuse
11:43 < sipa> ivs are nkt secret
11:43 < sipa> *not
11:44 < jonasschnelli> Okay. I see.
11:44 < gmaxwell> sipa: AEAD packet size does imply memory usage implications though.
11:45 < gmaxwell> but its maximum could just be the same as the largest message.
11:45 < sipa> right
11:45 < jonasschnelli> So. Changes i'll work on a) ecdh exchange for both direction, two sym. keys, fix synchro. b) use chacha20 poly1305 instead of AES GCM c) optimize message structure (drop magic, allow multiple payloads in the AEAD part)
11:46 < sipa> jonasschnelli: no need to fix synchronization if both directions are independent
11:47 < jonasschnelli> yes. I mean fix syncho by using two keypair, one per direction.
11:47 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 240 seconds]
11:48 < gmaxwell> great.
11:48 < jonasschnelli> Has chacha20-poly1305 been proven to be stable? Reasonable amount of cryptanalysis? Or do we threat stuff out of DJB's kitchen as stable anyways? :)
11:48 -!- gevs [~greg@unaffiliated/gevs] has quit [Read error: Connection reset by peer]
11:48 < gmaxwell> jonasschnelli: it's part of TLS and SSH.
11:48 < gmaxwell> I think it's sutiable for our purposes.
11:48 < wumpus> it's geting a lot of testing and review in ssh at least
11:49 < jonasschnelli> Okay. And how complex is an implementation? Or would this lead to a revival of openssl in core?
11:49 < gmaxwell> it's very simple.
11:49 < wumpus> their implementation is very short, that's one thing that is so cool about it
11:49 < jonasschnelli> what speaks again unsing openssl (p2p layer enc is non consensus)?
11:49 < jonasschnelli> *against
11:50 < gmaxwell> we're not taking 400,000+ lines of unreviewable, frequently CVEed code for this; I'd rather not have the functionality.
11:50 < wumpus> attack surface, making it impossible to get rid of openssl dependency
11:50 < wumpus> and you can already do it using stunnel
11:51 < gmaxwell> I hope that this works so that even if we don't care about the confidentiality improvement, it's just simply faster than the existing transport.
11:52 < jonasschnelli> Right. I think dropping the sha256 per message could be an improvement in performance.
11:52 < jonasschnelli> combining multiple messages into one encrypted message also
11:53 < jonasschnelli> The question is, how to "bundle" messages (example: bundle invs). When releasing them, etc. I mean for the implementation.
11:53 < gmaxwell> https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html has some benchmarks vs AES-GCM fwiw.
11:53 < sipa> jonasschnelli: we already do that
11:53 < sipa> jonasschnelli: SendMessages is a function in main that computes a block of messages to send at once
11:53 < jonasschnelli> Ah. But they get sent individually (one inv per msg)?
11:54 < sipa> jonasschnelli: maybe you should look into how our current protocol works :)
11:54 < jonasschnelli> haha. True.
11:54 < sipa> no, an inv messages can contain up to 5000 invs
11:55 < jonasschnelli> Okay. So where would we benefit from bundling messages in one encrypted message?
11:55 < wumpus> it makes sense to make it possible, it benefits privacy
11:55 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Quit: Leaving]
11:56 < sipa> well, if you take as baseline an implementation that encrypts message sizes, there is no privacy benefit to bundling
11:56 < wumpus> even if your first implementation doesn't actually use it, imo the protocol should support it
11:56 < gmaxwell> phantomcircuit had a patch to add corking and uncoarking in the message handling loop, I presume something similar would be done for message batching.
11:56 < jonasschnelli> agree
11:56 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
11:56 < wumpus> ok, yes, no privacy benefit to bundling makes it less important to me
11:56 < sipa> as they would be sent back-to-back, so traffic analysis would not let you discover independent messages
11:56 < gmaxwell> e.g. we'd cork both the crypto and tcp, do all the message handling for a peer, then uncork both. 
11:57 < sipa> however, bundling does give a small bandwidth improvement, as you'd share a authentication tag acorss muktiple messages
11:57 < wumpus> well, let's not micro-optimize before we have anything
11:57 < jonasschnelli> tag is 12bytes. Right.
11:58 < gmaxwell> not necessarily all that small, the auth is relatively large to our average message size.
11:58 < wumpus> let's first make sure it is secure, then wonder about bandwidth optimization
11:59 < jonasschnelli> Right. I'll try to update the Bips with what we have discusses and ask for another review.
11:59 < jonasschnelli> *discussed
11:59 < wumpus> trying to tackle everything at once is going to make this go nowhere, I'm afraid
11:59 < gmaxwell> the bundling also makes padding easy, you just define a new message type "pad" that is just discarded on the other end. :)
11:59 < sipa> jo	16 if you want 128 bit security
11:59 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:59 < gmaxwell> yea, iteration is fine.
11:59 < jonasschnelli> should i say now: "perfect is the enemy of good". Yes? No. *duck*
12:00 < MarcoFalke> meeting time?
12:00 < gmaxwell> Meeting time.
12:00 < wumpus> jonasschnelli: more like: keep your goal focused. Your goal  is security and privacy, first. Make no dumb mistakes there ;)
12:00 < jonasschnelli> RIght!
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Mar 24 19:00:25 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < wumpus> jonasschnelli: scope creep is a very bitcoin-y thing
12:00 < wumpus> ok, topic proposals?
12:01 < MarcoFalke> python 3 and rpc tests?
12:01 < wumpus> from last meeitng we have ACTION: merge #7575 (wumpus, 19:04:04)  ... that was done
12:01 < btcdrak> softfork #7648 status
12:01 < wumpus> next was ACTION: review #7648 after #7575 is merged (wumpus, 19:09:39)
12:01 < Luke-Jr> topic proposal: v0.11.3 and v0.10.5
12:01 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:01 < wumpus> how is that going?
12:01 < wumpus> #topic softfork #7648 status
12:02 < wumpus> MarcoFalke: will get to python3 at the end, I think the softfork stuff is most important right now
12:02 < btcdrak> #7648 has received some tested ACKs.
12:02 < MarcoFalke> sure
12:03 < wumpus> okay, good
12:03 < wumpus> I think it needs more review still
12:04 < btcdrak> time to crack the whip.
12:04 < wumpus> for a softfork the bar is somewhat higher than for random pull #1234
12:04 < wumpus> yes
12:05 < jonasschnelli> 7648 looks good and will also review it in details soon (during weekend)
12:05 < wumpus> I mean I've seen some acks but very little comment on the actual code, that could be a sign everything is perfect, or people need to look better 
12:05 < wumpus> thanks jonasschnelli
12:05 < btcdrak> MarcFalke: can you look as well please?
12:05 < wumpus> #action review more at https://github.com/bitcoin/bitcoin/pull/7648
12:05 < btcdrak> and CodeShark
12:05 < wumpus> I'll take a more in-depth look at it as well
12:05 < btcdrak> ty
12:05 < MarcoFalke> sure
12:06 < gmaxwell> has anyone looked to see if there are MTP violations still being accepted on the network? 
12:06 < gmaxwell> I wouldn't consider them a hard blocker to 113 deployment, but if any are, we should make a concerted effort to extinguish them first.
12:07 < btcdrak> gmaxwell: there should be 100% coverage of 113 since the upgrade to 0.11.2
12:07 < gmaxwell> btcdrak: there may be miners with order or modified code, however.
12:07 < gmaxwell> er, s/order/older/
12:07 < sipa> s/may be/are/
12:08 < gmaxwell> if there are any, we should try to find them and get them to stop mining MTP violations.
12:09 < wumpus> yes
12:09 < gmaxwell> I can work on this.
12:09 < cfields> sipa: missed you earlier. ack on allowing for chunked decrypt/decode.
12:10 < btcdrak> cfields: can you put 7648 review on your tasklist too please?
12:10 < wumpus> #action hunt down miners that mine MTP violations
12:10 < cfields> btcdrak: yes
12:11 < wumpus> ok
12:11 < wumpus> next topic I guess
12:12 < wumpus> #topic proposal: v0.11.3 and v0.10.5
12:12 < sipa> we discussed what would go in last week; did anythkng chang
12:12 < sipa> ?
12:13 < wumpus> I don't know, luke-jr requested the topic
12:13 < btcdrak> well we didnt discuss 0.10.5, we discussed 0.12.1
12:13 < Luke-Jr> I'm going through https://github.com/bitcoin/bitcoin/pull/7047 again, to check everything included is in 0.12 and make it mergable again
12:14 < wumpus> that's way too much for a softfork release at least
12:14 < Luke-Jr> what isn't clear to me is what the plan is for v0.11.3 being released - I assume wumpus is doing that at some point? - and whether I'm taking over for v0.10.5, or if wumpus wanted to do one final 0.10 before passing it off
12:14 < wumpus> for a normal minor release it'd make more sense
12:14 < wumpus> yes I'll do the 0.11.x release
12:14 < MarcoFalke> 7047 also includes a lot of "comment-fixed". I am not sure if they are useful in our branch
12:15 < gmaxwell> whats deployment of 0.11.2 vs 0.12 look like right now? 
12:15 < MarcoFalke> I'd rather only have bugfixes
12:15 < wumpus> I'll leave 0.10.x to you 
12:15 < Luke-Jr> are we doing a softfork release in the next month?
12:15 < sipa> Luke-Jr: i say yes
12:15 < Luke-Jr> ok, so then we should let these things wait until after that
12:15 < wumpus> I think we should do a softfork release asap
12:15 < Luke-Jr> or maybe I should go through it and make sure there's nothing important
12:15 < wumpus> let's just get those stupid things reviewed and merged
12:15 < jonasschnelli> As soon as #7648 has been reviewed more and merged 
12:16 < wumpus> jonasschnelli: and backports reviewed and merged ofc
12:16 < wumpus> but yes 7648 is the first step
12:16 < jonasschnelli> RIght
12:16 < Luke-Jr> (also, depending on ease of backporting the softforks, I may decide to just give up on 0.10 support; tbd)
12:16 < btcdrak>  /Satoshi:0.12.0/	1713
12:16 < btcdrak>  /Satoshi:0.11.2/	1387
12:16 < jonasschnelli> 0.10 can be given up IMO
12:16  * jonasschnelli is checking his seeder data
12:17 < gmaxwell> Luke-Jr: I think absent someone requesting otherwise (and perhaps funding your effort) you probably should.
12:17 < Luke-Jr> jonasschnelli: it's currently Gentoo stable, so at the very least I will need to bump that
12:17 < btcdrak> The problem with 0.10 is we all need to put review time into the backports and that's difficult when we have trouble even reviewing backports for 0.11
12:17 < petertodd> btcdrak: +1
12:17 < Luke-Jr> btcdrak: most backports are trivial, but for softforks I agree if they're not a clean backport
12:18 < wumpus> right
12:18 < btcdrak> I think if there is a 0.10.5 release it should be extremely minimal... and frankly, backporting BIP68 wont be fun or easy.
12:18 < sipa> bip68/112/113 are quite a bit of code
12:18 < wumpus> let's spend our energy on moving forward
12:18 < jonasschnelli> 0.10 should be last priority. If someone offers to do that: fine.
12:18 < gmaxwell> plus, a far backport which is done by one person and used by few more likely won't be materially more stable than a more recent release.
12:18 < Luke-Jr> ok, so for 0.10 I'll see the complexity in the softfork backports, and if it's anything more than absolutely trivial, I'll just decide to drop it
12:18 < btcdrak> Luke-Jr: even BIP68 backport to 0.11 was tricky, not a clean cherry-pick.
12:18 < Luke-Jr> btcdrak: well, I'd be backporting to 0.10 *from* 0.11
12:19 < jonasschnelli> at dnsseed.dump | grep "  100.00% 100.00%" | grep "/Satoshi:0.10." | wc -l       ---> 266
12:19 < sipa> we can still do critical security updates for 0.10 without choosing to backport sotfork
12:19 < wumpus> sure
12:19 < jonasschnelli> 6.3% 0.10.x nodes
12:19 < btcdrak> so on this topic, people need to also look at backport #7543 
12:19 < Luke-Jr> and for 0.11, sounds like the plan is to do a softfork-only release before any non-essential bugfix backports
12:20 < CodeShark> +1 jonasschnelli 
12:20 < petertodd> sipa: and people who need a v0.10.x node for software compatibility reasons can generally run it behind a newer node
12:20 < sipa> petertodd: also true
12:20 < wumpus> #action people need to also look at backport #7543: [0.12] Backport BIP9, BIP68 and BIP112 with softfork
12:20 < sipa> petertodd: specifically, behind a 0.11 or 0.12 pruned one :)
12:20 < petertodd> sipa: yes! that too
12:20 < Luke-Jr> #action 0.10: attempt to backport softforks, and if non-trivial, discontinue support
12:21 < Luke-Jr> #action 0.11: no non-essential fix backports until softfork release
12:21 < Luke-Jr> #action bump Gentoo stable to 0.11 (from 0.10)
12:21 < sipa> Luke-Jr: support is already discontinued according to policy, only critical biffixes
12:21 < sipa> *bugfixes
12:21 < CodeShark> I'd say discontinue support for 0.10 unless someone wishes to provide resources for it
12:22 < wumpus> well if luke-jr wants to try to backport the softfork that's up to him
12:22 < Luke-Jr> sipa: policy only dictates guaranteed support, not guaranteed to end
12:22 < sipa> wumpus: sure, but i don't think that's very relevant here
12:22 < wumpus> no need to even discuss it here :p
12:22 < wumpus> right
12:22 < btcdrak> #action 0.11 review #7716 Backport BIP9 and softfork for BIP's 68,112,113
12:22 < Luke-Jr> any more topics?
12:23 < sipa> as soon as we have 0.12.1, i will rebase segwit on top, so segnet can benefit from its bip9/68/112/113 support
12:23 < cfields> can give a quick update on the net refactor
12:23 < wumpus> I'd say spend the rest of the meeting time reviewing #7648 :p
12:23 < wumpus> sure cfields!
12:24 < wumpus> #topic cfields net refactor
12:24 < sipa> please, stick to the net refactor, not the gross one
12:24 < cfields> i finally have a working full-featured branch. it's a mess code-wise, but i think it should be approachable in the next day or two after some code movement. I expect to be looking for concept review next week
12:24 < gmaxwell> cfields: start taking, I can't take the wait.
12:25 < wumpus> lol
12:25 < wumpus> cfields: I've been testing it on a node btw for last week, seems to be stable and working 
12:25 < wumpus> haven't looked at details of performance etc but no crashes or insane log entries
12:26 < btcdrak> sipa: you can cherry-pick from  #7543 in that case
12:26 < cfields> wumpus: that's great to hear. lots has changed since then, but the core is the same
12:26 < cfields> i think i have an idea of how to handle code review, but i'd like to get some concept acks first...
12:26 < wumpus> you got my concept ack at the boston meeting
12:26 < sipa> and mine
12:27 < cfields> there's a huge mix of code movement, a new lib, abstraction, etc. I think i have a plan for getting it slotted in
12:27 < wumpus> great
12:27 < cfields> ok. i can start PRing chunks into core as i go, then
12:27 < Luke-Jr> cfields: practical to add block streaming? ;)
12:28 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
12:28 < cfields> first step is getting the net stuff instanced. that's a lot of movement without much functional difference
12:28 < gmaxwell> do not creep cfield's scope. :P
12:28 < wumpus> please, let's replace the current things first, then add additional features
12:28 < jonasschnelli> hah
12:28 < wumpus> example gmaxwell
12:28 < wumpus> exactly*
12:28 < cfields> i think that can start going in parallel
12:28 < cfields> gmaxwell: heh, i've adjusted scope so many times now that i'm certainly not budging again :p
12:28 < jonasschnelli> The net refactor will be very hard to review already. Lets keep it as simple as possible.
12:28 < wumpus> that's good, stand your ground , people here are awful :)
12:28 < cfields> turns out the absolute minimum scope for net refactor is already enormous
12:29 < jonasschnelli> Indeed.
12:29 < wumpus> yes it'll already be challenging to get this done before 0.13 I think, but we have to try
12:29 < Luke-Jr> gmaxwell: indeed, just hope we don't need to refactor it again after
12:29 < sipa> Luke-Jr: we absolutely will
12:29 < cfields> wumpus: yes, it's much later than I was hoping for. If it slips past 0.13, I'll understand.
12:29 < sipa> but at different layers :)
12:30 < wumpus> right, this is only the bottom layer
12:30 < cfields> sipa: well the hope is that it's been split up into chunks that can be changed in the future much easier
12:30 < sipa> cfields: yes, that's what abstractions are for
12:31 < jonasschnelli> topic: Should we shorty touch how we should proceed with sipas CT AES implementation? Extract to library? Yes/No?
12:31 < cfields> there are a few hacks that i'm not going to mess with for now. For ex, even though it's all instanced, there's still a g_connman that's used liberally as opposed to the clean way of passing the instance around
12:31 < wumpus> meh
12:31 < cfields> i'll start working on a list of todos so that some of the decisions are more clear
12:32 < petertodd> jonasschnelli: extract is a great idea I think - don't have to be fancy, just enough to continue to set a better standard than "roll our own"
12:32 < sipa> cfields: just PR it! i want to see the code :)
12:32 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
12:32 < jonasschnelli> sipa: code: https://github.com/theuni/bitcoin/tree/net-refactor8
12:32 < cfields> sipa: i'm still frantically coding it :)
12:32 < sipa> ah.
12:33 < cfields> jonasschnelli: nooooooo. everyone shield your eyes from that :)
12:33 < wumpus> the code is actually buildable and works
12:33 < sipa> now i have a moral obligation to actually go look, right?
12:33 < wumpus> well test at least :)
12:33 < btcdrak> cfields: love that last commit message :)
12:33 < cfields> sipa: with the understanding that it's basically my /tmp :)
12:33 < jonasschnelli> cfields: We all know how code during implementation can look. No shame for it!
12:34 < wumpus> yes :)
12:34 < jonasschnelli> petertodd: I'm also for extracting.
12:34 < jonasschnelli> Simple autotools setup, add as subtree place on bitcoin/libctaes (or similar)
12:34 < wumpus> #topic CT AES library
12:35 < Luke-Jr> what is "CT" for here?
12:35 < wumpus> I don't think extracting it into a library has to affect our use of it
12:35 < petertodd> jonasschnelli yup, subtree is fine
12:35 < wumpus> Constant Time
12:35 < jonasschnelli> constant time
12:35 < Luke-Jr> ah
12:35 < sipa> i feel like it's more a code snippet than a library
12:35 < gmaxwell> constant time.
12:35 < wumpus> yes, it's more like a snippet
12:35 < gmaxwell> "Petertodd raised verification concerns for the internal AES implementation. I could suggest some strategies on that." is what I wrote earlier. :P
12:36 < wumpus> crypto has a rich tradition of copy/paste
12:36 < cfields> fwiw, I plan on doing the same with libbtcnet
12:36 < jonasschnelli> wumpus: I think placing stuff in libraries follows a modular approach  which is desirable for Bitcoin IMO
12:36 < Luke-Jr> +1 for libctaes
12:36 -!- jcorgan [~jcorgan@89.206.243.160] has joined #bitcoin-core-dev
12:36 < cfields> i have a tiny/crappy makefile that i use to build it externally, but I plan to just copy/paste it into Core and keep it in sync
12:36 < petertodd> sipa: well, to be clear, you did write that code snippet from scratch yourself right?
12:36 < wumpus> you could stil include it in a library, but please don't compilicate the build
12:36 < Luke-Jr> cfields: libbcnet I hope; what does the BTC unit size have to do with networking? :P
12:36 < gmaxwell> in any case, I'm not convinced that the standard test vectors prove the code correct. Beyond soliciting outside review, which btcdrak has done.  I was going to suggest trying some mutation testing to see if some additional better test vectors can be constructed.
12:36 < jonasschnelli> sipa: Its a snipped now, ... but we all know how snippets evolve over time.
12:37 < cfields> Luke-Jr: when i googled "libp2p" some etherium thing came up :)
12:37 < sipa> petertodd: yes, though the logic gates for the sbox come from a paper
12:37 < wumpus> I think we should separate concerns here: getting the code into a library, and getting the damn code reviewed
12:37 < wumpus> the first is easy, just work
12:37 < Luke-Jr> cfields: oh great, let's just integrate that! :P
12:37 < petertodd> sipa: right, so it's independent work, which means it's crypto we wrote, which means no matter how small it is, we should at least make a token effort to try to let independent use and review :)
12:37 < Luke-Jr> wumpus: I don't feel competent to review crypto code :<
12:37 < wumpus> Luke-Jr: me neither.
12:38 < wumpus> Luke-Jr: so we'll have to find someone that can, btcdrak had some ideas.
12:38 < gmaxwell> You're all competent to review if the code is constant time or not.
12:38 < sipa> or that it has test coverage
12:38 < jonasschnelli> What about apoelstra?
12:38 < gmaxwell> And probably no one is competent to review if it's correct, fortunately AES is a permutation, which does make confidence building via testing easier.
12:38 < wumpus> but not if it's correct AES, or has some weird edge cases, mathatical inconsistencies, or other wacky side channels
12:38 < wumpus> right
12:39 < sipa> and notice it has no tables or branches, so it would be exceedingly hard to make it broken in a very small number of cases
12:39 < jonasschnelli> IMO that all speak for splitting it off into a own library.
12:39 < petertodd> gmaxwell: the problem here, is I don't know enough about the problem to know if I'm actually competent to review that
12:39 < gmaxwell> (by no one, I mean no human. :) )
12:39 < btcdrak> petertodd: I asked isis to take a look on a paid basis.
12:39 < petertodd> btcdrak: good!
12:39 < gmaxwell> petertodd: the requirement is that there should be no leakage of the secret state (key or data) in the timing of the program on any hardware we support.
12:39 < btcdrak> that's @isislovecruft from Tor for anyone that doesnt know.
12:40  * Luke-Jr volunteers to do the splitting-off-into-library work if sipa doesn't want to
12:40 < sipa> anyway, i'll turn it into a .c/.h; if someone else wants to actually do the work for autotools etc, go ahead.
12:40 < jonasschnelli> Luke-Jr: I already have started that. :)
12:40 < wumpus> Luke-Jr: this will again trigger the subtree-or-external discussion, I can't take that another time
12:40 < wumpus> Luke-Jr: and linux distributions messing it up etc
12:40 < gmaxwell> it will not be external.
12:40 < Luke-Jr> wumpus: seems that discussion should be project-global, not per-lib
12:40 < jonasschnelli> sipa: I have checked to code and it looks pretty Cish.
12:41 < Luke-Jr> subtree-with-configure-option seems to work
12:41 < sipa> imho, it can be a separate repository without being a library
12:41 < sipa> just copy it into your project if you neeed it
12:41 < wumpus> right.
12:41 < sipa> it's a single file and has no intention to grow beyond that
12:41 < gmaxwell> nor any utility to grow beyond that.
12:42 < jonasschnelli> meh. Adding a build setup should be trivial and would hurt nobody?
12:42 < cfields> sipa: is there enough non-standard stuff to necessitate a buildsystem? or would a simple makefile do?
12:42 < wumpus> the API will never change, the implementation will hopefully also never change (excluding critical problems)
12:42 < sipa> cfields: it will be a single C89 file with no dependencies beyond stdint
12:42 < Luke-Jr> stdint isn't C89, though?
12:42 < gmaxwell> wumpus: the only 'change' I could imagine for it is wrapping it with something that uses AESNI when available instead.
12:42 < sipa> Luke-Jr: it indeed isn't, which is why i mention it :)
12:42 < cfields> sipa: ah great
12:42 < gmaxwell> well C89+stdint, or C99...
12:43 < gmaxwell> stdint is almost universal even in terrible embedded complilers.
12:43 < jonasschnelli> Are there no plans to extend the "lib" with more stuff? Like for a possible p2p encryption?
12:43 < wumpus> and if not it's easy enough to define the types yourself
12:43 < Luke-Jr> jonasschnelli: well, then the name libctaes would be wrong
12:43 < sipa> jonasschnelli: i'd do that on another layer
12:44 < jonasschnelli> Right.
12:44 < wumpus> no, jonasschnelli, that should be something else yet again
12:44 < sipa> jonasschnelli: it would still rely on aes primitives
12:44 < gmaxwell> This pressure to constantly create "libraries" to dump things in is streesful for me. A well constructed library is a serious amount of work in and of itself.
12:44 < wumpus> ctaes would be constant time aes :-) I don't think you want/need that for the p2p
12:44 < petertodd> gmaxwell: I may have to use a climbing analogy to get my point accross here :) sure, I can easily read a book on knots and belay systems and feel like I _should_ know everything I need to know to do that stuff safely, but the consequences of failure are high enough - and the field unusual enough - that I'm going to insist I check things out with others generally accepted as experts first - who cares how irrational ...
12:44 < jonasschnelli> Okay. Then we might agree in a subtree with just a .c/.h instead of a autotools setup.
12:44 < petertodd> ... that feels. I think general standards for low-level crypto implementations tend in that direction.
12:45 < wumpus> jonasschnelli: yes
12:45 < petertodd> jonasschnelli: yes, just a .c/.h is fine! like I said, bare minimum to set a precedent that we're trying to invite outside review
12:45 < Luke-Jr> subtree with just .c/.h until some future time when someone decides to lib-ify it seems ok
12:45 < wumpus> jonasschnelli: that's very common for crypto
12:45 < sipa> and maybe for performance reasons, it makes sense to use a more complicated faster implementation, and maybe also warrants more maintainance afterwards if it's going to be adopted by other prijects for the purpose of p2p encryption
12:45 < jonasschnelli> okay.
12:45 < gmaxwell> petertodd: considering that basically all AES-CBC software (not AESNI) out there is gratitiously timing vulnerable, and we were going to take such a patch ourselves before; I feel you're compent enough to review and increase confidence, if not alone to achieve perfection. 
12:45 < Luke-Jr> sipa: seems likely other wallets may use it
12:45 < jonasschnelli> agree on bitcoin/libctaes?
12:45 < wumpus> and just copy/subtree the thing into your project and include it into your build system, all the dependency micro management isnt' worth it for everything
12:46 < sipa> Luke-Jr: they absolutely may!
12:46 < jonasschnelli> Luke-Jr: right.  I have two projects where i will use it immediately. 
12:46 < wumpus> jonasschnelli: bitcoin-core/libctaes it would be then
12:46 < gmaxwell> as I noted before, this implementation is not super fast. We have no need to make it super fast. It may be of idependant interest to others because it is quite small.
12:46 < sipa> Luke-Jr: but for wallets, it has no performance requirements
12:46 < jonasschnelli> wumpus: ah. Right. The moving.
12:46 < sipa> Luke-Jr: which is why it's easy, and needs no dependencies on assemblers or instruction sets, or simd extensions, or ...
12:47  * Luke-Jr not sure libctaes makes sense as bitcoin-core as opposed to just bitcoin, but meh
12:47 < petertodd> gmaxwell: yeah, I probably am - I also learned how to do climbing/caving ropework by buying a book on it, some equipment, and going out to find some trees to practice on. Doesn't mean it was a good idea. :) just having a separate repo with a bare .c/.h goes a long way to making our intentions clear and having good precedents, even if pragmatically we need a solution right now.
12:47 < wumpus> jonasschnelli: which reminds me, I think I still need to add you to that project
12:47 < jonasschnelli> bitcoin/ should be consensus critical stuff
12:47 < wumpus> jonasschnelli: we're not actually doing anything with it at the moment
12:48 < wumpus> jonasschnelli: right
12:48 < jonasschnelli> +1 ;-)
12:48 < cfields> topic has strayed a bit :)
12:48 < wumpus> yes
12:48 < sipa> petertodd: ok, agreed
12:49 < petertodd> sipa: thanks!
12:49 < wumpus> #topic convert python RPC tests to python 3
12:49 < gmaxwell> I am disappointed that all of this time is being wasted over faffing about libraries, for code that has very narrow independant interest and likely against the wishes of its author. .. and no one commented on further verification strategy.
12:49  * gmaxwell sees topic is over.
12:50 < MarcoFalke> I think it's cleaner to just switch to py3
12:50 < petertodd> wumpus: concept ack!
12:50 < MarcoFalke> but I'd like to hear any drawbacks first.
12:50 < wumpus> gmaxwell: I agree, I think this will do just as well as a code snippet, but I don't think discussing this further is constructive. The people that want a library so bad can work on it I guess :)
12:50 < Luke-Jr> py3 vs py2, I can think of no drawbacks to exclusively py3
12:50 < wumpus> as you may have read in https://github.com/bitcoin/bitcoin/issues/7717, the next release of ubuntu, 16.04, xenial something will no longer ship python 2
12:50 < btcdrak> MarcoFalke: agreed
12:51 < jonasschnelli> Is  the reason for the py3 switch the deprecating of py2 or the missing of it in some of the distributions?
12:51 < wumpus> I think this makes a nice moment to decide on a switch
12:51 < MarcoFalke> ok, so I will close the "refactor py2 code" pull and just go py3 only
12:51 < wumpus> we're modernizing the build environment anyway by starting to rely on c++11
12:51 < wumpus> MarcoFalke: it's the first step right
12:51 < jonasschnelli> ACK on py3... the RPC tests are not something we need "full portability".
12:51 < wumpus> for the build system I have py2+py3 compatibility ready
12:51 < Luke-Jr> actually, we should retain support py2 at least initially
12:52 -!- jcorgan [~jcorgan@89.206.243.160] has quit [Quit: Lost terminal]
12:52 < Luke-Jr> since we may need to backport
12:52 < wumpus> for the RPC tests I don't think that is necessary
12:52 < petertodd> I'm not sure there exist any build environments that we need to support that are py2 only
12:52 < wumpus> agree petertodd
12:52 < jonasschnelli> agree with petertodd 
12:52 < cfields> agreed
12:52 < sipa> agree, the backport trees could also just switch to py3
12:52 < Luke-Jr> if it's not much effort, moving to py2+py3, and then to py3 before 0.13 would be best
12:52 < wumpus> Luke-Jr: that's a lot more work
12:52 < Luke-Jr> if it's a lot more work, forget it
12:53 < wumpus> I did that for scripts used by the build system itself
12:53 < wumpus> but the test framework is huge
12:53 < wumpus> and it's a lot of work for people to make sure it works for both python versions
12:53 < MarcoFalke> considering that the current rpc test are full of bugs due to missing maintanance and review, doing a py2+3 coverage is impossible
12:53 < wumpus> for every change
12:53 < sipa> i think we should just outright switch to py3
12:53 < jonasschnelli> Yes. No backward comp. for test script please.
12:53 < petertodd> fwiw, I'm somewhat in favor of making my own python-bitcoinlib py3-only, simply because I personally never use it on py2, which makes me worried I'm missing bugs
12:53 < wumpus> exactly, practical concerns kind of rule this out
12:54 < btcdrak> I think we should switch to py3 outright also
12:54 < wumpus> that's clear, then
12:54 < jonasschnelli> And kudos to MarcoFalke for working on this!
12:54 < wumpus> yes!
12:54 < btcdrak> +1
12:55 < MarcoFalke> You can pipe the files through 2to3 and then "only" check the diff.
12:55 < wumpus> ok, that concludes the topic I guess, I'm happy we can finally agree on something :)
12:55 < cfields> yes, it's much easier for us than most because it's all internal and we really have no downstreams to cater to
12:55 < wumpus> more topics?
12:55 < wumpus> 5 minutes to go
12:56 < gmaxwell> Lets end early.
12:56 < MarcoFalke> #action Close https://github.com/bitcoin/bitcoin/pull/7722 and switch to py3
12:56 < wumpus> great
12:56 < wumpus> #endmeeting
12:56 < lightningbot> Meeting ended Thu Mar 24 19:56:39 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:56 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-24-19.00.html
12:56 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-24-19.00.txt
12:56 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-24-19.00.log.html
12:57 < GitHub184> [bitcoin] btcdrak opened pull request #7741: [0.12] Mark p2p alert system as deprecated (0.12...alert0) https://github.com/bitcoin/bitcoin/pull/7741
12:57 < jonasschnelli> sipa: how would you support test if the ctaeslib is just a c./.h?
12:57 < jonasschnelli> Add a test.c and a Makefile?
12:57 < gmaxwell> with a define.
12:57 < gmaxwell> #ifdef CTAES_TESTS  int main()...
12:57 < sipa> i preferna test.c
12:58 < sipa> as it's perfectly externally testable
12:58 < Luke-Jr> in this case, it may be wise to have a function for tests that software can call at startup
12:58 < gmaxwell> sipa: k.
12:58 < Luke-Jr> ie, refuse to start if the AES code fails its own testws
12:59 < gmaxwell> well a test harness for verification may be very different than built in selftests.
12:59 < Luke-Jr> sure
12:59 < petertodd> test harness for the constant-time functionality is probably going to be a lot less portable than the code itself for instance...
13:00 < gmaxwell> well for example, a verification test harness would likely contain another whole implementation of AES. :)
13:00 < cfields> sipa: just pushed the code-movement to net-refactor8 branch. Still lots of placeholders, todos, and hacks in there, but it now looks overall how i want it to
13:02 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
13:03 < sipa> gmaxwell: hmm... about tests; the s-box implementation is the most obscure/unreviewable/largest part of the code... but it's trivial to.test exhaustivelg against another implementation, as it only deals with 32-bit inputs
13:05 < sipa> ah, nvm
13:05 < gmaxwell> sipa: right. an exhaustive sbox test, e.g. with forward sbox pulled out of another implemetation. and checking forward and reverse. And then I thought it might be interesting to see if the existing vectors are enough to catch any simple or or two byte mutations in the current implementation. And if not, we could add vectors until they are.
13:05 < gmaxwell> why cant the sbox be exaustively tested?
13:06 < sipa> gmaxwell: not as a black box; its inputs are 8 16-bit integers (and.it does 16 sbox applications in parallel)... you can't exhaustive test 128 bits (i hope)
13:07 < gmaxwell> right. well it could test each lane one at a time.
13:07 < sipa> if you can inspect the code and see that it's "obviously" doing the same thing for every bit position, it suffices to test just the 2^8 inputs
13:08 < sipa> petertodd: how is the bip9 warning code broken?
13:08 < sipa> (re: github pr)
13:08 < petertodd> sipa: oh, I spoke to soon on that - but it was more confusing than it should have been, which I'll fix next week when I get back after the long weekend
13:08 < sipa> petertodd: the warning logic uses bit positions; the trigger code uses DeplymentPos
13:09 < sipa> (i agree DeploymentId is better)
13:09 < petertodd> sipa: yeah, simple enough pull-req, and I've got a few more improvements re: adding comments that I'll add to it too
13:09 < sipa> great!
13:10 < petertodd> oh, one thing I forgot to ask: if I understand it correctly, right now changes to the "meta-version" - the top three bits - do *not* trigger a "network may have upgraded warning"
13:10 < sipa> petertodd: they do if it's permanent
13:10 < petertodd> sipa: ah, alright, I'll go look at that more then and verify
13:10 -!- gevs [~greg@ip-80-236-245-236.dsl.scarlet.be] has joined #bitcoin-core-dev
13:10 -!- gevs [~greg@ip-80-236-245-236.dsl.scarlet.be] has quit [Changing host]
13:10 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
13:11 < sipa> there is the 50% of last blocks habe unexpected version warning still
13:11 < petertodd> sipa: ah, ok, good
13:11 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has quit [Read error: Connection reset by peer]
13:11 < sipa> in addition, there is warning logic for each bip9 bit position, which works retroactively
13:11 < petertodd> sipa: anyway, probably best I don't ask too many more questions to keep my mind uncontaminated with what you guys think the code should be doing :)
13:12 < sipa> petertodd: good strategy
13:12 < petertodd> bbl - have a good long weekend!
13:13 < cfields> wumpus: https://github.com/travis-ci/travis-build/pull/680
13:14 < cfields> one step closer, i hope
13:16 < wumpus> cfields: wow! finally :)
13:16 -!- hybridsole [~hybridsol@67.177.114.112] has joined #bitcoin-core-dev
13:17 < cfields> wumpus: i have some work on docker that may not have been in vain, though. It looks like a very possible gitian replacement
13:18 < warren> cfields: for your own deterministic toolchain?
13:18 < wumpus> cfields: interesting
13:19 < cfields> (after all, Gitian basically is an early/simplified version of what Docker has come to be)
13:20 < wumpus> in a way, yes. At least docker is very actively supported/maintained.
13:20 < warren> docker still puts an OS into a chroot
13:20 < cfields> warren: kinda. it just builds from a pre-determined sandbox and caches each step. as a bonus, each step can be shared as well
13:21 < warren> IMHO it's worthwhile to switch away from gitian if we are at the stage of being fully in control of our own deterministic toolchain
13:21 < cfields> warren: well you'll always need a reference environment
13:21 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
13:22 < warren> cfields: the reference environment could be deterministic as well
13:22 < wumpus> that's a long way, you don't just need a reference toolchain, but there's also other tools that have an effect on the result
13:22 < cfields> in this case, docker basically acts as that reference environment, containing only our reference toolchain and the bare minimum other tools
13:22 < cfields> seems to me, docker is the perfect tool for us in this case
13:22 < wumpus> warren: we need a deterministically buildable OS, isn't debian working on that :)
13:23 < cfields> warren: sure. and you have to run it somewhere :)
13:23 < warren> ANY OS > build stage A that probably isn't deterministic -> use that to build stage B
13:24 < cfields> warren: regardless of the determinism of the base, you have to have some tool for actually building the thing. Short of handing out a rootfs.tar.gz and praying that it will run on some baremetal, ofc
13:25 < wumpus> anyhow this is driftng off topic
13:25 < wumpus> main thing I'd like is to have c++11 in travis
13:25 < cfields> warren: btw, I believe I've seen some early deterministic Debian base images on dockerhub
13:25 < wumpus> cfields: so deterministic debian doesn't only exist in theory anymore? that's good to hear there's progress
13:25 < cfields> wumpus: yes, i'm committed to making that happen one way or another. The net code depends on it, so I'm kinda forced to :)
13:26 < wumpus> cfields: it sounds like a project akin to building the pyramids
13:27 < cfields> hmm, trying to re-find what i saw
13:27 < wumpus> even getting the bitcoin dependencies deterministic was a hell of a lot of work, just imagine for a full OS
13:27 < wumpus> although it gets easier, with better tooling, some things only had to be done onece
13:28 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
13:29 < cfields> wumpus: hmm, i might've made up the Debian part. I saw someone working on a deterministic base for Travis, my brain might've just lumped 'em together.
13:29 < cfields> s/Travis/Docker/
13:30 < wumpus> right - any deterministic base wouldb e fine, it doesn't need to be debian 
13:32 < wumpus> docker is based on lxc isn't it? that means it at least doesn't need deterministic kernel, init etc
13:33 < cfields> based on cgroups, I don't believe it uses lxc itself
13:34 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 260 seconds]
13:39 -!- t800 [~t800@mail.werk1.at] has quit [Quit: ThrashIRC v2.9 sic populo comunicated]
13:41 < wumpus> right, the same underlying mechanism
13:43 < kanzure> in addition to deterministic debian please also consider deterministic nixos things
13:43 < kanzure> fwiw i recommend not using docker's build tool. it's a mess.
13:44 < kanzure> using docker for running containers or something is probably fine (although coreos/rkt things should be considered, since they seem to be compatible with docker containers and have a specification and words written)
13:45 < kanzure> "docker build" is a build tool crammed into a container management system. a more realistic build tool is something like bazel ( http://bazel.io/ ), which can spit out finished container images.
13:45 -!- t800 [~t800@mail.werk1.at] has joined #bitcoin-core-dev
13:45 -!- t800 [~t800@mail.werk1.at] has quit [Client Quit]
13:45 < GitHub178> [bitcoin] jonasschnelli opened pull request #7742: [Wallet][RPC] add missing abandon status documentation (master...2016/03/ab_doc) https://github.com/bitcoin/bitcoin/pull/7742
13:46 -!- musalbas [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
13:46 < kanzure> (with "docker build" you lose out on things like build caching unless you always build only on one machine. this negatively impacts things like distributed continuous integration build runners.)
13:46 < cfields> kanzure: docker would only be used as a way to launch our own build process inside of a pre-determined environment
13:46 -!- lysobit [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
13:47 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 264 seconds]
13:47 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
13:48 -!- t800 [~t800@mail.werk1.at] has joined #bitcoin-core-dev
13:48 -!- lysobit [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
13:48 < warren> kanzure: coreos supports docker, not the other way around
13:49 -!- t800 [~t800@mail.werk1.at] has quit [Client Quit]
13:49 < kanzure> i don't think i said otherwise.
13:49 -!- musalbas [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
13:50 < kanzure> cfields: right but even the pre-determined environment has a build toolchain. and the default way when using docker is to use "docker build". which is what my above rant is about.
13:51 < kanzure> oh i guess that is inconsistent with me mentioning rkt. my mention of rkt is unrelated to my complaints about "docker build".
13:51 < kanzure> (rkt doesn't do container building)
13:53 < cfields> kanzure: I'll read up on those things
13:53 -!- lysobit [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
13:53 < kanzure> ok feel free to pester me. i have been reading docker source code and such.
13:54 -!- musalbas [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
13:54 < cfields> great, thanks :)
13:54 -!- musalbas [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
13:55 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
13:56 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
13:56 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
13:56 -!- lysobit [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
13:57 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has quit [Read error: Connection reset by peer]
14:07 -!- Guest27862 [~ChillazZ@194.97.152.20] has quit [Ping timeout: 240 seconds]
14:08 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev
14:13 -!- droark [~droark@24.22.36.12] has joined #bitcoin-core-dev
14:19 < GitHub139> [bitcoin] luke-jr closed pull request #7047: [WIP] Backports for 0.11.3 (updated to 93ca5a3) (0.11...backports-for-0.11.3) https://github.com/bitcoin/bitcoin/pull/7047
14:22 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
14:27 < GitHub149> [bitcoin] luke-jr opened pull request #7743: [0.11] Important backports for 0.11.3 (updated to v0.12.0) (0.11...backports-for-0.11.3) https://github.com/bitcoin/bitcoin/pull/7743
14:29 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
14:31 -!- Hybrids0le [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
14:31 -!- hybridsole [~hybridsol@67.177.114.112] has quit [Disconnected by services]
14:32 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mryabbrtgwhzoqmj] has quit [Read error: Connection reset by peer]
14:33 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-yshridwmazkddgda] has quit [Read error: Connection reset by peer]
14:33 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mwjdjgsntuuptsod] has joined #bitcoin-core-dev
14:33 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-keqqcguejzxvoyqy] has joined #bitcoin-core-dev
14:33 -!- Hybrids0le [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has quit [Client Quit]
14:34 -!- droark [~droark@24.22.36.12] has quit [Ping timeout: 250 seconds]
14:34 -!- lysobit [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
14:34 -!- musalbas [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
14:34 -!- lesderid [~lesderid@anna.lesderid.net] has quit [Ping timeout: 240 seconds]
14:36 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 244 seconds]
14:41 -!- musalbas [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
14:41 -!- lysobit [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
14:41 -!- lesderid [~lesderid@anna.lesderid.net] has joined #bitcoin-core-dev
14:44 -!- Netsplit *.net <-> *.split quits: windsok, ebfull, d_t
14:50 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
15:00 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
15:00 -!- ebfull [~sean@73.34.119.0] has joined #bitcoin-core-dev
15:00 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev
15:03 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-ivpcunvxydutizey] has quit [Ping timeout: 248 seconds]
15:05 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-vzenjdbdyrsclbua] has joined #bitcoin-core-dev
15:07 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds]
15:18 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 240 seconds]
15:19 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev
15:32 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
15:33 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
15:33 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:38 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 252 seconds]
15:43 -!- Hybrids0le [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
15:44 -!- Hybrids0le [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has quit [Client Quit]
15:55 -!- shesek [~shesek@bzq-84-110-33-184.red.bezeqint.net] has joined #bitcoin-core-dev
15:59 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-pzpuamqsbskpjmzp] has joined #bitcoin-core-dev
16:02 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
16:04 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 244 seconds]
16:06 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
16:10 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
16:20 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
16:23 -!- musalbas [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
16:23 -!- musalbas- [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
16:23 -!- musalbas- is now known as musalbas
16:27 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 45.0.1/20160315153207]]
16:50 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
16:52 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
17:02 -!- d_t [~textual@212.144.253.35] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:04 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:08 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
17:09 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
17:12 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]
17:28 -!- supasonic [~supasonic@172-11-188-117.lightspeed.rcsntx.sbcglobal.net] has quit [Quit: Leaving]
17:33 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
17:35 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
17:39 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 244 seconds]
17:44 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:50 -!- murch [~murch@p4FE39C5E.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
18:03 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 248 seconds]
18:05 -!- murch [~murch@p4FE39C5E.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
18:36 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
18:40 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 240 seconds]
18:41 -!- kangx [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has quit [Ping timeout: 250 seconds]
18:47 -!- Chris_Stewart_5 [~Chris_Ste@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]
18:51 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer]
18:52 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-core-dev
19:06 -!- wangchun_ [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
19:06 -!- ChillazZ [~ChillazZ@194.97.152.20] has quit [Ping timeout: 240 seconds]
19:06 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 240 seconds]
19:06 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev
19:07 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:07 -!- shesek [~shesek@bzq-84-110-33-184.red.bezeqint.net] has quit [Ping timeout: 240 seconds]
19:08 -!- shesek [~shesek@bzq-84-110-33-184.cablep.bezeqint.net] has joined #bitcoin-core-dev
19:08 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:11 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-bmenxcebohaiamfr] has quit [Quit: Connection closed for inactivity]
19:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
19:20 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
19:28 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
19:31 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
19:33 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 276 seconds]
19:41 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Quit: .]
19:43 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
19:56 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
19:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]
20:00 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
20:06 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
20:11 -!- anttea [~anttea@a88-112-146-73.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds]
20:11 -!- anttea [~anttea@a88-112-146-73.elisa-laajakaista.fi] has joined #bitcoin-core-dev
20:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
20:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
20:40 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
20:40 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-pzpuamqsbskpjmzp] has quit [Ping timeout: 240 seconds]
20:42 -!- wallet42 [uid154231@gateway/web/irccloud.com/x-vykhvamohdmnmgnp] has joined #bitcoin-core-dev
21:07 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
21:11 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
21:13 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Read error: Connection reset by peer]
21:14 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
21:22 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
21:23 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
21:28 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 252 seconds]
21:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:05 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:05 < 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
22:06 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:08 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
22:12 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
22:18 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
22:19 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
22:25 -!- d_t [~textual@212.144.253.35] has quit [Read error: Connection reset by peer]
22:26 -!- d_t [~textual@212.144.253.35] has joined #bitcoin-core-dev
22:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:40 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
23:05 -!- lysobit [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 240 seconds]
23:05 -!- lysobit [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
23:13 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
23:18 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Ping timeout: 264 seconds]
23:23 -!- d_t [~textual@212.144.253.35] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:24 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]
23:26 -!- fengling [~fengling@111.198.29.53] has joined #bitcoin-core-dev
23:30 -!- Don_John [~Don@250-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer]
23:32 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:33 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:35 -!- mrkent [~textual@unaffiliated/mrkent] has quit []
23:35 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Ping timeout: 244 seconds]
23:39 < gmaxwell> yippie. mutation testing proves the existing tests are inadequate. 
23:39 < gmaxwell> (for ct aes)
23:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lszjiqroxdqpskvx] has joined #bitcoin-core-dev
23:56 -!- fengling [~fengling@111.198.29.53] has quit [Ping timeout: 240 seconds]