Two parties, Alice (who has BTC) and Bob (who has LTC), wish to swap coins trust-lessly via HTLCs on each chain. Parameters Secret preimage x such that H = RIPEMD160(SHA256(x)) Timeouts: Chain A (BTC) locktime T₁ (e.g. block 700_000)

Introduction Shir Ya Khat podcast, which translates to "Head or Tails" in Farsi, started its non-profit mission in early 2016. The Vision of Shir Ya Khat is open and free information for all, similar to Coiniran. The main goal is to remove the language barrier in order to allow the knowledge on blockchain and decentralization to be accessible to Farsi speakers, and offer a global open platform for people to discuss related subjects. History of ShirYaKhat The journey of ShirYaKhat, a trailblazing podcast in the realm of blockchain and cryptocurrency, began its remarkable journey around 2013 and 2014. During this period of growing fascination with blockchain technology, Shayan Eskandari embarked on a mission to connect with individuals actively engaging in Persian-language discussions about these groundbreaking topics across various online platforms. This initiative gave birth to 'Coiniran', a collaborative effort formed with participants from these online gatherings. In the initial phase, these sessions, originating as casual online discussions, evolved into more organized and structured meetings. In 2016, the group made a pivotal decision to record their insightful conversations and share them with a broader audience, leading to the inception of the 'Shir Ya Khat' podcast. This step was significant, as it not only formalized their discourse but also amplified their reach, engaging a wider community intrigued by the ever-evolving world of blockchain and cryptocurrency.

Below is a refined technical document that clarifies the role of the temporary key and how the emergency/disaster UTXO is effectively unspendable except via the pre-signed “recovery transaction.” In particular, this version emphasizes that there is no extra script-based lock on the disaster UTXO; rather, it is simply sent to the temporary key Key_T, and the only valid signature to spend it is the one created (and then partially shared) by the custodian before Key_T was destroyed. OverviewTemporary Key (Key_T): • A fresh key pair generated by the custodian during setup. • Used only to create partial signatures for the recovery transaction and the “disaster signal UTXO.” • Destroyed immediately after, preventing both the user and the custodian from using it for any other purpose. User’s Final Taproot: • The user’s funds reside in a Taproot output with two internal paths: Normal Path:  for daily spending. Recovery Path:  activated only after the “disaster signal.”

🌟 EPF-5 | Week 12 -> Pivot 🌟 Hello internet Over the past 3-4 weeks, I have been deeply engaged in testing and prototyping my project idea, Inclusion List with Plausible Deniability. Through several iterations, I explored the feasibility of this idea and worked to identify potential challenges and solutions. However, as I delved deeper into the implementation, it became clear that the concept faced significant hurdles that would prevent its adoption on the Ethereum mainnet. These challenges included network overhead and other limitations, which I will discuss in more detail in the following sections. In the conclusion of this document, I will also outline what’s next for me as I continue my journey in the Ethereum Protocol Fellowship. Challenges Encountered While working on the Inclusion List with Plausible Deniability project, I encountered several challenges that ultimately led to the decision to pivot. These challenges include: Let's go through each section and refine your reasoning in more technical language.

🌟 EPF-5 | Week 6 🌟 Sections • 📅 Update • 📆 Next Week Plan • 📚 Resources Update 📅 Finlized project proposal and prepared for presentation Started Implementation of consesus test vecotr Next Week Plan 📆

🌟 EPF-5 | Week 5 🌟 Sections • 📅 Update • 📆 Next Week Plan • 📚 Resources Update 📅 This week, I focused on completing the project proposal and specification for the Anonymous Inclusion List with one-bit attestation. Next Week Plan 📆 Start Implementation Phase:Onboard myself to the ethereum-consensus spec repo to enable coding of my specification.

🌟 EPF-5 | Week 4 🌟 Sections • 📅 Update • 📆 Next Week Plan Update 📅 This week, I focused on onboarding into the Lighthouse and Engine API codebases, essential for implementing the one-bit attester idea for the Inclusion List. I explored key modules and began drafting the functional specification based on my findings. Next Week Plan 📆 work on presentation and project proposal and project spec

🌟 EPF-5 | Week 3 🌟 Sections • 📅 Update • 📆 Next Week Plan Update 📅 This week, I focused primarily on onboarding myself to the consensus layer P2P network and the Lighthouse implementation of this network. This step is crucial for the implementation of the one-bit attester idea for the Inclusion List, as I need to send data over this P2P network. Additionally, I worked on familiarizing myself with the Engine API. Understanding this API is essential because I need to add another API for the Inclusion List and update the fork choice logic based on the Inclusion List validation. Next Week Plan 📆

Sections • 📅 Update • 📆 Next Week Plan • 📚 Resources Update 📅 This week, I delved deeper into the One-bit-per-attester idea and introduced myself to erasure codes, specifically Reed-Solomon encoding. I explored more data on Inclusion Lists and examined different design spaces. I also began formulating my own specification that combines the One-bit-per-attester and FOCIL ideas, preparing for the Rust implementation using Reth and Lighthouse. Additionally, I explored the Lighthouse node to familiarize myself with its structure and functionality in depth.

