Published on: 2016-08-25T09:02:27+00:00
The discussion on the bitcoin-dev mailing list revolves around the consideration of whether certain Bitcoin Improvement Proposals (BIPs) should be treated as final or not. BIP44, which is widely used by many wallets without any real-world issues, is suggested to be set as final despite its imperfections. Jonas Schnelli initially expresses disagreement with the development paradigm of "maybe detect funds," but later clarifies his statement. The discussion also raises concerns about the gap limits in BIP44 and the potential issues it may cause for merchants who generate multiple addresses. There is a conversation thread discussing the sequential scanning of blockchain transactions and a hypothetical scenario where a user generates 21 addresses, with only one receiving funds immediately and another receiving funds after 180 days. This scenario triggers a resize+20 of the address-lookup-window, but the wallet would need to go back 180 days to detect the transaction on the second address. The discussion ends with a question about whether there is a misunderstanding in this hypothetical scenario.Andreas Schildbach discusses the BIP44 protocol and its lack of encoding a seed birthday necessary for SPV wallets to scan from the beginning of the blockchain. However, some wallets still interoperate on this standard. The status of the protocol depends on its usage rather than its quality. Additionally, BIP43 is suggested to be made final as it only advises other BIPs on how they could do things.Jonas Schnelli raises a concern about the BIP44 Gap Limits, stating that if 20 unused addresses are found in a row, the software stops searching for used addresses beyond that point. The discussion clarifies that this does not require a transaction rescan back to the genesis block every 20 addresses and suggests starting scanning sequentially from the genesis block or a block around the time when BIP44 was written.The discussion highlights potential misdesigns in BIP39 seed phrases and BIP44 gap limits for Bitcoin wallets. The absence of a version number in BIP39 seed phrases raises questions about deriving addresses from an old seed phrase when new derivation methods are used. The BIP44 gap limit, currently set at 20, is also questioned regarding whether it requires a transaction rescan back to the genesis block every 20 addresses or if wallet recovery after BIP44's implementation is necessary for full access to a blockchain indexed by addresses. Overall, the discussion reflects concern for potential issues and limitations in the current design of Bitcoin wallets.Luke Dashjr criticizes the design of BIP39 and BIP44, stating that they are poorly designed. He mentions several reasons, including limited support in Electrum and the complexity of multiple accounts breaking the property of using the same wallet instance on different devices. He also points out inconsistencies and potential problems with BIP39 seed phrases not having a version number. He suggests separating BIP43 from BIP44 to allow for the development of a better standard.Kenneth Heutmaker raises concerns about broken Simplified Payment Verification (SPV) wallets that lack bloom filtering detection. SPV wallets connect only to nodes that support bloom filtering, and if they don't get updates, the wallet becomes outdated, causing panic among users who end up rescanning the blockchain and losing their transaction history. The discussion highlights the need for robustness against abusive peers and the challenges in achieving this due to the design of bloom filtering.BIP 111, also known as NODE_BLOOM service bit, has been implemented in Bitcoin Core and derivatives, but it is unclear if clients are using it. Multibit plans to add detection of the NODE_BLOOM bit, and SPV wallets are advised to update to respect NODE_BLOOM. The discussion emphasizes the importance of detecting the NODE_BLOOM bit to avoid issues with outdated SPV wallets and recommends the use of the new DNS seeder filter option.Luke proposes updating several BIPs to Final Status if no objections are raised, including BIP 39, 44, 67, 125, and 130. He also suggests upgrading the status of BIP 43 to Active as it guides the creation of new BIPs. Developers of Bitcoin clients are requested to comment on their software's support for BIP 111 (NODE_BLOOM service bit) and their intention to support it in the future. If any clients are already using this service bit, BIP 111 will be updated to Final Status in two weeks.
Updated on: 2023-08-01T18:58:06.605884+00:00