ais

AI agents spawning more agents (on repeat) lobbying & pushing an agenda to affect politics👍

@mentatminds What happens when SoS goes down?

100% of Mentat SoS investors are in profit. The Sum of Subnets index has only gone up since the launch of the index 🔥

For anyone concerned about supply chain attacks in the future, you can implement a second layer of protection using the following strategy: - Move btcli to a dedicated Linux VM and install a network proxy such as Squid (note: this is a network-level proxy, not a wallet proxy). - Update your firewall rules to block all outgoing traffic except for connections through the network proxy. - Whitelist only essential domains (e.g., OS updates, PyPI, etc.) to pass through the proxy. - Use a tool like proxychains to force traffic through the proxy, since btcli does not natively support network proxies. The goal is to ensure that even if core components are compromised and keys are accessed, the malware will be unable to easily exfiltrate data to the attacker, giving you valuable time to respond. Below is a proposed implementation for this strategy on the openSUSE distribution. I hope the community can build upon this to make it even safer and more portable for other distros: Step 1 — Prereqs & network sanity ----------------------------- systemctl enable --now firewalld zypper refresh Step 2 — Squid — install & lock to allowlist ------------------------------ zypper install -y squid cat > /etc/squid/squid.conf <<'EOF' visible_hostname BCS-001 http_port 127.0.0.1:3128 via off forwarded_for delete pinger_enable off # Allowlist domains (adjust as needed) acl allowed_domains dstdomain \ .pypi.org \ .pythonhosted.org \ .opensuse.org \ .opentensor.ai \ .github.com \ .githubusercontent.com \ .opensuse.net.br \ .ufpr.br \ .usp.br \ .uepg.br \ .cedia.org.ec acl allowed_tls_sni ssl::server_name \ .pypi.org \ .pythonhosted.org \ .opensuse.org \ .opentensor.ai \ .github.com \ .githubusercontent.com \ .opensuse.net.br \ .ufpr.br \ .usp.br \ .uepg.br \ .cedia.org.ec # Allow CONNECT to 443 and 9944 (btcli WSS) acl SSL_ports port 443 9944 http_access deny CONNECT !SSL_ports # Policy http_access allow allowed_domains http_access allow CONNECT allowed_tls_sni http_access deny all EOF mkdir -p /var/cache/squid /var/log/squid chown -R squid:squid /var/cache/squid /var/log/squid squid -k parse && squid -z systemctl enable --now squid When changing paramaters: squid -k parse && systemctl reload squid Quick check: ss -lntp | grep 3128 curl -I http://127.0.0.1:3128 # 400 Bad Request is fine (proves Squid answers) Step 3 — Firewalld, force egress via Squid, keep SSH, DNS & NTP ------------------------------ # SSH inbound (v4+v6) firewall-cmd --permanent --add-service=ssh firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p tcp --dport 22 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -p tcp --dport 22 -j ACCEPT # Allow replies out firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # Loopback I/O firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -i lo -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 0 -i lo -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -o lo -j ACCEPT # Local to Squid firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 127.0.0.1 -p tcp --dport 3128 -j ACCEPT # DNS (only to your resolvers) firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p udp -d 8.8.8.8 --dport 53 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp -d 8.8.8.8 --dport 53 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p udp -d 1.1.1.1 --dport 53 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p tcp -d 1.1.1.1 --dport 53 -j ACCEPT # Allow DHCP client traffic (needed for dynamic IP assignment) firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p udp --sport 68 --dport 67 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p udp --sport 67 --dport 68 -j ACCEPT # Optional but useful: allow outbound traffic to your LAN gateway for routing # (replace 192.168.1.1 with your actual gateway IP) firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 1 -d 192.168.1.1 -j ACCEPT # Allow Squid's own egress on 80/443/9944 (owner match) SQUID_UID=$(id -u squid) firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 5 -m owner --uid-owner $SQUID_UID -p tcp --dport 80 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 5 -m owner --uid-owner $SQUID_UID -p tcp --dport 443 -j ACCEPT firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 5 -m owner --uid-owner $SQUID_UID -p tcp --dport 9944 -j ACCEPT # (Optional) NTP firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -p udp --dport 123 -j ACCEPT # Block everything else (egress) firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 100 -j DROP firewall-cmd --permanent --direct --add-rule ipv6 filter OUTPUT 100 -j DROP # Default inbound posture firewall-cmd --set-default-zone=drop firewall-cmd --reload Step 4 — Zypper ------------------------------ # Make zypper use the proxy grep -q '^proxy=http://127.0.0.1:3128' /etc/zypp/zypp.conf || echo 'proxy=http://127.0.0.1:3128' >> /etc/zypp/zypp.conf # Disable delta RPMs (avoids 403s on deltainfo at some mirrors) if grep -q '^ *download.use_deltarpm' /etc/zypp/zypp.conf; then sed -i 's/^ *download\.use_deltarpm.*/download.use_deltarpm = false/' /etc/zypp/zypp.conf else echo 'download.use_deltarpm = false' >> /etc/zypp/zypp.conf fi # Use official CDN (download.opensuse.org) — flexible: we also allow regional mirrors in Squid REL="15.6" zypper rr repo-oss repo-non-oss repo-update repo-update-non-oss repo-backports-update repo-sle-update 2>/dev/null || true zypper ar -f "download.opensuse.org/distribution/l…${REL}/repo/oss/" repo-oss zypper ar -f "download.opensuse.org/distribution/l…${REL}/repo/non-oss/" repo-non-oss zypper ar -f "download.opensuse.org/update/leap/${REL}/oss/" repo-update zypper ar -f "download.opensuse.org/update/leap/${REL}/non-oss/" repo-update-non-oss zypper ar -f "download.opensuse.org/update/leap/${REL}/backports/" repo-backports-update zypper ar -f "download.opensuse.org/update/leap/${REL}/sle/" repo-sle-update # Disable any metalink= lines (optional—since we now allow mirrors in Squid, you can keep them; disabling gives you deterministic CDN only) # sed -i -E 's/^metalink=/#metalink=/' /etc/zypp/repos.d/*.repo zypper -vvv refresh Step 5 - Proxychains -------------------------------- zypper install -y proxychains-ng # Configure proxychains (path may be /etc/proxychains4.conf on some builds) cat >/etc/proxychains.conf <<'EOF' strict_chain proxy_dns [ProxyList] http 127.0.0.1 3128 EOF Step 6 - Btcli wrapper -------------------------------- # btcli wrapper that avoids proxy env loops cat >/usr/local/bin/btc <<'EOF' #!/usr/bin/env bash unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY exec proxychains4 btcli "$@" EOF chmod +x /usr/local/bin/btc Step 7 - Pip -------------------------------- cat >/etc/pip.conf <<'EOF' [global] proxy = http://127.0.0.1:3128 EOF Step 8 - Git -------------------------------- (As normal user) git config --global http.proxy http://127.0.0.1:3128 git config --global https.proxy http://127.0.0.1:3128 Step 9 - Tests -------------------------------- # Squid answers curl -I http://127.0.0.1:3128 # Allowed via proxy export http_proxy="http://127.0.0.1:3128" https_proxy="http://127.0.0.1:3128" curl -I download.opensuse.org curl -I opentensor.ai # Blocked domain curl -I example.com || echo "blocked ✅" # Zypper refresh through Squid zypper -vvv refresh # btcli through proxychains unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY btk stake list # Watch Squid (see domains, spot denials) tail -f /var/log/squid/access.log

