btw, the day wasn't wasted, we discovered another bottleneck that required special attention, so we decided to deduce it from a proof-of-concept form, rather than simply as an algorithm and separately decided to prove that after any write, the state remains synchronized among all participants, a quorum requires both thresholds (number and weight of participants) to be met the learning context itself, based on moving consensus, doesn't change the vote, lock, or finalization phase. this was a rather specific problem, so we decided to formalize it (sorry for the format - the OPD platform will be available in a couple of days, but for now, we're writing the descriptive part manually), so you can take a look at it here: gitlab.octra.org.uk/octra/li… the new release marker is now available for validators, pls upgrade as usual: sh controls/upgrade.sh sh controls/upgrade.sh --apply sh controls/stat.sh – at London, England

yeah, also coming – at London, England

releasing the latest hand made bits to improve fault tolerance (the upgrade will be required on weekends), as well as a portal with all changes and the proposal log, which stands out for its activation rules, the name has been coined -OPD (octra protocol document), everyone will be able to participate in proposals for changes. OPDs are needed to structure all the changes and separately highlight explanations of why they have been made in the first place, and to propose a discussion. – at London, England

Shabbat shalom – at London, England

yes – at London, England

a mainnet upgrade is a matter of days, not weeks or months (the capabilities and featuresare already visible in the devnet) – at London, England

agreed, we’re working on it btw – at London, England

use circles in octra to host private resources, apps, data, etc, there will be nothing to steal, and there is no such concept as exit nodes – at London, England

indeed – at London, England

@octralex calls it loops, i call it zaloops (in the russian manner) – at London, England

hack yourself before other do (the policy we ourselves adhere to). fyi: an automated fuzzing search engine based on slop generators (by @octralex) found critical crap in ALL projects we've ever interacted with (since there's already context), some have been fixed, others haven't been revealed yet and may not be, given the mixed reactions. what a time to be alive – at London, England

ca? – at London, England

a new unscheduled release is now available for vals. please upgrade your nodes (a lot has been done on recovery and sync + an old bug from an earlier implementation at the vm level has been fixed) * * the node could process the same epoch twice, and the root at that moment was different, when building and checking proposals at the consensus level, it was specified as 32 raw bytes (the earliest implementation from the end of 2024),and when using the epoch from the head, it was transmitted as a 64-hex string, so the bug was found during pre-release main net testing for mem compatibility of different program envs upgrading is easy - sh controls/upgrade.sh sh controls/upgrade.sh --apply sh controls/stat.sh github.com/octra-labs/lite_n… – at London, England

we established these rules for ourselves 3 years ago – at London, England

6 months ago.

I like – at City of London, London