19:02:37 <wumpus> #startmeeting
19:02:37 <lightningbot> Meeting started Thu Feb 16 19:02:37 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:37 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:02:58 <wumpus> jonasschnelli: well it's a magic option value but it's only for the option, it doesn't get represented internally as 1
19:03:01 <luke-jr> tbh, I've had second thoughts about the manual pruning design (seems it'd be nicer to do "automatic pruning always, but with named barriers that must confirm being done up to <height> before pruning it"), but that's beyond this topic
19:03:18 <wumpus> jonasschnelli: I think the reason or choosing 1 was that -prune will work
19:03:27 <wumpus> luke-jr: I like the current manual pruning from an API point of view
19:03:28 <luke-jr> s/always/always in pruning mode/
19:03:33 <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
19:03:44 <luke-jr> wumpus: yes, but it doesn't scale well if you have 2 external apps using the node
19:04:02 <cfields> hi
19:04:05 <wumpus> luke-jr: it's very simple. Automatic pruning is disabled and the client/admin can choose what to prune. Also useful for testing the pruning stuff without too much complexity
19:04:12 <wumpus> luke-jr: the implementation is convoluted though
19:04:16 <morcos> wumpus: i think two more are needed for 0.14, both very small  #9760 and #9761  (9761 is already included in one of the marked ones)
19:04:17 <gribble> https://github.com/bitcoin/bitcoin/issues/9760 | [wallet] Remove importmulti always-true check by ryanofsky · Pull Request #9760 · bitcoin/bitcoin · GitHub
19:04:18 <paveljanik> proposed topic: release status, where can we help...
19:04:19 <gribble> https://github.com/bitcoin/bitcoin/issues/9761 | Use 2 hour grace period for key timestamps in importmulti rescans by ryanofsky · Pull Request #9761 · bitcoin/bitcoin · GitHub
19:04:22 <wumpus> luke-jr: but I'm happy someone implemented it anyhow
19:04:27 * luke-jr nods
19:04:41 <kanzure> hi.
19:04:47 <petertodd> wumpus: same: my OpenTimestamps servers actually need this feature
19:04:58 <wumpus> release status: running as hard as we can but staying in the same place
19:05:09 <sipa> i think we're very close.
19:05:13 <morcos> wumpus: boo!  we're not staying in the same place
19:05:19 <gmaxwell> I am becoming increasingly happy with the release.
19:05:29 <sipa> let's be optimistic: everything we're fixing is an improvememt
19:05:51 <gmaxwell> Two weeks ago I was chewing my nails feeling like we were at risk of shipping something that wouldn't meet our standards of quality, and now I am not worried. :)
19:06:05 <jonasschnelli> hah. Good.
19:06:06 <wumpus> but I think we need to decide when we can do release candidate 1, which is a test release anyway, when rc1 is out it's bound to find more issues
19:06:32 <sipa> i think we can do rc1 today?
19:06:52 <gmaxwell> I would be fine doing it _now_, now.  There are AFAIK not anything in the pipe which are disruptive enough issues that they'd degrade our rc1 learning, though a rc2 will be guarenteed.
19:06:53 <paveljanik> rc1 for the weekend is fine!
19:06:56 <sipa> or at least branch off today
19:06:59 <luke-jr> I don't think we have any critical problems blocking a rc1
19:07:17 <jtimon> sipa: why branch of if we can't rc1 ?
19:07:19 <wumpus> I don't think so either
19:07:24 <cfields> no more blockers from me either
19:07:26 <luke-jr> jtimon: to begin merging for 0.15?
19:07:40 <wumpus> right, because more and more pulls for 0.15 are waiting
19:07:40 * jtimon nods
19:07:58 <jonasschnelli> IMO the two import multi fixes are not critical and can go in after rc1 (or even in 0.15 in the worst case).
19:08:08 <gmaxwell> all you naughty people not banging away at getting 0.14 ready to go.
19:08:29 <morcos> jonasschnelli: well lets decide that
19:08:40 <gmaxwell> jonasschnelli: I think 0.15 would be really unfortunate since they're interface changes that users may have to accomidate in their software. (and also are covering corner cases that could result in funds losses)
19:08:42 <wumpus> I think the fixes are all important, and should get either into 0.14.0 or backported to the 0.14 branch if they don't, but not everything should be regarded as yet another thing to hold up rc1
19:08:43 <morcos> yesterday people were saying it was bad to release with something that coudl silently not find funds
19:09:03 <gmaxwell> but no reason to hold rc1 for them. They're well understood.
19:09:28 <jonasschnelli> Yes. I think the should be in 0.14. Just worst case if we spun of rc1 and chaincode-labs colabses. :)
19:09:29 <wumpus> anyhow tomorrow sounds good to me, let's try to get in what we can get in
19:09:31 <gmaxwell> it's not like someone is going to encounter one of them running rc1 and leave us going "shit was that the know issue or something else?"
19:09:32 <luke-jr> #9619 is a fix, but not really critical since anyone affected needs a workaround in 0.13 anyway (just pushed an amend-with-no-changes because the Travis error seems impossible)
19:09:33 <gribble> https://github.com/bitcoin/bitcoin/issues/9619 | Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates by luke-jr · Pull Request #9619 · bitcoin/bitcoin · GitHub
19:09:34 <achow101> what's the point of making an rc1 if we're going to need rc2 anyways?
19:09:42 <sipa> achow101: exposure
19:09:46 <gmaxwell> achow101: to start getting people using it.
19:09:50 <wumpus> achow101: get the code actually tested?
19:09:52 <gmaxwell> more*
19:09:56 <wumpus> what is the point of doing rc1 at all if not?
19:09:57 <kanzure> and seeking bug reports
19:09:57 <jonasschnelli> I think we should plan enough time to fix stuff that gets report after rc1...
19:10:18 <sipa> jonasschnelli: the release schedule already has 2 weeks left
19:10:33 <wumpus> achow101: I don't think it ever happened that a major release didn'tneed a rc2
19:10:35 <luke-jr> 2 weeks can go fast
19:10:52 <jonasschnelli> Other can work on fixes reported in rc1.
19:10:54 <gmaxwell> achow101: what we generally don't want to do is to ship an RC1 with issues bad enough that it will harm the testers seriously, or which will fail in mysterious ways that we can't learn from.  E.g. if we had a known crash fix, we would hold rc1, so that we wouldn't worry that every user crash report might have been an unknown issue.
19:10:57 <jonasschnelli> *Others
19:11:05 <morcos> my only concern is that if we do rc1 everyone will be distracted with that and not this last few remaining PR's..  but i guess i don't really care either way
19:11:08 <cfields> wumpus: just forget the bump to v0.14 again and thereby guarantee an rc2 :p
19:11:38 <wumpus> cfields: lol exactly
19:11:39 <morcos> seems like if someone would just review those PR's we might be able to get them merged today
19:11:41 <gmaxwell> well I think an RC2 is already guarenteed if we do an rc1 ASAP. But thats fine. Much better than not doing the rc1.
19:11:49 <achow101> ok
19:12:04 <wumpus> a RC2 is guaranteed in any case, not just if we do rc1 asap
19:12:17 <wumpus> that's my point, we don't know of all the issues yet
19:12:26 <morcos> almost all the complication is in new tests.. reviewing the code changes is pretty simple
19:13:18 <wumpus> the only one I doubt about is #9773, at it is still WIP
19:13:20 <gribble> https://github.com/bitcoin/bitcoin/issues/9773 | WIP: Return errors from importmulti if complete rescans are not successful (on top of #9761) by ryanofsky · Pull Request #9773 · bitcoin/bitcoin · GitHub
19:13:44 <luke-jr> it's a new feature, so we could just say "don't use this without being aware of the risks"
19:14:13 <paveljanik> mark it as experimental then?
19:14:40 <sipa> paveljanik: meh, i think we're close enough to not do that
19:15:15 <luke-jr> I mean in rc1 only
19:15:26 <wumpus> well even with that change it can be marked as experimental
19:15:34 <wumpus> it is new code afterall
19:15:39 <gmaxwell> I'm not too worried about it in rc1.
19:16:12 <wumpus> there are probably still problems with it that we haven't found, which will be found by people testing it
19:16:33 <paveljanik> we can mark it as experimental in the release notes only...
19:16:33 <wumpus> so yes, experimental makes sense. Though a new major release should be considered experimental entirely
19:16:37 <gmaxwell> people running rcs are the least likely to lose funds due to a rescan limitation, and there won't be many of them.
19:17:50 <morcos> i think it is a mistake to call it experimental
19:17:56 <morcos> we don't want to devalue the meaning of that word
19:18:13 <wumpus> ok...
19:18:17 <morcos> sometimes we may want to have things that are actually experimental and we don't want people to think we just always say that
19:18:40 <wumpus> "this feature is experimental level 4"
19:18:44 <sipa> haha
19:18:50 <kanzure> nasa technical readiness levels
19:18:54 <CodeShark> The whole thing is experimental :p
19:18:56 <morcos> this is known to the state of CA to be experimental
19:18:56 <petertodd> morcos: "dangerously experimental"
19:19:06 <petertodd> morcos: lol
19:19:23 <gmaxwell> Yea, thats why I was not supporting expiremental.
19:19:54 <instagibbs> morcos, accounts... deprecated!
19:20:13 <morcos> what..  is that an announcement? a question?
19:20:17 <morcos> i hate accounts
19:20:21 <gmaxwell> For rc1 we can simply say that there are in-flight improvements to that feature link to the PRs. if we really want to... in a reply to the announcement.
19:20:42 <sipa> let's just review the outstanding patches, they are tiny
19:20:42 <instagibbs> morcos, we use "deprecated" in things that are lasting forever in practice, bad joke
19:20:50 <jtimon> mhm, why 9619 doesn't go in for 0.14?
19:20:51 <morcos> oh.. yeah
19:20:58 <sipa> with some luck we can get everything merged
19:21:14 <sipa> branch and rc1 tomorrow
19:21:15 <wumpus> gmaxwell: yes, that there is still work in progress, that's better and more clear than the word experimental
19:21:21 <sipa> with whatever is in
19:21:33 <morcos> ok, so can we just pick a time.  wumpus is going to call rc1 tomorrow morning..  it tonight we can convince people to merge a few of these other things... that'll leave less for rc2
19:22:05 <morcos> that was "if tonight"  , if not , then ok
19:22:09 <sipa> wumpus: is that fine by you?
19:22:16 <wumpus> yes, that's fine with me
19:22:48 <wumpus> I'm okay with another day, let's just not let it slip another week, that next thursday we're again wondering when to do the rc1 :)
19:23:15 <sipa> next thursday we should be talking about doing rc2
19:23:22 <wumpus> yes, ideally
19:23:30 <gmaxwell> We're at a point where beyond the couple in flight PRs little to no more improvement is happening, which is when we need more input.
19:23:54 <achow101> so rc1 tomorrow regardless of whether those three prs get merged?
19:24:06 <sipa> achow101: that's what i suggest, yes
19:24:12 <paveljanik> +1
19:24:20 <achow101> ^
19:26:14 <sipa> are we ok with talking about things beyond 0.14?
19:26:30 <wumpus> sure!
19:26:34 <luke-jr> new #topic?
19:26:41 <sipa> i'd briefly like to talk about randomness
19:26:54 <wumpus> #topic randomness
19:26:56 <luke-jr> that's random.
19:27:06 <sipa> we currently have 3 "levels" of randomnesz
19:27:21 <sipa> fastrandomcontext, getrandbytes, getsecurerandbytes
19:27:28 <sipa> i'd like to have only 2
19:27:30 <wumpus> we need a random number of levels of randomness
19:27:42 <wumpus> yes.
19:27:46 <wumpus> why are there three?
19:27:49 <instagibbs> can you explain "getsecurerandbytes"
19:27:58 <instagibbs> im going through code now but..
19:27:59 <wumpus> I mean we need one for wallet keys, I understand that
19:28:02 <sipa> the last one is used for privaye keys
19:28:04 <jtimon> why 9619 doesn't go in for 0.14?
19:28:22 <jonasschnelli> jtimon: wrong topic
19:28:27 <sipa> it's as secure as getrandbytes if all goes well, but it's more paranoid
19:28:47 <sipa> so, i've been playing with a chacha2p based rng instead of fastrandomcontext
19:28:51 <jtimon> jonasschnelli: suggested topic then
19:28:53 <wumpus> I think I'm fine with an extra paranoid level for wallet keys
19:28:56 <sipa> *chacha20
19:29:17 <sipa> which takes around 10ns for a 32-bit rand
19:29:30 <wumpus> it's much more important to have good randomness there then in almost any other place in computing currently
19:29:36 <instagibbs> "GetStrongRandBytes" <--- this it?
19:29:48 <rabidus> return 4
19:29:49 <sipa> the current fastrandomcontext takes 1.5ns, but with extra optimizations it can be made comparablr
19:30:08 <sipa> and if we have that, i think we can use strong randomnes for everything
19:30:13 <wumpus> for non wallet keys we can probably do with one level
19:30:19 <wumpus> is that your plan sipa?
19:30:36 <sipa> basically i suggest making all RNGs cryptographic
19:30:55 <sipa> but the fast one is not thread-safe, doesn't reseed, doesn't protect against VM reloads
19:30:55 <wumpus> so merge the fastrandomcontext and somewhatmoresecure level, and keeping that and the ultra-paranoid one for wallet keys
19:31:36 <sipa> i realize the "only two randomness levels" is a bit of an abstract goal
19:31:45 <wumpus> yes the fastrandomcontext is supposed to only eb used from one thread at a time
19:31:54 <morcos> are there any inner loops that use random numbers?
19:31:58 <petertodd> wumpus: the ultra paranoid one can also use the chacha code
19:31:59 <wumpus> because it's for inner loops
19:32:05 <sipa> yes, the wallet coin selection
19:32:20 <sipa> i benchmarked it, making it chacha20 doesn't affect its performance
19:32:23 <wumpus> any locking for synchronization there would be pretty bad
19:32:41 <wumpus> there's also an inner random loop in the address selection code IIRC
19:32:56 <jonasschnelli> Do we need cPRNG for coin selection?
19:32:56 <sipa> yup
19:33:02 <wumpus> sipa: yes chacha20 is fast, but the problem is the thread safety
19:33:05 <sipa> jonasschnelli: no, we don't
19:33:14 <gmaxwell> sipa wants to reduce the codebase complexity.
19:33:19 <sipa> but chacha20 is so fast i don't care
19:33:21 <wumpus> if you want to be able to share a random context between threads, you end up with lots of synchronization overhead
19:33:23 <jonasschnelli> Yes. This would be good.
19:33:51 <wumpus> that's why the inner loops use a non-threadsafe random context, =which doesn't matter as it's only used by one thread
19:34:01 <bitcoin-git> [13bitcoin] 15gmaxwell opened pull request #9779: Update nMinimumChainWork and defaultAssumeValid. (06master...06update_chainparams) 02https://github.com/bitcoin/bitcoin/pull/9779
19:34:11 <sipa> having clearer expectations about the rngs may simplify getting rid of openssl later
19:34:18 <wumpus> the thread sync overhead is where the overhead would be
19:34:24 <sipa> though that's not something to discuss now, i think
19:34:38 <wumpus> so how would you cope with that sipa? or would it all be non-shared context?
19:35:07 <sipa> so 1) replace fastrandomcontext with a bit more featureful chacha20 based one
19:35:39 <wumpus> yes, depending on openssl for just randomness is fine, there's no urgent reason to get rid of that, and it seems controversial for some people
19:35:47 <sipa> 2) see where the current non-strong-getrandbytes can be replaced with fastrandcontexts, and replace everything with getstrongranbytes
19:35:50 <wumpus> that makes sense
19:36:06 <gmaxwell> one of the harder points (beyond threading) is that we need to manage which RNGs are robust against a VM image being snapshotted and restored.  Coinselection using the same randomness again after a VM restore would be harmless.  Choosing a crypto nonce would be much less harmless.  If a RNG needs to be outputing data intially after restore there is unfortunately a runtime cost (esp on ARM).
19:36:58 <wumpus> also I think we need an abstraction for 'kernel randomness', this came up recently in context of OpenBSD, which doesn't have /dev/random/urandom available in all contexts
19:37:07 <gmaxwell> Pieter and I have been debating this a little bit the past could days.
19:37:23 <wumpus> the modern way,sandbox-proof way seems to be to use a specific system call fo that, but it differs per OS unfortunately
19:37:27 <sipa> wumpus: yup, that would go into the (singular) getstrongrandbytes implementation
19:37:27 <cfields> isn't there an old PR for exactly that abstraction?
19:37:28 <gmaxwell> wumpus: we do have a function for OS randomness, it should be smarter of course... but it was only fairly recently introduced.
19:37:48 <Victorsueca> maybe you could get rid of getrandbytes? so we keep the fast one for simple operations and the secure and paranoid one for important stuff and you can focus on implementing more features on those two
19:37:59 <gmaxwell> GetOSRand()
19:38:06 <wumpus> (linux also has a "getrandom" system call that can be used instead of /dev/urandom, in sandboxes)
19:38:13 <sipa> Victorsueca: read the above discussion, that is exactly what i am proposing
19:38:22 <wumpus> gmaxwell: ok
19:38:41 <gmaxwell> wumpus: yes, in newer systems. We do mention using that in the PR that implemented GetOSRand I think. (getentropy)
19:38:43 <wumpus> gmaxwell: in any case, that is the lowerst level, it shouldn't be regarded as 'a level of randomness'
19:38:52 <gmaxwell> so I think we know what we need to go there.
19:39:09 <wumpus> indeed, getentropy is bsd, getrandom is linux
19:39:29 <Victorsueca> sipa: ohh, I somehow misread that you where proposing to merge the fast and the middle one to make it simpler
19:39:37 <sipa> FWIW linux 4.8 also switched to chacha20 for /dev/urandom
19:39:48 <wumpus> yes
19:40:14 <gmaxwell> The framework I think about this is that we have several randomized algorithims where there are basically no cryptographic guarentees needed... coin selection, addr man buckets, and tests being some examples.  These need to be fast but can all use just a local context, need no resistance against reversal (somsone steals your ram and recovers older randomness) or prediction (vm saves repeat rando
19:40:19 <petertodd> gmaxwell: re: VM image being snapshotted and restored, that's basically a case where reusing a secret is by itself harmful - is there an example in Bitcoin where that's the case, now that we do deterministic signing?
19:40:20 <gmaxwell> mness).
19:40:22 <gmaxwell> So thats one set of uses.
19:40:23 <sipa> Victorsueca: i'm proposing to make the fast one stronger (but not much slower), and then things using the middle one need to be judged on a case by case basis whether they can use the new fast one, or the strong one
19:40:50 <sipa> Victorsueca: after that, the middle one goes away
19:40:59 <gmaxwell> Then we have other uses where we have randomized behavior which does have stronger security requirements, like ping nonces which need to be strongly unforgable to prevent peers hiding their latency.
19:41:07 <Victorsueca> sipa: makes sense
19:41:11 <gmaxwell> But even if they're broken it just turns into DOS attacks.
19:41:39 <wumpus> it's strong, but far from as strong a requirement as wallet keys
19:41:43 <gmaxwell> Then we have things like long term keys which we do infrequently and basically no cost is too high. And they have to meet basically every security characteristic we can imagine.
19:41:57 <wumpus> indeed
19:42:05 <cfields> suggested similar next topic: clocks
19:42:09 <gmaxwell> the second class often has to be moderately fast too.
19:42:41 <gmaxwell> Pieter would like to collapse this class hierarchy some by making the first class use the second while making the second fast enough that it's fine to do so.
19:43:09 <Victorsueca> cfields: clocks as in CPU clock or as in timestamp?
19:43:27 <wumpus> Victorsueca: please wait until the topic is actaully started
19:43:33 <Victorsueca> ohh, sorry
19:43:48 <wumpus> though I think we've wrapped up randomness
19:43:51 <sipa> agree
19:43:56 <wumpus> #topic clocks
19:43:58 <gmaxwell> I have a little doubt that this is possible, because I think the second may need to deal with reversal resistace and prediction resistance, which cannot be done for free. (e.g. you must mix in TSC and/or RDRAND at every use.)
19:43:59 <instagibbs> he has to gavel before we can switch
19:44:02 <gmaxwell> okay!
19:44:16 <wumpus> gmaxwell: oh, didn't know you were still typing, sorry
19:44:18 <cfields> I have some local changes that implement the concept of different clocks/time_points/durations. The objective is for them to be incompatible with each-other.
19:44:27 <gmaxwell> thats fine! just some things to think about.
19:44:33 <wumpus> cfields: yes, that seems the way to go about it
19:44:54 <sipa> cfields: f i may interject... i was thinking about creating a generic int class wrapper that supports no implicit conversioms
19:44:59 <gmaxwell> cfields: pieter and I were talking about type safty recently, and pieter suggested a scheme for introducing more integer types which will never implicitly be converted.
19:45:19 <wumpus> most importantly we should start using monotonic timestamps in the network code where possible
19:45:51 <cfields> that sounds fine, but i'm not sure that they're entirely related here. The (my) objective is to stop storing time as an int, and instead as a time_value
19:46:01 <sipa> cfields: or are timestamps in a c++11 world not something that fit in integers?
19:46:04 <cfields> that way it can be represented in sec/msec/whatever whenever it's needed
19:46:10 <cfields> sipa: exactly
19:46:23 <cfields> it also enforces timestamps that can't be used on the wrong clock
19:46:32 <sipa> i'm confused
19:46:37 <gmaxwell> I have suggested in the past that we consider constructing a monotonic local clock, but wumpus seemed to not like the idea. which I think is orthorgonal to the type safty thing, but it would perhaps make time more sane in the codebase.
19:46:44 <wumpus> cfields: in general that sounds good, though in some structures such as the block index we want to use as compact types as possible
19:47:02 <gmaxwell> saftey*
19:47:09 <gmaxwell> doh
19:47:12 <cfields> wumpus: sure, you can always get an int out of it if you want
19:47:13 <wumpus> gmaxwell: huh I'm all for using monotonic clocks were possible, they're just not good for everything
19:47:22 <gmaxwell> safety**
19:47:48 <sipa> cfields: my point was to have a template<typename tag> class non_convertible_int
19:47:52 <cfields> also, i believe the class is actually not bigger than an int. It's just not convertable to int
19:48:21 <wumpus> cfields: well if it represents micro/nanosecond it needs to be at least uint64 :)
19:48:23 <sipa> and then have typedef non_comvertible_int<systemtime> systemtime_type
19:48:36 <sipa> and systemtype_type is what is used
19:48:44 <gmaxwell> you would get_int() on the object to get an int. You would just get a conversion by surprise.
19:48:45 <sipa> *systemtime_type
19:48:54 <gmaxwell> I would _hope_ we can construct something that at runtime is _exactly_ equal to using an integer.
19:49:06 <sipa> cfields: you're being inconsistent
19:49:19 <cfields> sipa: http://en.cppreference.com/w/cpp/chrono/time_point
19:49:42 <gmaxwell> I think we should do this far more broadly than just timestamps however.
19:49:43 <sipa> we can't use that in blocks, etc
19:50:08 <wumpus> indeed - block times /consensus are a special case
19:50:25 <cfields> sipa: we don't use timeval in blocks either though, we convert from the clock
19:50:26 <sipa> but perhaps we should use those types in network state, measuring speed, ...
19:50:35 <cfields> sipa: i'll demonstrate with code, probably easier that way
19:50:53 <wumpus> right
19:51:13 <sipa> cfields: what i want to address is the fact that an int or int64 can now mean microseconds, milliseconds, or seconds, and either system time, or monotonous time, or network-adjusted timr
19:51:44 <sipa> it's fine that those are int-like, but they shouldn't be convertible from one into another
19:51:59 <cfields> sipa: and that's exactly what i've addressed. Each of those gets its own type, and they're not convertable to eachother. But you can do a duration_cast<std::chrono::seconds>(foo) and get an int64_t seconds value out
19:52:09 <sipa> anyway, for everything but consensus data structures, perhaps there are more c++ish ways
19:52:50 <sipa> cfields: let's discuss this outside of theeeting
19:52:51 <gmaxwell> This problem exists far beyond timestamps however. Use a node ID as a tx count? no problem.  Use a vin index as a block number? no problem. Use a bytes sent as a relay bool? no problem.
19:53:16 <gmaxwell> We have multiple times had potentially serious bugs from the general issue of implicit conversions.
19:53:35 <cfields> gmaxwell: yes, agreed that the tag would be very useful
19:53:42 <gmaxwell> (or in the case of sighash single, an actual consensus behavior flaw)
19:53:50 <cfields> sipa: np
19:53:51 <sipa> jtimon had a topic as well
19:53:56 <wumpus> using enumerations instead of booleans would also go a long way
19:54:00 <jtimon> well, just a question really
19:54:03 <jonasschnelli> I also have a little proposal
19:54:04 <gmaxwell> all the data is there in the compile to prevent these mistakes, we're just not exposing it right. :)
19:54:13 <jtimon> I guess it can wait after the meeting
19:54:16 <wumpus> especially for functions that have tons of boolean arguments in succession, that's just crazy
19:54:17 <sipa> wumpus: yeah, generally useful
19:54:26 <gmaxwell> wumpus: yea, using bools, also using structs to get named parameters... lots of things we can do.
19:54:30 <cfields> wumpus: for sure
19:54:43 <jtimon> or answered fast enough that it doesn't need its own topic: "why 9619 doesn't go in for 0.14?"
19:54:48 <gmaxwell> true false true true false die die die.  ... I hate counting aruments when changing things.
19:54:48 <morcos> jtimon: i think because there was an error reported and no explanation that it was fixed or wasn't really a problem.  that's at least why i haven't looked at the PR.
19:54:53 <wumpus> (well with some IDEs you can see what gets assigned to what parameter because it parses the interface, but that's not something you can realy on that everyone has available)
19:55:00 <wumpus> gmaxwell: exactly
19:55:08 <wumpus> jtimon: what was your topic?
19:55:09 <instagibbs> gmaxwell, the fun really starts when you drop an arg with a default value at the end
19:55:21 <cfields> (or three)
19:55:28 <jtimon> morcos: that explains why is not merged, not why it's not labeled 0.14, but ok I guess
19:55:53 <wumpus> jtimon: let's reverse the question: why would it need to be added for 0.14?
19:55:55 <jtimon> wumpus: including 9619 in 0.14
19:56:11 <jtimon> it's a bugfix and is simple enough, why not?
19:56:41 <sipa> i think it can go in, it's trivial and very small in scope
19:56:45 <gmaxwell> basically without it a plausable downstream gbt user that changes the transaction set could construct an overlarge block, is that the concern there?
19:56:46 <wumpus> I'm fine with merging it before 0.14, if its sufficiently reviewed and teste
19:56:50 <wumpus> it will however not hold up rc1
19:57:08 <gmaxwell> it looks trivial and small in scope, and if my understanding is correct it should go in.. but sure, nothing should hold up rc1.
19:57:19 <gmaxwell> at least nothing that we know of now.
19:57:20 <sipa> fair
19:57:35 <jonasschnelli> Not sure if this makes sense, But I propose to rename the ./qa dir to ./test (or something that sorts after ./src). I think it would be better to have the RPC tests further down in the PRs diff.
19:57:36 <jtimon> sure, was simply surprised it didn't had the 0.14 label since it's not really that new
19:57:57 <Victorsueca> I see lots of utACKs but not any ACK, so trivial it doesn't need testing I assume?
19:57:57 <gmaxwell> short of some kind of crash eat money doom bug showing up before we manage to get it out (and even that shouldn't delay _constructing_ RC1; if doom shows up we can abort launch)
19:58:30 <wumpus> gmaxwell: sure, there are always serious enough problems possible that should postpone the release
19:58:57 <gmaxwell> jonasschnelli: On that I'd like to get into a state where make check is running those tests. They are most of our tests now, and the most valuable.. and really people building with compilers we've never seen before _REALLY_ ought to be running them.
19:59:18 <wumpus> jonasschnelli: don't really have an opinion on that, does it matter much how things are sorted?
19:59:35 <gmaxwell> Why would the sorting matter?
19:59:39 <jonasschnelli> As long as review is a bottleneck I think it matters
19:59:53 <jonasschnelli> But maybe I'm alone with that opinion.
20:00:05 <gmaxwell> OH so they show up lower on github.
20:00:21 <sipa> /zzztest
20:00:28 <wumpus> my biggest pet peeve is that they're called RPC tests, not 'functional tests' or such, they're testing much more than RPC these days :)
20:00:41 <jonasschnelli> ./test_functional
20:00:43 <gmaxwell> It is sometimes a bit confusing that the tests show up first... otoh it can be informative to read the test before the change in the cases where the test is especially good. :)
20:00:45 <wumpus> but not serious enough to actually go on renamind directories
20:00:49 <sipa> also, pull-tester should be merged in rpc-tests
20:00:51 <gmaxwell> wumpus: they are "system tests"  rpc is incidental.
20:01:36 <sipa> we don't have pulltester anymore, and it's annoying to always change directory :)
20:01:44 <wumpus> gmaxwell: yes, it doesn't matter what interface they use, whether it's RPC or P2P or ZMQ or REST or command line arguments etc
20:01:44 <instagibbs> we're over time
20:01:46 <instagibbs> btw
20:01:52 <jonasschnelli> Okay. I'll do a cleanup PR once we branch off.
20:01:53 <wumpus> instagibbs: ah yes
20:01:55 <wumpus> #endmeeting