some info about upcoming mini-updates and the mini-roadmap: - a planned transition to a new proof format (TAPE verifier), natively supported by hfhe (field core), is scheduled for next week, it will lead to faster processing of heavy txs and increased security, however, this also has a trade off, as a migration to the new ct-format (client side manual re-encryption) will be prepared (stress free, one tx), details will be provided later, once we've completed this - expanded circle functionality and app launchpad directly within the network, minimal deployment at startup, and a flexible way to deploy code, debug, and configure security settings, circles from the examples are becoming a truly universal tool for running proprietary private computing. - a small breakthrough in on-chain inference (a fully open LLM circle, optimized specifically for ML, has become even faster), in the app launchpad, you simply select the interface, an available model, and deploy with a customizable access level - a small release of a private tx example on the EVM network (evm sepolia/octra devnet ), a non-blocking pool, etc - bridge update and stealth bridge capability - other minor thing 1: a lite node will be available any day in the next two weeks (along with a convenient launch container) - other minor thing 2: mini-paper release ps: we spent the last week working on security, so things have been a bit quiet some ppl tried to sour the mood, but we’re not too bothered, work goes on thanks for your support Chiefs and wish you a good start to the new week

a mini update, which actually turned out to be quite large, we updated the library and added the most important part - a recrypt that turns the HFHE (pvac ver) into a circuit with unlimited computation chain depth (we also added a bunch of examples of how to use it) this is an important part and the penultimate one before the next final update,if you want to understand what this means, run benchmarks and review past results (hfhe against everything) in the public test, 63 consecutive reset stages pass with support growing to 16 terms per stage and resetting back to 4 terms run: make test-hfhe-native PVAC_HFHE_DEPTH_ROUNDS = 63 make test-hfhe-depth github.com/octra-labs/pvac_h…

nature is clearing up, ignore the slop-noise, let the speculators and gambling addicts be blown away, there's a lot of interesting things ahead

Simple obfuscation of wallets, transfers and programs doesn't feel like the endgame for privacy. Operating directly on encrypted data does. FHE ties it all together neatly, with nodes performing heavy but meaningful tasks, while keeping the state composable and verifiable.

the next batch of mini-updates was just added, we recommend updating webcli as soon as possible more webcli changes coming this week: accessible github production cycle, less hassle with manual builds, new security improvements, etc. repo: github.com/octra-labs/webcli stay alert for your safety

