Standardizing an exposure classification for existing outputs (pre-BIP)

The classification system introduces four categories: EXPOSED_AT_REST, EXPOSED_ON_SPEND, NOT_EXPOSED, and UNDETERMINED. These categories aim to standardize how outputs are assessed regarding their vulnerability to being accessed by unintended parties. Notably, this classification is crucial as it influences how software will respond under various conditions, particularly when legacy systems are phased out as proposed in BIP 361.

A substantial aspect of the proposal includes an informative appendix in version 0.4.0, which proposes standard actions associated with each exposure level. This feature intends to guide wallet software on handling different types of exposures consistently across platforms. For example, outputs classified as EXPOSED_AT_REST should be moved to a safer output type as soon as possible, while those classified as EXPOSED_ON_SPEND require action only upon transaction initiation. The draft suggests that such standardized responses could prevent inconsistencies in how security risks are handled across different wallets, thereby enhancing user protection and confidence.

Further development and feedback have led to refinements in the classification document, now available in version 0.6.0, where the prose has been condensed for clarity and directness, addressing previous feedback about the verbosity and complexity of earlier versions. Additionally, specific rules regarding address reuse have been tightened, providing clearer guidelines for managing outputs sharing the same script. The revised appendix retains the core advice but adjusts the guidance for sweeping funds when spending from scripts exposed on spend, recommending consolidating transactions involving all outputs paying that script.

The ongoing debate includes perspectives on whether these classifications and the detailed guidance provided are necessary or redundant given existing knowledge and documentation within the community. Some argue that the distinctions and edge cases addressed in the draft are crucial for ensuring uniform behavior across implementations, especially in light of significant protocol changes like those proposed in BIPs 360 and 361. Others feel the information might be too trivial or already covered by existing protocols.

The final decision on the publication and adoption of these standards hinges on community feedback, particularly emphasizing real-world applicability and the necessity of formalizing these classifications in the BIP repository. The dialogue continues in the pull request here, where community members can contribute their insights and influence the outcome.