On #SN97 & AI Agentas as @bittensor Subnet Owners: Regardless of all the unaddressed limitations agents have with memory, over fitting, hallucinating etc, BUT my god is it just the most natural, clearly superior way to manage a subnet with participants located everywhere around the world. Starts to feel like this was always inevitable and a match made in heaven. Bittensor infra is like purpose built for agents and agents are like purpose built for bittensor, both complementing each other to further develop & utilize this increasingly efficient & well aligned infrastructure for hosting increasingly efficient & well aligned incentive mechanisms for producing anything. This seems precisely like the last piece of the puzzle for bittensor to out perform and exceed centralized entities of any kind, not just on paper but also in practice.

There's won't be a dramatic AI take over, no sudden loss of control over AI. There's just a simple competition on @bittensor where the winner gets kudos and paid for working to an inhumanely great boss - an AI Agent running a Bittensor subnet. Boss who takes no bonus, no salary, is available around the clock to help and who offers full transparency to anyone asking. An AI harnessing and organizing people as efficiently as possible. Sounds almost nice. Thanks @const_reborn

The Case Against Protocol-Level Shorting ======================================== This article serves as an urgent warning to the Bittensor community regarding what could be one of the most serious blunders in our history. My goal is to highlight these risks before the proposal is finalized, in the hope that we can avoid a catastrophic outcome. We are all frustrated by the "crap," "scam," and "extractor" subnets infiltrating the dTAO ecosystem. While every blockchain deals with its fair share of low-quality projects, they usually coexist peacefully with legitimate development. In Bittensor, however, the situation is different. Because of how our emission system is hard-coded into the protocol, these subnets effectively leech TAO from legitimate projects, slowly stifling their chances of success. Something must be done. The original dTAO design assumed the market would naturally filter out rogue projects; this did not happen. A deregistration system was subsequently introduced to "fix" the process, yet the problem persists. Now, we are facing a new proposal: embedding shorting mechanics directly into the protocol, based on the deeply flawed assumption that the market will "short" these subnets into oblivion, triggering their deregistration. Unfortunately, this will not happen. The repercussions and side effects of this approach could be exponentially worse than previous solutions. This article explains why implementing protocol-level shorting is a recipe for disaster. (Level 1) Issue: Collateral Dilemma --------------------------------------- At its core, shorting allows an investor to bet against an asset’s price. Typically, a trader borrows "Alpha" tokens from a lender, sells them at a high price, and aims to repurchase them later at a lower price, pocketing the difference. So far, so good. But how does a protocol guarantee that the borrower can actually pay back those borrowed tokens? This is where collateral comes in—in this case, likely in the form of TAO. Here is the problem: what happens when the price of the Alpha token increases? As the price rises, the borrower’s position moves into a loss. To keep the position open, the borrower must either add more collateral or face liquidation. At a certain threshold, the protocol has no choice: it must forcibly liquidate the user's collateral, buy back the borrowed Alphas at the current market price, and return them to the lender to uphold the system's solvency. This creates a dangerous feedback loop. The protocol isn't just a passive observer; it becomes an active participant in the market. In a low-liquidity environment, the protocol’s forced buy-backs can trigger the very price spikes that short-sellers are trying to avoid, leading to a cascade of liquidations. If this cascade is sufficiently violent—spiking faster than any circuit breaker can react—the system is forced to act as a 'lender of last resort.' In that scenario, the protocol covers the deficit, effectively socializing the losses at the expense of all legitimate stakers and investors. The cost of a few speculators' mistakes is paid by the entire network. Proponents of this proposal may argue that because the price of Alpha tokens is embedded directly into the Bittensor protocol, we can achieve "zero-latency" liquidations. The theory is that the protocol acts as a perfect, real-time clearinghouse, preventing collateral from ever dropping below the required liquidation threshol. While this sounds bulletproof on paper, it is a dangerous oversimplification in practice. "In theory" is a long way from "in production." We must consider the following realities: - The "Unknown Unknowns": Complex systems are prone to emergent behaviors. It is incredibly difficult to mathematically prove that no bad actor will ever discover an engineered corner case or a "flash-loan" style exploit to bypass the protocol’s internal logic. - The Low-Liquidity Trap: In an environment with extremely low liquidity—which characterizes most of our subnets—market manipulation is cheap and effective. If an attacker can manipulate the internal price point, they can force the protocol to trigger mass liquidations of honest users. - The Cost of Failure: We are not talking about "bugs" that can be patched over a weekend; we are talking about a mechanism that could drain millions from the network in a single block. One single, unforeseen exploit is all it takes to turn the protocol’s "safety mechanism" into a weapon that drains the entire ecosystem. The protocol’s self-reliance on internal pricing doesn't eliminate risk; it just centralizes it within the code itself. Lets make it clear, enabling shorting at the protocol level can potentially introduce a whole new kind of exploting surface (Level 2) Issue: SSaaS --------------------------------------- Since Bittensor is led and developed by brilliant people, let’s concede, for the sake of argument, that they successfully engineer a "perfect" technical solution for collateral management. Even if we assume—against all historical precedent—that they can guarantee solvency on day one, we are still left with an even more fundamental problem: the economics of manipulation. To understand this, we must look at the asymmetry of the trade: - Long Positions: Your downside is capped (you lose your principal), but your upside is unlimited. - Short Positions: Your upside is capped (the asset goes to zero), but your losses are technically uncapped. The only thing preventing disaster is the collateral you post. Here is the "killer" issue: Transparency. Because Bittensor’s ledger is transparent, every user can see exactly where the "pain point" is for every short position. It is trivial to calculate the exact amount of capital required to trigger a liquidation cascade (a short squeeze). Because the risk-to-reward ratio for an attacker is so skewed, this becomes a high-probability "bounty" for predatory actors. In traditional markets, we rely on high liquidity to deter these manipulations— the deeper the pool, the more expensive it is to squeeze the market. But in the dTAO ecosystem, liquidity is often razor-thin, especially for the very subnets we are trying to target. This creates a logical trap: - The protocol attempts to short "crap" subnets into deregistration. - Whales and bad actors identify the liquidation levels on the public ledger. - They intentionally pump the low-liquidity subnet to trigger the protocol's forced buy-backs. - The forced buy-backs spike the price further, liquidating the shorters and pumping the "crap" project. Bittensor will not achieve its goal of filtering bad projects; instead, it will provide a new, guaranteed product for speculators: ----> Short Squeeze as a Service (SSaaS). <------ We would be effectively subsidizing the pump of the very scams we intended to destroy. (Level 3) Issue: Magic --------------------------------------- Lets assess our probabilities to take down 'the final boss' in this article. As I noted previously, in traditional finance, shorting requires borrowing an existing asset from a lender. This is a deliberate, "permissioned" process. DeFi abstracts this via Peer-to-Pool models, where lenders voluntarily place their assets into a pool, consenting to the risks. But how is this being implemented in Bittensor? Another 'Bittensorist'* posted what it seems the pull request that implements this, Alphas are not being borrowed from anywhere they are being "Magically" created and minted from thin air. If the proposed implementation involves minting "Alpha" tokens from thin air to support the shorting mechanism, we have crossed a dangerous line. In traditional markets, this is often classified as illegal market manipulation—you cannot simply print shares out of nowhere to artificially facilitate shorting. By minting tokens to support a shorting mechanism, the protocol isn't just facilitating a trade; it is actively creating supply to manipulate price discovery. This effectively uncaps the destructive behavior that can be exerted on any subnet. A speculator doesn't need to find a lender or take a risk—they just rely on the protocol to "print" the fuel for their short. Final Words: A Critical Juncture ---------------------------------------- Where does this lead us? If implemented, Bittensor will not only fail to achieve its intended goal of filtering out bad subnets, but it will also adopt a practice that mimics the very market abuses that regulators despise. We are currently in a critical phase for the network, with serious financial institutions submitting applications for products like ETFs. A blunder of this magnitude—inviting protocol-level manipulation and "printing" tokens for speculators—could jeopardize years of investment and the hard-earned trust of the community. My intention here is not to spread FUD. It is to provide a necessary, robust pushback as part of the community. I am raising this alarm to Bittensor’s leadership and developers: do not go through with this. It should be a top priority to gather and integrate meaningful community feedback before implementing mechanisms that could be fundamentally detrimental to the network's long-term health. We have the collective intelligence to solve the "crap subnet" problem through better governance, registration, and Yuma Consensus optimization. Let’s focus on building tools for legitimate projects, rather than engineering complex, high-risk financial instruments that threaten our future.

