If the multi-sig balance is 10BTC and you have a Note with a 1BTC balance you will automatically receive 10% of 0.0333BTC every day you keep your Note funded, which is 0.0033BTC a day.

Basically, main people lost access due to travels while people still with access didn't have the right credentials to solve basic issues that caused withdraws to get stuck on the back-end. I've been assured that nothing has been lost and that all will be taken care of tomorrow meaning all currently pending withdraws will be processed and things return back to normal. It was an unfortunate situation is all!

Isn't that exclusively for posts on the English board?

ANN design was updated, see first post in this thread. It now includes a step-by-step walkthrough showing all actions you can make on our our website.

The initial escrow deal was that we were supposed to receive the funds back when the review campaign ended a while ago. We did not request the funds back so they are still with minerjones. We'd be happy to adhere to the 7 day delay rule you proposed, and I will ask minerjones if it's possible for him to confirm here that this rule will be enforced and the amount held by him at the moment.

Changing password and email occasionally has always been a good security practice what changed now?

Regular password expiry is a common requirement in many security policies. However, in the Password Guidance published in 2015, we explicitly advised against it. This article explains why we made this (for many) unexpected recommendation, and why we think it’s the right way forward.

Let’s consider how we might limit the harm that comes from an attacker who knows a user’s password. The obvious answer is to make the compromised password useless by forcing the legitimate user to replace it with a new one that the attacker doesn’t know. This advice seems straightforward enough.

The problem is that this doesn’t take into account the inconvenience to users - the ‘usability costs’ - of forcing users to frequently change their passwords. The majority of password policies force us to use passwords that we find hard to remember. Our passwords have to be as long as possible and as ‘random’ as possible. And while we can manage this for a handful of passwords, we can’t do this for the dozens of passwords we now use in our online lives.

To make matters worse, most password policies insist that we have to keep changing them. And when forced to change one, the chances are that the new password will be similar to the old one.

Attackers can exploit this weakness.

The new password may have been used elsewhere, and attackers can exploit this too. The new password is also more likely to be written down, which represents another vulnerability. New passwords are also more likely to be forgotten, and this carries the productivity costs of users being locked out of their accounts, and service desks having to reset passwords.

It’s one of those counter-intuitive security scenarios; the more often users are forced to change passwords, the greater the overall vulnerability to attack. What appeared to be a perfectly sensible, long-established piece of advice doesn’t, it turns out, stand up to a rigorous, whole-system analysis.

The NCSC now recommend organisations do not force regular password expiry. We believe this reduces the vulnerabilities associated with regularly expiring passwords (described above) while doing little to increase the risk of long-term password exploitation. Attackers can often work out the new password, if they have the old one. And users, forced to change another password, will often choose a ‘weaker’ one that they won’t forget.