No description provided.
bip85: require direct HMAC use when sufficient #2295
pull scgbckbone wants to merge 1 commits into bitcoin:master from scgbckbone:bip85-direct-entropy changing 1 files +26 −3-
scgbckbone commented at 11:06 AM on September 18, 2026: contributor
-
bip85: require direct HMAC use when sufficient c1e14b0ada
- murchandamus added the label Proposed BIP modification on Sep 18, 2026
- murchandamus added the label Pending acceptance on Sep 18, 2026
-
murchandamus commented at 6:43 PM on September 18, 2026: member
cc: @akarve
-
akarve commented at 6:37 PM on September 19, 2026: contributor
@scgbckbone Requiring derivation paths that consume <= 512 bits to use the raw HMAC output creates a few problems:
- Inconsistent codepaths within the same application (harder to test and prove correct)
- A "back and forth" correctness dance during application development where we realize things like "oh, powers of 2 do not require re-rolls for DICE". Or "my app consumes a variable number of bits (like RSA key generation), how do I partition this into cases under and above the 512 bit limit?" This will lead to unwarranted test vector complexity and more carve-outs for backward compatibility (as was proposed for DICE).
A more consistent and sustainable policy would be to require that any application that could, under any of its derivation paths, consume more than 512 bits of pseudorandomness MUST use the DRNG. All other apps MUST use the HMAC output. For instance PWD BASE85 was designed so that all of its paths obey the 512 bit ceiling. In exchange for the gain in consistency and clarity, it is true that we trade away hardware wallet reach for the time being. That is a fundamental limitation of the already finalized and accepted DRNG application. I would rather see us put energy into noting in the BIP the fact that apps that depend on the DRNG have little to no hw wallet support as of today. The RSA app is already in this category.
Contributors