IRC meeting summary for 2017-02-16

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• 0.14.0RC1 release
• Randomness
• Clocks

0.14.0RC1 release

Background

Bitcoin Core 0.14.0 is scheduled to be released around March 2017. Open pull request aimed for 0.14 are tagged with a 0.14 tag.

Meeting comments

General sentiment was that release readiness has improved significantly in the past two weeks and that a first Release Candidate (RC1) could be made either today or in the next few days. However, there are still some Pull Requests (PRs) that are nearly finished being reviewed that many meeting participants would like to see in the final 0.14.0 release, so there’s certain to be at least a second release candidate as part of this version’s release process.

Andrew Chow asked, “What’s the point of making an RC1 if we’re going to need [an] RC2 anyways?” Several people replied with answers such as, “exposure”, “to start getting people using it”, and “get the code actually tested”. Gregory Maxwell expanded on these replies: “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.”

Discussion continued about whether a release candidate that was not-quite-finished required a special label, but nobody pushed hard for doing that and the idea was dropped.

The provisional schedule was, “[Wladimir van der Laan] is going to call RC1 tomorrow morning. If tonight we can convince people to merge a few of these other things, that’ll leave less for RC2”.

PRs proposed for merging after review into either the RC1 codebase or the RC2 codebase included:

• #9760 - [wallet] Remove importmulti always-true check by ryanofsky (proposed by Alex Morcos, seconded by Jonas Schnelli and Gregory Maxwell)

• #9761 - Use 2 hour grace period for key timestamps in importmulti rescans by ryanofsky (proposed by Alex Morcos, seconded by Jonas Schnelli and Gregory Maxwell)

• #9773 - WIP: Return errors from importmulti if complete rescans are not successful (on top of #9761) by ryanofsky

• #9619 - Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates by luke-jr (proposed by Jorge Timón, discussed more towards end of meeting)

Conclusion

Release RC1 in the next few days and get any remaining patches into RC2.

Randomness

Background

Pieter Wuille proposed and opened the topic by describing the current state, “We currently have 3 ‘levels’ of randomness: fastrandomcontext, getrandbytes, getsecurerandbytes. I’d like to have only 2.”

1. FastRandomContext: currently takes 1.5 nanoseconds but is not a cryptographically-secure psuedo random number generator (CSPRNG).

2. GetRandBytes: a CSPRNG.

3. GetStrongRandBytes: “used for private keys. It’s as secure as getrandbytes if all goes well, but it’s more paranoid”, Wuille explained.

Comments

Wuille proposes making GetRandBytes very fast using the ChaCha20 cipher, which Linux 4.8 switched to using for its /dev/urandom. Once GetRandBytes is fast, it can also be used in place of FastRandomContext.

GetStrongRandBytes can continue being used for “things like long term keys which we do infrequently and basically no cost is too high, and [where it has] to meet basically every security characteristic we can imagine”, said Greg Maxwell. For example, it can mix entropy (randomness) from multiple sources, even fairly slow ones, because it’s ok for it to be comparatively slow.

Conclusion

Questions focused primarily on understanding Wuille’s plan and nobody objected to Wuille attempting the first part of the plan, which is updating GetRandBytes to use ChaCha20.

Clocks: inconvertible times

This was the first of two different time-related topics discussed under the “clocks” topic.

Background

Pieter Wuille explained the problem, “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 time. It’s fine that those are int-like, but they shouldn’t be convertible from one into another.”

Gregory Maxwell described why this is important, “We have multiple times had potentially serious bugs from the general issue of implicit conversions. (Or in the case of sighash single, an actual consensus behavior flaw.) All the data is there in the compile to prevent these mistakes, we’re just not exposing it right. :)”

Comments

Cory Fields proposed and opened the topic, “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. The objective is to stop storing time as an int, and instead as a time_value—that way it can be represented in sec/msec/whatever whenever it’s needed [and] it also enforces timestamps that can’t be used on the wrong clock.”

Nobody seemed to disagree with the objective and discussion focused on implementation details.

Conclusion

Cory Fields and Pieter Wuille will discuss details in more depth outside of the meeting. (If you’re interested, discussion picked up immediately after the meeting.)

Clocks: monotonic timestamps

This was the second of two different time-related topics discussed under the “clocks” topic.

Background

A monotonic clock is one whose time never decreases. Clocks based on the time of the local computer (system time) are not monotonic because system time is occasionally adjusted backwards.

Bitcoin’s consensus require that each block must have a timestamp greater than the median timestamp of the previous 11 blocks on the block chain, thereby providing a monotonic clock (note: with limitations not discussed here).

Comments

Related to the topic of using inconvertible times, Wladimir van der Laan suggested that “most importantly we should start using monotonic timestamps in the network code where possible”.

Gregory Maxwell said, “I have suggested in the past that we consider constructing a monotonic local clock, but [Wladimir] seemed to not like the idea. which I think is orthogonal to the type safety thing, but it would perhaps make time more sane in the codebase.”

Wladimir replied, “huh, I’m all for using monotonic clocks were possible, they’re just not good for everything.”

Discussion of using monotonic clocks ended there. The author of this summary suspects that it will be discussed again when other work on time unit type safety has made progress.

Conclusion

No conclusion.

Mini-topics

Rearranging things related to testing

A wishlist of minor changes to tests was described:

• Jonas Schnelli proposed renaming some directories to help GitHub users new to the project find the most useful tests.

• Pieter Wuille suggested some additional rearrangement to help productivity by factoring out a directory that as added for a testing tool that is no longer used.

• Gregory Maxwell suggested running some of the more time-consuming tests as part of the standard compile sequence.

• Wladimir van der Laan complained that the RPC tests are misnamed since they test a lot more than the RPC interface today (many tests use the RPC interface to test whether the rest of the system is functioning as expected).

Schnelli volunteered to create a pull request to the master branch after 0.14 was split off into a separate git branch.

Comic relief

<morcos> i think it is a mistake to call it experimental
<morcos> we don't want to devalue the meaning of that word

<wumpus> ok...

<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

<wumpus> "this feature is experimental level 4"

<morcos> this is known to the state of CA to be experimental

<sipa> i'd briefly like to talk about randomness

<luke-jr> that's random.

<sipa> we currently have 3 "levels" of randomness

<wumpus> we need a random number of levels of randomness

Participants

Disclaimer

This summary was compiled without input from any of the participants in the discussion, so any errors are the fault of the summary author and not the discussion participants.