IRC meeting summary for 2017-03-23

• Link to this week logs
• Meeting minutes by meetbot

Main topics

• Segwit address proposal
• DER private keys in wallet
• Statement against binary releases
• Blocked and review-needed PRs

Segwit address proposal

Background

Pieter Wuille and Gregory Maxwell recently proposed an address format for use with native segregated witness (segwit) scriptPubKeys.

Conversation

Gregory Maxwell started the conversation, “We might have made a strategic error in getting 1:1 comments from too many people, causing a dearth of comments on the list. Comments on the list would be good even if they’re just ‘I reviewed this before, LGTM [Looks Good To Me]’.”

Peter Todd suggested, “along those lines, I think making some of those 1:1 comments public might be helpful for new devs interested in learning how these processes work.”

During discussion of optimizing for QR code encoding, Jonas Schnelli mentioned, “It’s probably not worth to design an additional binary addr standard for QrCodes. Maybe they are only temporary? Gone in 3-4 yrs?”

Maxwell replied, “I think that it’s probably not worth it for that, but industry feedback would be nice.”

Wuille added, “[QR code’s] alphanuneric mode is pretty efficient; only 10% extra compared to binary. It uses 5.5 bits per character, so 5.5 bits per 5 bits of data is pretty good.”

Schnelli then asked, “could the Bech32 encoding also be used for private keys (== 32bit seeds)?”

Wuille replied, “good question! We’ve been thinking about a stronger checksum for private keys, possibly 12 checksum characters (which is the maximum doable with 64 bit arithmetic). For addresses you really only care about [error] detection, but for private keys you want [error] correction. With a 12 character checksum, correcting 3 errors is trivial, but perhaps we can find one that can correct 4.”

Maxwell added, “Finding a 12-digit code that corrects 4 may take more computing power than we have with just the a hundred cores here, though [Wuille] has done a lot to take that search from completely intractable to plausible. :) I think this work is a lot lower priority though other things we could be working on (like utxo database refactors and tx compaction)”

Near the end of the discussion, Maxwell spoke briefly about the effectiveness of the bech32 encoding at preventing funds from being sent to the wrong address, “if the user’s error rate is below 3.53 errors per address entered, this code has better protection than a 32bit hash (like base58 check uses). And because of case modulation, users are MUCH less likely to make mistakes with this format. If the user is unlikely to make errors, then the effective protection of this scheme tends to infinity. e.g. 0.1% chance of error per character and the probability that an errored string goes undetected is 1:2⁶⁰ [0.0000000000000000867%].

Conclusion

Several people in the meeting who have not reviewed (or finished reviewing) the proposal will review it, and all those who have already reviewed it were encouraged to share their assessments on the mailing list.

Any wallet authors or other Bitcoin developers reading these meeting notes are encouraged to review the proposal, let the community know if they tentatively support it, or make known any issues they have with it.

DER private keys in wallet

Background

Gregory Maxwell described the current situation: “The DER private key format includes the public key, along with all the ECC group parameters, and other overheads all packed in hundreds of bytes of ASN1 parsing hell.” And this is done for every private key in the Bitcoin wallet, even though all Bitcoin private keys use the same parameters and those parameters are already known to Bitcoin Core.

Since Bitcoin Core 0.13.0, all new wallets created by Bitcoin Core’s default settings use a BIP32 Hierarchical Deterministic (HD) wallet. Older-style wallets that used individual randomly-generated keys, and wallets where keys have been imported using the importprivkey RPC are both still supported.

Discussion

Nobody objected to changing the wallet format to store keys or HD seeds without using DER. Most discussion involved how this change and other similar wallet changes should be managed, in particular ensuring that they’re easy to test but that the wallet format only changes at most once per release.

Conclusion

No explicit conclusion. Near the end of the conversation, discussion was focused on using special flags for pending features; for example, Maxwell wrote, “I don’t care if we retain compatibility for a wallet someone created by running bitcoind with --force-wallet-screw-me-over-now-now-now”.

This type of flag would allow individual features to be tested and merged but not activated by default until all the features intended for a particular release have been merged.

Statement against binary releases

Background

A few days before the start of the meeting, a fork of the Bitcoin Core project made a binary-only release for what they claimed were security reasons.

Discussion

Gregory Maxwell asked if developers would be willing to sign a statement regarding Bitcoin Core’s commitment to never releasing binaries without source code. The statement began,

The Bitcoin project would never ask users to run a binary without providing the source. If it ever does, you may safely assume that the actual contributors to the project are locked in a basement somewhere. In that case, please send help.

Bryan Bishop suggested that people send not only help but also food.

There were several other suggestions to refine the statement but no one spoke in opposition of the statement.

Conclusion

No explicit conclusion. Possibly Maxwell will continue working on refining the statement and collecting signatures for it.

Blocked and review-needed PRs

Background

Matt Corallo suggested, “a weekly call for ‘what [Pull Request (PR)] are you blocked on and want review on,’ though we’ve had mixed results when I’ve done that before.”

Discussion

• Corallo requested #9725: CValidationInterface Cleanups

• Wladimir van der Laan and Jonas Schnelli requested #9294: Use internal HD chain for change outputs (hd split)

• Gregory Maxwell requested #9959: Mining: Prevent slowdown in CreateNewBlock on large mempools

There was also discussion about tracking review requests using a GitHub project kanban or using a label.

Conclusion

Reviewers are encouraged to focus on the above PRs. No decision was made in the meeting regarding using a project kanban or label for requested reviews.

Comic relief

<wumpus> proposed topics?

<btcdrak> holiday at the beach?

<petertodd> btcdrak: that's what the financial crypto conference is for

<kanzure> rationale section was good, although i think it would be worthwhile to
          describe the 'exhaustive search'

<gmaxwell> kanzure: we left out a lot of technical minutia about the construction
           which is interesting but not really relevant to the spec.

<sipa> earlier version explained finite field arithmetic and generator polynomials :)

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.