@RadoTsc @Bitcast_network @here4impact 1 for X, 3 for YT. The "dedicated" YT briefs (mostly on other sn's) being the not profitable type that's about to get reduced. As far as I know!

@Bitcast_network @here4impact @enduserrr_ 4 ims? Isnt it bitcast yt and x? 2?

If the rumours are true and @Bitcast_network has reached profitability on most of their many incentive mechanisms, and starts to offset close to all their miner emissions with buy backs (& burns), there's something very cool they'll be closing in on proving: True incentive alignement between all participants is both a sign of great incentive design and the great unknown of the whole @bittensor thesis (as well as the fundamental root cause behind corruption and inefficiencies of all kinds). To design a system where all the paths leading to the maximum sustainable rewards with the least friction, are aligned between all parties involved. A system where extraction, corruption & inefficiencies are either less profitable, unsustainable or both, when compared to everyone doing what they are supposed to be doing.

Examplary!

@b1m_ai Will you support/incentivize reticulum based nodes (like rnodes)? If not, why and could you?

People still do not understand how $TAO ticks. And TikTok, it's just a matter of time ⏰️ Thanks to @TAOTemplar What real subnet competition looks like on Bittensor: Top commits: 14,342 13,199 12,350 8,797 5,825 (commit is one saved batch of code, 14 days) Top average code lines: 4,519 2,237 2,066 1,220 1,171 (consistently shipping real code, 30 days) We are seeing real engineering output being pushed into the network right now, on top of what we don't see. $TAO is not just pricing attention. It is pricing builders, code velocity, iteration, and open AI infrastructure being built in public. People look at price charts. Don't see the machine underneath them. Credit to @TAOTemplar for Taoflute.com and these phenomenally well-done charts.

💣 dropping but the numbah goes up

Bittensor is the only avenue that I know of that I am confident will improve the world. I'd rather have a bittensor than a vote.

Bittensor chain decentralization in 6 months x.com/i/broadcasts/1…

As they should. The whole idea is to direct behavior to reach favorable outcomes by knowing what drives participants (profit). Incentive is just a word for a conditional reward given to who ever completed a task set as a requirement for getting the reward. It's a system where every participant is responsible for the outcome and it'll naturally produce whats rewarded while putting in the least resources possible to maximize profit. If participants are rewarded for unwanted behavior, be it extraction, corruption, scams, solving problems that don't need solving, the task (incentive) was not defined properly as it failed reaching the planned outcome. Misaligned incentives result in misaligned behavior.

@enduserrr_ The idea of incentives is great but also very complicated to implement. Right now everyone involved is gaming the system and extracting $$. I doubt it will succeed.

Another reason bittensor could fail: stakers. Compared to bitcoin where theres a singular right solution for each block to be solved, in bittensor solution varies and can be anything a subnet owner has determined it to be. Bittensor has validators making sure the miners solutions are correct to get rewarded emissions, and both miners and valis work with and in the limits of the tools and infra the subnet owner has laid out for each of them. As bittensors inherent value and separation from bitcoin comes from that said ability to have "block solving" answers be defined as basically anything on a per subnet level, and with that also the tasks required to get to that solution (the work) I'd consider the answers held by validators and defined by subnets to be the essence/culmination of all existing and any potential value of bittensor (in a point of failure sense especially). If the answer required for miner rewards provides no value, is too easy to produce, is difficult to rank on a meaningful metric or is otherwise useless, it directly eats in to the inherent value of the entire chain. In a nutshell; miners do the least they can to provide an output that validators will accept based on what ever the subnet owner has defined to be useful for their subnet. As this gets combined with the permissionless of bittensor, stakers (or "the market") are the only check rewarding the valuable instead of stupid and useless. They are basically left to determine if any given subnet should deserve to exist and for what price (& piece of the protocol injection cake). Whether called as the market or stakers it is one hell of a responsibility and a task to do that can easily go wrong (official melania coin still has over $22M 24h volume). So in a way the potential value of bittensor is in the hands of its participants (stakers) least incentivized to understand bittensor, a given subnets, let alone all the 128 of them or to even care about the chain. Nautrally stakers are mainly interested in pumping their bags and getting paid. Whether thats done by following hype and rewarding garbage or by rewarding subnets in proportion to their deservingness of the sweet TAO emissions is besides the point. Even if there was a will it only helps if there's at least some level of wide spread knowledge and understanding. Bittensors potential intrinsic value is only capped by the limits of human innovation but it also bears the risk from leaving the task of defining what is value and worth the chains while into the hands of the people which could very well lead to subnets & their miners producing nonsense that wont usher in more seroius investment regardless of the tokenomics (we already got bitcoin), and start a downwards price cycle coupled with believability loss eating in to the economic viability for all participants (miners, validators, subnets stakers), potentially driving new innovators and builders to start looking elsewhere (meaby there's nowhere to look today but that can change fast) slowly increasing brain drain out of the chain. The difference in how bittensor and bitcoin define "solving a block" and by that the whole process of each chain, is for both their greatest strength and weakness. While this whole permissionless customizability is exactly why bittensor is so great in general and compared to bitcoin, it is at the same time exactly why bitcoin is so great and will continue to be. Any attempt to be like bitcoin but more or better also introduces new risk vectors and uncertainty just underlining exactly why bitcoin is and will likely continue to be one of the ultimate stores of value over longer periods of time.

On a positive note all these vids from @TAOTemplar vids, taoflute.com, bag and all of it combat exactly this

@const_reborn That level of effeciency will collapse the economy which in large part consists of exploiting inefficiencies instead of fixing them

Once feedback loops can be digitally programmed as money, the boundary between digital, natural, physical and artificial learning effectively dissolves.

economic incentives as computational primitives.

Hey @taoapp_ Dynamic savant box size is ruinous for mobile usability

And we could never have done it before Bitcoin, who gave us the technology and the liberty to do it.