Sections • 📅 Update • ⚠️ Inclusion List Challenges • 📝 Vitalik’s EthResearch Post on Inclusion List • 📃 Project Proposal: Initial idea • 📆 Next Week Plan • 📚 Resources Update 📅 As I mentioned in my previous update, privacy and censorship resistance are my areas of interest. At the beginning of the week, I started exploring the ecosystem to find related ideas and projects that align with my interests for the program.

👋 Introduction Hello everyone, my name is Hamid. I am the co-author of EIP-7503, which proposes native privacy for EVM-based chains, and the author of the Private Proof of Solvency paper. Currently, I work as a software engineer at txFusion, focusing on the zkSync Era node implementation. For the past six months, I have been deeply exploring core Ethereum details to prepare myself for contributing to the Ethereum ecosystem. I am passionate about becoming a core developer. Having participated in the EPF study group, I am now excited to officially start my journey in the EPF program and contribute to the Ethereum community. 📝 Week 0 Update During this week, I have primarily been exploring different ideas and open problems. I have a keen interest in working on privacy and censorship resistance-related ideas. Additionally, I find the Reth codebase fascinating and plan to use it or contribute to it during the program.

EPF Application Essay Section Initially, I planned to write about the EOF (Ethereum Object Format), an approach that introduces versioning to contract bytecode and allows nodes to execute transactions of these contracts in the future based on the released EVM version. This mechanism enables us to implement breaking changes in the EVM without worrying about previously deployed contracts. However, after watching the Town Hall of the previous cohort (https://www.youtube.com/watch?v=ovwXAgP9LS8), where it was mentioned that we can use our previous blog posts or write-ups for this section, I decided to share one of my previous posts from four months ago about the Periphery Contract. Essay on Periphery Contract Link to the essay: https://hackmd.io/@irnb/uniswap-periphery Additional Activities In Ethereum Related Research Forum Diagram for Using STARK in Quantum Emergency:

How SmartContract ByteCode published on Data Availability layer in Ethereum Rollups Introduction In the ever-evolving landscape of Ethereum's blockchain, scalability remains a paramount challenge, prompting the development of sophisticated solutions known as rollups. These innovative mechanisms enhance Ethereum's capacity by batching numerous transactions off-chain and subsequently validating their integrity on Layer 1. This article presupposes that readers possess a high-level understanding of rollups and their operational dynamics, focusing on their pivotal role as a scaling solution. At the heart of rollup technology lie two fundamental challenges: validating the authenticity of data published (new L2 state) determining the optimal location for this data's publication.

Zk-hack zk tooling Lisp DSL O2js Risc zero the stark to snark trnslator Plonkish Ola zkevm, private application Risc zero bonsai zk virtual machine verifier

Subscription Friendly Fungible Token Problem The existing standard for fungible tokens, known as ERC20, includes a function called transferFrom. The purpose of this function is to delegate control over a certain amount of a user's token balance to another smart contract. This allows a specific quantity of tokens to be transferred from the user's address to the contract's address, and so on. This concept has its roots in the traditional banking system and the credit card model. For instance, when you subscribe to a service like Spotify, you grant Spotify the right to withdraw a specific amount of money from your bank account each month. The transferFrom function aims to replicate this concept. Let's say Spotify accepts an ERC20 token (e.g., DAI) as a payment method, and you can subscribe to Spotify using this token. As we've already noted, the ERC20 transferFrom function provides the infrastructure needed for this subscription model. Therefore, a Spotify user can use the approve function to grant allowance to the Spotify access manager contract, which can then use this allowance to charge users each month. At first glance, everything seems fine, right? However, there are a few problems.

Opening Session (15 Jan 2024) 3-4 month long tim fellowship slide prover - veryfier architecture and scheme is it important to know wich component belong to wich place is it important to know wich math belpng to where

:mag_right: Overview I've reviewed the UniswapX Whitepaper and various diagrams related to its architecture: Diagram 1 <img width="2231" alt="UniswapX Architecture" src="https://github.com/irnb/board/assets/41897852/39f45fbf-be99-4627-a4ea-6d79f3a01237"> UniswapX System Overview :memo: Notes Permits2 :star2: The Permits2 concept appears to be a highly innovative approach. It allows a user to give one-time approval for a token, after which this contract facilitates the use of this approval in other contracts through signed messages. This concept has potential applications in various DeFi protocols.

Assumption: The reader is already familiar with Automated Market Makers (AMM) and ERC20 tokens. Githublink: [https://github.com/irnb/board/blob/main/content/review/uniswap-periphery.md] 🧩 Problem Statement Let's consider a scenario with three AMM pools in our hypothetical DEX: WETH-DAI WETH-TokenX TokenX-TokenY

Exploring 'Make Ethereum Cypherpunk Again' 🔍 Exploring 'Make Ethereum Cypherpunk Again': Comprehensive Analysis and Personal Reflections Main Article Link: [https://vitalik.eth.limo/general/2023/12/28/cypherpunk.html] 🖊️ Author: Vitalik Buterin github link :[https://github.com/irnb/board/blob/main/content/review/MakeEthereumCypherpunkAgain.md] table of contents

Nobicoin Virtual Machine vm.py We write our codes for this section in this file. class VM: def __init__(self, storage, transaction): self.storage = storage self.tx = transaction