Kenneth Heutmaker [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2016-05-14 to 2016-08-23
💬 Posted a total of 2 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:53:01

- reply

📅 Original date posted:2016-08-23
📝 Original message:> Additionally, BIP 111 (NODE_BLOOM service bit) has been implemented in Bitcoin
> Core and derivatives; it is unclear if used by clients yet. Can developers of
> such clients please comment and let me know: 1) if their software supports
> this BIP already; 2) if not, do they intend to support it in the future?
> If and only if there are any clients using this service bit already, I will
> update BIP 111 to Final Status in 2 weeks also.
Multibit is adding detection of the NODE_BLOOM bit in the next 2-3 weeks.
SPV is kinda broken if the wallet doesn’t do this detection. If your wallet connects only to nodes that don’t support bloom filtering, the wallet never gets updates. We have had a spike in users reporting that their wallet isn't getting updated. To compound the problem, they rescan the blockchain and lose all of their transaction history. It has caused much panic among less technical users.
We believe that failing to detect the NODE_BLOOM bit is the culprit, although it is non-deterministic, so we aren't certain.
I imagine that other SPV wallets are having similar issues. BIP 111 really isn’t optional at this point, so it should be marked final.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160823/2e38b60b/attachment.sig>

2023-06-07 17:50:43

- reply

📅 Original date posted:2016-05-14
📝 Original message:> * What if the "old" wallet has used more then 1000 addresses? I guess
> some wallets do not even create a lookup window up to 1000 addresses.
> There is a high chance of loosing funds when doing sweep (move all funds
> to a new wallet) operation.
If that is the case, the wallet is not following the standard. The wallet hierarchy standards like BIP44 specify how to walk an address chain. They all specify that you should keep going until you don’t find any more used keys within the lookup window. If a wallet leaves gaps that are too big, that is also not compliant.
In any case, if the sweeping wallet understands how the “old” wallet uses the hierarchy, it can be safely swept without a potential loss of funds.
> * I guess most or maybe all wallets will keep all keys (the
> "lookup-window" keys) in the wallet database which could affect
> performance [4]
Yes, wallets with more addresses take more time to process.
> * I guess most wallets do not offer "moving the funds to a new seed" [5]
> which results in not solving the problem of a "lost" or "compromised"
> wallet and implies wrong security to the enduser.
Some wallets do and for those that don’t, implementing it is straight forward if it already implements BIP32. It’s just a matter of knowing how the old wallet uses the hierarchy and prioritizing the work.
> * If I import a bip39 mnemonic into a hardware wallet (assume Trezor or
> Keepkey) I have to type in the words into my computer which bypasses
> some of the security my hardware wallet provides me (MITM seed attack).
> Together with the point above this reduces the security of a wallet (in
> particular cold storage significant).
Both TREZOR and KeepKey have developed strategies to prevent MITM attacks during seed recovery. TREZOR asks for the words in a random order and in some cases, adds ’noise’ words. KeepKey uses a rotating substitution cipher.
> I just wanted to point out that importing a wallet is a tricky step
> especially cross-wallet imports (I think cross wallet imports is an
> experts job without further improvements).
I don’t think it is as hard as you think. If a wallet uses BIP32 HD, all of the hard code is already implemented. It is just a matter of stringing the correct sequence of steps together.
Also, if the new hierarchy is under a separate purpose code as specified in BIP43, there is no need to create new seed. The BIP44 hierarchy and the new hierarchy can be extended from the same seed.
—
Ken Heutmaker, KeepKey