a mini update regarding webcli - many security improvements have been added that make it worth updating your version to the latest version (don't delay with the update) we’re also reinstating the bounty program as an open portal with challenges after receiving good findings from researchers, we'll share more in the coming days once the concept is finalized github.com/octra-labs/webcli

currently studying @octra, made a neat chart. i'm working on the formal verification (in lean 4) of their hfhe system, which is slowly approaching completion, but i still need to plug some knowledge gaps and do more investigative work. additionally planning on doing more graphs that demonstrate the encryption and decryption process, and how the homomorphic operations work.

there will be a few mini-updates ( mini-paper) this weekend (with a detailed description on monday), nothing "huge" or anything like that, just routine stuff related to the lite node release and some info for validators, there will also be a major webcli update and new features for circles thank you everyone for your support

you can just do things (while the vibe slopers complain about the lack of docs or another reason), ignore the noise, stay focused and build with your hands

An in-depth overview of the @octra bridge by @DefiLlama Research team is out. It covers how assets can move between public and private states, and not just chains. The bridge is becoming a standalone product, and also part of a broader EVM privacy stack being released gradually.

mini update (pre-night devbuild): the devnet and main net RPCs, as well as both scanners, have just been updated, adding support for a very important element - formal verification, as we said earlier, .aml supports native formal verification backed by Coq lang and belongs to the Standard ML family, which imposes certain obligations on us, we were not planning to announce new features specifically today, but one situation, which is indirectly related to formal verification and more likely belongs to the class of silly bugs in an independent devs's program, made us decide not to wait and to update support right now, especially considering the upcoming availability of lite nodes for everyone who wants to run one, we decided to speed up the process with the latest mainnet beta features for your convenience we deployed 4 progs and each of which is formally verified- the first program is clean when the second has a warning, the third has a clear stupid bug and the fourth is a standard OCS01 token that is also formally validated and has passed attestation,all programs are valid and compile successfully fyi: the token standard is not obliged to answer for a dev's mistake when he shoots himself in the foot, but an additional element in the form of formal verification can stop him from making such mistakes. so, here are the 4 programs: clean, warning, clearly broken, and a canonical token standard, each with a full formal verification trace in the corresponding scanner tabs clean prog: octGcYxnDL8SqkQRzSsewfkXC1uApwhMSTiKP1AAGwPXVmU has warning: octrascan.io/address.html?ad… issues: octrascan.io/address.html?ad… OCS01 token: octrascan.io/address.html?ad… when a user looks at a program, he no longer blindly believes that "the dev is right", he relies on a formal verification procedure that minimizes the human factor among other things the scanner now shows the exact validator reward for each epoch, which is a useful feature for economic accounting ps: the next update concerns the mini-paper (HFHE, pvac and hardness assumptions, cryptography, etc) and will appear in the coming days, together with a major webcli update, .aml docs, and the full formal verification spec, if there is anything interesting, we will inform you in a separate announcement, but for now that's all thanks all

the upcoming release will open up new opportunities for formal verification auditing directly in @octrascan, where all problems and warnings will be clearly reflected, the full result is immediately available in the corresponding tab

an additional optional step is being introduced before deploying programs to @octra - formal verification the new version of webcli compiler will require formal verification (which can be optionally skipped for now, but it's best not to), the dev will have to write a proof system with strict validation that his program has predictable and safe behavior and the logic does not lead to problems, this will remove a large class of bugs and logical errors in complex systems, programs that are formally verified will be marked as more reliable and secure in the @octrascan and an additional window with a full trace will be added @AppliedLang is natively supported by Coq and ROCQ via @ocaml_org tools

a boring lang is a sign of maturity, rust will become an industry standard if it becomes boring (this is a requirement for adoption among real devs)

announcing octra starter pack our trusted partner will configure a full octra node on raspberry pi or mac mini and ship it worldwide or run it for you payments in OCT, ETH, BTC, XMR and stablecoins, with 100% of proceeds converted to OCT pre-sales opening this summer, notis on

today, among other things, we are building the ideal candidate for the lite node, which everyone will be able to run on any hardware, lite node can be used as a store for the treechain (if you have an SSD) or in the simplest version - a signal node, DHT transmitter, and a quick verifier of epoch headers (without heavy proofs) today we have the following configuration in the tests: @Raspberry_Pi version 5, 16 gb RAM, IRasptek Kit, PCIe 4.0 NVMe M.2 SSD (P3 plus, 1TB) and PCIe to M.2 NVM Shield (X1001) optional: keyboard for PI5 and mini-monitor for it the results and economics of mining and validation will be published asap

pre-mini update (dev version, night build): extended feature support at the rpc level has been updated, with program exec, multi exec, value call, large storage, and fhe mul (a function with a recrypt and unlimited operation depth) now available on the mainnet btw, we've managed to develop a strategy where dev updates are released on friday and general updates are released on monday (with an unlimited number of pre-mini updates like this one throughout the week) if there's something important for the community (besides mini-updates) we'll report about it separately

it’s probably a good time to make a mini update

Btw, a fun fact about ML and contex mixing - all the time at the end of school and the beginning of university, I was fascinated by data compression and algorithmic codecs. This is essentially how I started my career as a C developer. There's one fun fact about compression that just occurred to me: the legendary Matt Mahoney, who created the most powerful algorithmic coder and founded the PAQ family, variations of which constantly won the Hutter Prize for data compression, essentially laid the foundation for the concept of ML through data compression, since algorithmic codecs are built on predictive models and sigmoid functions for constructing frequency context models based on the data type. So, what I'm getting at is that in our "narrow" circle of those involved in this topic, there was a clear justification for what AGI is expressed through data compression. As you know - you can't bypass the Shannon limit, that's a hard math law. However, the Shannon limit is bound to a specific predictive model. If an algorithmic codec can build such a profound, context aware model of the world that its 'guessing' pushes the practical compression down to the data's absolute, intrinsic complexity, that might just be the key to unlocking AGI. If you want to start approaching AGI, you need to pay attention to data compression, bc if a context codec model can "decompress" and predict and compress the full context of Wikipedia (which in a compressed format has entropy practically within the limits of Shannon), then this may mean that one of the most important steps towards AGI has been made. PVAC-HFHE uses our own version of algorithmic mixing to compress public keys for the HFHE engine. You can see it here: github.com/octra-labs/webcli… Now that we're head over heels in working on circles in @octra with the goal of bringing interesting use cases, this has made sense again and we've developed a passion for trying out new hypotheses. So yes, one of the new directions for octra is ML and contextual transformation, because the treechain structure and data model are perfectly compatible with the goals of ML inference. We'll continue working on this (I think every day now) and will report if we find anything interesting.