Please see latest draft and conversation in the bips repository PR #1378
-
-
Save dhruv/5b1275751bc98f3b64bcafce7876b489 to your computer and use it in GitHub Desktop.
Pushed revision 92 removing the BIP 61 REJECT
p2p message which is no longer used.
On rekey, it may help strengthen entropy to feed the last 32 bytes of keystream into the HKDF:
... The IV is initialized to 0 and incremented on every re-key event.
k0 = key
iv = 0
k0 = HKDF_EXPAND(prk=k0, hash=SHA256, info="BitcoinK_Rekey", L=32)
ks0, k1 = ChaCha20DRBG(k0, iv)[0:4064], ChaCha20DRBG(k0, iv)[4064:4096]
iv = iv + 1
k1 = HKDF_EXPAND(prk=k1, hash=SHA256, info="BitcoinK_Rekey", L=32)
ks1, k2 = ChaCha20DRBG(k1, iv)[0:4064], ChaCha20DRBG(k1, iv)[4064:4096]
iv = iv + 1
k2 = HKDF_EXPAND(prk=k2, hash=SHA256, info="BitcoinK_Rekey", L=32)
ChaCha20Forward4064DRBG(key) = ks0 || ks1 || ks2 || ...
We now have a bips repo PR and will continue community engagement there.
Is there any reference code (or other library?) for your x-only ECDH secret derivation? There are several places with Gordian Envelope, in particular for pairing between a coordinator or watchtower and holders of bitcoin keys where we'd like to encrypt the PSBTs. This would enhance the security of our current UR PSBT approach that a dozen wallet vendors support that can optionally be transported with animated QRs.
Yes, see
https://bip324.com/sections/code-review/ may also be helpful to navigate the jungle of the PRs.
Be aware that our key exchange encodes the EC points contributed from both sides using Elligator Swift.
I've created a repo for now to get the large outstanding questions under discussion. Once we are in reasonable shape, I will update again here or make that repo public.