The daily scrum is designed for the team to coordinate and adapt its progress within the sprint. At a minimum, the product team should be in attendance. Typically, the invite list should also include the product manager and scrum master or delivery manager.
Although stakeholders and others outside of the team are generally welcome to attend, the intended audience is the team. Any attendees outside of the team should be observers only.

Velocity is a key Scrum metric that measures the amount of work a team can deliver during a sprint.

During Sprint Planning, the team’s velocity is used to determine the number of product backlog items to tackle. Based on this, the amount of work and the delivery date can be estimated. At the end of the Sprint, the actual velocity will be used in the calculation for the next one.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal. The Sprint Goal is an objective set by the Scrum Team during Sprint Planning and captures the hypothesis that the team wants to test, a goal it wants to achieve, or an experiment to run. Although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not. This would be unwise considering the core premise of Scrum: we can't create detailed plans for the future. Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog.

A team might learn that a technology they picked does not perform as expected. Or a key feature needed to reach the Sprint Goal was missed during the Sprint Planning. As issues emerge, changes to the Sprint Backlog may be warranted in order to reach the Sprint Goal. The Development Team will then re-negotiate the Sprint Backlog with the Product Owner. In short; a Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.

The Daily Scrum presents Development Teams with an excellent opportunity to inspect and adapt upon their progress to the Sprint Goal and make adjustments to the Sprint Backlog when deemed necessary.

By definition, a Sprint cannot be longer than one calendar month. Therefore any so-called Sprint of a longer duration will be invalid, and it would mean that Scrum principles are not being followed.
Note that the Agile Manifesto allows up to two months between each delivery of customer value, albeit with a preference towards shorter timescales. Iterations of greater than a month may therefore be arguably agile, although they would not be Scrum-compliant.
Also, bear in mind that Scrum Sprints must result in *potentially* releasable increments and that the time between actual releases may therefore exceed one month. However, if the release of an increment equates to the delivery of customer value, and if the release is deferred for longer than two months, then the Scrum implementation (although strictly valid) would not conform with the principles of the Agile Manifesto.
Therefore be sure to time-box Sprints to no more than one month in length, and aim to release an increment into production at least every two.