BIPs — Rejected

Ordinal numbers are serial numbers for sats, assigned when mined and preserved across transactions. I originally posted an earlier draft of the BIP to [bitcoin-dev](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019975.html) in February of last year. We've implemented a wallet and block explorer, with public instances on [mainnet](http://ordinals.com/), [signet](http://signet.ordinals.com/), and [testnet](https://testnet.ordinals.com), and a [wallet](https://github.com/c

Mailing list post: https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE Delving bitcoin discussion: https://delvingbitcoin.org/t/64-bit-arithmetic-soft-fork/397 S/o to the ["Write a BIP" talk at btc++ by Ava Chow](https://www.youtube.com/live/cd-0fG3nwmU?si=1lrwuXibIgxaD6TL&t=14819) to motivate me to actually submit this :-) If you are interested in previous versions of this idea, see https://github.com/bitcoin/bips/pull/1538 and #1533

Summary: This pull request introduces a new Bitcoin Improvement Proposal (BIP) for QES2, a hybrid digital signature algorithm that combines post-quantum cryptography (PQC) with traditional ECDSA. The proposal aims to address the potential vulnerabilities posed by quantum computing while preserving backward compatibility with existing Bitcoin infrastructure. Details: Abstract: QES2 leverages a dual-signature mechanism to incorporate both a post-quantum signature and a classical ECDSA signature

If we find a better way to implement reject unrequested transactions in a backward compatible fashion, I’ll withdraw it. ML post: https://groups.google.com/g/bitcoindev/c/nWUcXBQbLGU Bitcoin Core conceptual discussion: https://github.com/bitcoin/bitcoin/pull/30572 Re-opening there is tx-relay work-in-progress available here: https://bitcoinbackbone.org/. Open comments on #1663 have been fixed.

Expired per BIP-0002 expiration rules. What do you say @maaku @btcdrak @kallewoof ?

