Is there an active list of BIPs currently open for voting?

This question is based on a misconception. Miners do not vote on proposals. Consensus changes to Bitcoin are made by the entire ecosystem transitioning to new rules that they choose, by running node software that enforces these rules.

Miners are a part of that ecosystem, and their enforcing of new rules is part of what makes them safe. But if miners refuse to adopt a rule change that the rest of the ecosystem demands, they have no choice. If a rule is implemented and enforced by the network's full nodes, then miners who produce blocks that do not follow those rules will simply be ignored.

Everything works better however, if miners and the rest of the ecosystem do not diverge on what rules they're demanding and enforcing. For that purpose, several past backward-compatible consensus changes ("softforks"), have used a mechanism where miners can signal that they're ready to enforce a particular rule, and once a certain threshold is reached, all of them (including non-miners) start enforcing those rules in lockstep.

So in reality, such a signalling mechanism is for coordination, not for voting. Proposals may go through even without miners' consent, but it's better for everyone if things are synchronized.

Previous softforks that have employed such a coordination mechanism are:

• BIP34 Height in coinbase (2012)
• BIP65 OP_CHECKLOCKTIMEVERIFY (2014)
• BIP66 Strict DER signatures (2015)
• BIP68/112/113 OP_CHECKSEQUENCEVERIFY and associated relative locktime semantics (2016)
• BIP141/BIP143/144 Segregated witness (2016)
• BIP147 Dealing with dummy stack element malleability (packaged together with BIP141/BIP143/BIP144) (2016)
• BIP91 Reduced threshold Segwit MASF (2017)
• BIP341/BIP342 Taproot (2021).

The specific rules used by each of these differ (see my answer here for details). Some used a simple threshold of 750 or 950 blocks over the past 1000; some used BIP9.

Earlier softforks (BIP16, BIP30) were coordinated at the human layer. BIP16 did use signalling in blocks as well, but only to inform changes made to the software. The actual activation was time based (as soon as enough support was signalled, node software was modified to start enforcing new rules after a certain date). As BIP16 did have a competing proposal (BIP17), it was easy to misinterpret support for one or the other as a vote. Perhaps that is where the misconception originates.

Right now (as of October 2021), there are no unactivated consensus changes implemented in node software, so there is nothing to signal for.

Disclaimer: I am a (co-)author of some of the BIP documents listed in this answer (BIP30, BIP66, BIP141/143/144, BIP340/341/342).

People wishing to submit BIPs, first should propose their idea or document to the [email protected] mailing list. After discussion it will be published Here