|
| 1 | +# BIT-0000: Title of BIT |
| 2 | + |
| 3 | +- **BIT Number:** 0000 |
| 4 | +- **Title:** Title of the BIT |
| 5 | +- **Author(s):** [Name(s) and contact information] |
| 6 | +- **Discussions-to:** [URL for discussion thread] |
| 7 | +- **Status:** Draft |
| 8 | +- **Type:** Core | Subtensor | Networking | Interface | Meta | Informational |
| 9 | +- **Created:** [Date] |
| 10 | +- **Updated:** [Date] |
| 11 | +- **Requires:** [BIT number(s) if applicable] |
| 12 | +- **Replaces:** [BIT number(s) if applicable] |
| 13 | + |
| 14 | +## Abstract |
| 15 | + |
| 16 | +A short (~200 words) description of the issue being addressed and the proposed solution. |
| 17 | + |
| 18 | +## Motivation |
| 19 | + |
| 20 | +The motivation section should clearly explain why the existing protocol specification is |
| 21 | +inadequate to address the problem that the BIT solves. This is critical for BITs that want to |
| 22 | +change the Bittensor protocol. It should clearly explain why the solution outlined in the BIT |
| 23 | +is beneficial to the Bittensor ecosystem. |
| 24 | + |
| 25 | +## Specification |
| 26 | + |
| 27 | +The technical specification should describe the syntax and semantics of any new feature or |
| 28 | +proposed change. The specification should be detailed enough to allow for implementation |
| 29 | +without needing to interpret the proposal’s intent. |
| 30 | + |
| 31 | +## Rationale |
| 32 | + |
| 33 | +This section describes why particular design decisions were made. It should address alternative |
| 34 | +designs and why they were not chosen, and should discuss the potential impact of the proposal |
| 35 | +on the existing system. |
| 36 | + |
| 37 | +## Backwards Compatibility |
| 38 | + |
| 39 | +All BITs that introduce backward incompatibilities must include a section describing these |
| 40 | +incompatibilities and their severity. The BIT must explain how the author proposes to deal with |
| 41 | +these incompatibilities. BIT submissions without a sufficient backward compatibility treatise |
| 42 | +may be rejected outright. |
| 43 | + |
| 44 | +## Reference Implementation (Optional) |
| 45 | + |
| 46 | +If applicable, include a link to a reference implementation that demonstrates the feasibility |
| 47 | +of the proposal. This implementation may be partial or fully complete. |
| 48 | + |
| 49 | +## Security Considerations |
| 50 | + |
| 51 | +All BITs should consider the security implications of their proposals. This section should |
| 52 | +address potential attack vectors, vulnerabilities, and how the proposed changes affect the |
| 53 | +overall security of the Bittensor protocol. |
| 54 | + |
| 55 | +## Copyright |
| 56 | + |
| 57 | +This document is licensed under [The Unlicense](https://unlicense.org/). |
0 commit comments