This PR integrates the recently released [secp256k1lab ](https://github.com/secp256k1lab/secp256k1lab) prototyping library as a subtree [1] and uses it in the BIP-374 reference code as a drop-in replacement of the currently used secp256k1.py file (copied in from the Bitcoin Core functional test framework in 0c7e54d780d059ebbab345946d7c6adbc61fef15). This is intended to serve as a showcase in the hope of triggering a discussion with BIP maintainers and authors on how to best integrate current and

Author: defenwycke <defenwycke@icloud.com> This BIP removes the 75% witness discount for non-script data, introduces `segOP` as a clean, Merkle-rooted data section, and enforces a 100 KB total data cap per transaction. ### Key Rules - **Data**: OP_RETURN, segOP, or witness items >520 B (Taproot max push size) - **Fee**: Full 4 wu/byte for data (weight += data_size * 3) - **Cap**: 100,000 bytes total per tx - **segOP**: Post-witness, structured, verifiable via Merkle root Normal financial tran

Addresses the issue with needless and reckless rejecting of BIPs solely due to time passing. Instead allow anyone to inactivate a BIP. Rejection should be done based on BIP inapplicability. This does not retroactively undo the rejections made so far. See #1006 discussion for details. Note: I didn't realize there was an .svg source for the process.png file, so I rewrote the thing from scratch in latex. The .tex file is added in this commit. If people prefer, I will try to rewrite in the .svg f

This is a BIP Draft for an `unspendable` key expression that can be used as the taproot internal key. The expression creates a provably unspendable key that is deterministically created with only the descriptor. This allows all participants to verify that the keypath is unspendable, while also hiding that fact from outside observers. Previous discussion on delving https://delvingbitcoin.org/t/unspendable-keys-in-descriptors/304. Mailing list post: https://groups.google.com/g/bitcoindev/c/xWxy8

If we find a better way to implement reject unrequested transactions in a backward compatible fashion, I’ll withdraw it. ML post: https://groups.google.com/g/bitcoindev/c/nWUcXBQbLGU Bitcoin Core conceptual discussion: https://github.com/bitcoin/bitcoin/pull/30572

Delving discussion: https://delvingbitcoin.org/t/implemented-post-quantum-cryptography-pqc-feature-into-bitcoin-core/1320

I had written a [blog post](https://uncensoredtech.substack.com/p/octojoin) about the concept and it was shared on [mailing list](https://groups.google.com/g/bitcoindev/c/aAJrGBf_oS4) in July 2024. There wasn't any response on mailing list but I have discussed it with some developers and there seems to be lot of interest for the idea among users. This is an initial draft and the pull request will help me complete the BIP ASAP. ### TODO - [x] Add rationale section - [x] Add proof of concept

Allowing arbitrary hex data to be wrapped in `sh()`, `wsh()`, or even within the `TREE` argument of a `tr(KEY, TREE)` descriptor enables the representation of currently inexpressible information. Specifically, the absence of this feature limits the representation of non-standard redeem and witness scripts. This occurs because they can currently only be represented as top-level `raw(HEX)` descriptors, which retain only the output script information and lack the ability to preserve the actual scr

The first commit is a scripted diff that corrects field ordering in a number of BIPs which are not consistent with the specified in BIP 2. The second commit enforces that fields are ordered consistently with both BIP 2 and BIP 3. It does not strictly depend on #1820.

[BIP 3 introduced](https://github.com/bitcoin/bips/blob/master/bip-0003.md#changelog) a `Version` field in the header with semver inspired syntax. This PR allows the inclusion of this field and checks that it matches the `<MAJOR.MINOR.PATCH>` format.

This introducing a BIP for the unrequested transaction processing for the mechanism itself. This is building on top of `bip-txrelayv2` proposal. Bitcoin Core conceptual discussion: https://github.com/bitcoin/bitcoin/pull/30572 Partially related ML post: https://groups.google.com/g/bitcoindev/c/nWUcXBQbLGU

This BIP is expired according to BIP-0002 expiration rules. It is linking an ZKCP implementation (pay-to-sudoku). But ZKCP is [broken](http://stevengoldfeder.com/papers/ZKCSP.pdf). It is not mentioned that PTLC's are superior for many applications. The HTLC's are discussed and explained in the lightning-rfc documents, and they are subtly different. It is not explained how an optimal construction can be achieved using miniscript. Tagging @ebfull

This adds support for 3 new modes to CTV: 20 Bytes HASH160 21 Bytes HASH160 + ExtraData 33 Bytes Sha256 + ExtraData This allows LN Symmetry users to use less space and include extra data in any CSFS without enabling OP_CAT or Vectorized CSFS.

This BIP describes a soft fork to add 64-bit arithmetic op codes to bitcoin Implementation: https://github.com/bitcoin/bitcoin/pull/29221

Follow-up from #315 The following BIPs appear to meet the criteria for Final status, but have not been promoted to Accepted by their author yet, so theoretically need ACKs from the authors. Since @genjix is MIA, and @mikehearn ignores Bitcoin, we need to discuss how to handle such actions when BIP champions disappear - BIP 1 allows for me to assign an additional champion to take over, but I'm not sure anyone would necessarily want to do so in these cases. BIP 60: BIP 37 was apparently not clea

This BIP proposes a standard way for making Bitcoin Proof-of-Burn Transactions. There are many possible applications, such as being: - The default trust anchor in decentralised networks. - An effective dos-resistant signal for announcements or other low-frequency events. Please view the proposal here: https://github.com/veleslavs/bips/blob/bip-rpob-tx-template/bip-rpob-tx-template.mediawiki Next steps: - [ ] Update proposal with BIP Number. - [ ] Collect more peer-review. - [ ] Collect review

Opening to allow discussion on the text separately from the Bitcoin Core implementation here https://github.com/bitcoin/bitcoin/pull/30239 Example usage: https://github.com/instagibbs/bolts/commits/zero_fee_commitment https://github.com/instagibbs/lightning/commits/commit_zero_fees

As the BIP process restarts, one general risk in the BIPs is that they become (even more of) a dumping ground for half-baked ideas which even the BIP champion does not work on after the BIP is assigned. While simply never merging new BIPs addresses this issue, this isn't particularly sustainable, and we should instead have some concrete criteria here. BIPs generally fall into a few categories with respect to when they should be considered ready for merge: * they're not particularly controversi

This adds a BIP for a standard for storing fidelity bonds in BIP39 seed phrases. Preferably the BIP number will be a two-digit number to match the BIP44, BIP49, BIP84, BIP86 family of BIPs. Alternatively if a three-digit number is the only way then I suggest BIP-842 because it matches the bip32 derivation path `m / 84' / 0' / 0' / 2 / index`

This is a draft of BIP describing burn of portion of tx fees in bitcoin. It could be an improvement for the Bitcoin economy in the long term. The discussion thread is created here: https://bitcointalk.org/index.php?topic=5371921.new#new

This is WIP, see ML post for context.

Discussions happend here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/thread.html#16806 https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#comments Implementations is partially merged in Bitcoin Core (AEAD, KDF).

A new BIP for _Consensus (Hard Fork) PoST Datastore for Advanced Cryptography and Higher Efficiency Mining_ I have already talked about this a bit in the btc-dev list. I decided to submit at least for draft status, and hope that I can be assigned a BIP number to address/work on this further.

Fixes #

This specification is an application of BIP-32 and BIP-43 which allows a multiple-identity Bitmessage client to derive all needed keypairs from a single seed, which may be the same seed used to derive Bitcoin keypairs without the possibility of collision, greatly simplifying backup requirements and improving the user experience.

This contains the revised draft proposal for BIP98: Fast Merkle Trees, which incorporates all the feedback received so far from the developer mailing list and in-person review. This BIP draft is considered complete by its authors. For context, see the following mailing list discussions: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014932.html https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014935.html https://lists.linuxfoundation.org/pipermail/

This BIP supercedes BIP148 and outlines the methods and actions necessary to prevent unwanted network segmentation and forced isolation caused by non-consensual BIP148 and Segregated Witness deployment.

Design of soft-fork that provides opt-in consensus-based protection from anti-replay attacks. Hard-forking alt-chains would have to be explicitly malicious to avoid these anti-replay protections.

A request for BIP 102 was "a variant that does not require revisiting", so a small step was included per the current thinking on small-step small-shock. _NOTE_: Creates new "drafts" directory to illustrate different proposal technique.

Outlines the rules for selecting and confirming a candidate for “Satoshi Nakamoto” Open to initial edits by all interested parties.