pcaversaccio

ok I need some feedback: I've been looking into Dandelion++ lately and I'm getting more and more convinced that we should ship this mid-term for Ethereum. What would be potential bottlenecks and challenges or if there is even an improvement over Dandelion++ anyone has thought about?

so I've been thinking about this for a while now and I'm more and more convinced that crypto was never meant for mainstream. The main reason being that crypto's purpose is _liberation_, not popularity. It's effectively for those who choose sovereignty over simplicity. If it never goes mainstream, that means it stayed dangerous. It stayed free. Thus, mainstream isn't the goal. Freedom is.

so over the weekend I decided to try using my `CreateX` factory instead of the usual `SafeProxyFactory` to deploy my next Safe multisig. It took a bit of digging to understand all the implications, so I put together a step-by-step guide for deploying a 1-out-of-1 Safe multisig (version `1.4.1`) using `CreateX`. The cool thing is if you go with this approach, you get at least two nice benefits:
- Since for this approach you _must_ (this is super important!) configure a frontrunning protection as part of the salt in `CreateX`, no one can frontrun your deployments on any chain. Your deployment stays fully in your control, as long as the deployer address is trusted.
- You can generate a vanity address for your Safe multisig using the `createXcrunch` tool (props to @HrikBho for building it).

The recommended way to deploy a Safe is still through the `SafeProxyFactory` contract. But if you're up for something a bit more fancy, `CreateX` with the `deployCreate2AndInit` function and deployed on 160+ chains is a neat alternative.

you know, I'm a simple guy: I roll (mostly) with ETH, Tornado Cash, Railgun, BTC, Zcash, and XMR these days. I don't use L2s. I don't use Solana. I don't use fancy DeFi protocols (I like it KISS and trustless). Simply put: just tools that work and don't ask permission. It could've been simple but somewhere along the way, we chose to build a fragmented, bloated mess of chains instead. A monster of our own making.

One of the beauty of using EIP-7702 is that you can rescue all funds from a compromised wallet using a paymaster and a friendly delegator. There is _no need_ to send ETH to the compromised wallet at all! I decided this morning to write and open-source a fully-fledged Bash script that empowers anyone to run such rescues themselves. The flow of the script is basically:
- A paymaster account that covers gas fees and broadcasts all transactions (including the deployment of the friendly delegator).
- A victim account that signs the EIP-7702 authorisations.
- A friendly Vyper-based delegator contract `recoverooor` deployed for each rescue and protected by a trusted `OWNER` account (defaults to the paymaster account).
- A single script, `go_eip7702.sh`, that can batch recover all assets (you have a multicall possibility for any complex interactions needed, e.g. unstake and transfer).

I haven't fully tested everything so use with caution and use your brain as always please.

There is nothing I want more than for Ethereum to lead on privacy (scalability has always been a second priority for me tbh; not implying it's not important to be clear). Not conditional privacy. Unconditional. Long-term, I shouldn't need to interact with a smart contract just to shield a simple ETH transfer. Privacy should be native at the L1. Look, I've been using Monero & Zcash for some time already (on that note, please Ledger ship shielded addresses). I use them because their privacy is built-in & the UX is pretty smooth. That's exactly what I want from Ethereum. Simple, private, native payments. No extra steps. If we want to onboard people to privacy at a global scale, it must be native and easy. Full stop.

Seeing the first malicious EIP-7702 delegators being added to private key leaked victim addresses that revert on ETH transfers to prevent an "easy" rescue of locked funds. They first drain all the ETH and then authorise such a malicious delegator contract with a permissioned drain function. To rescue any remaining (locked) funds you need to selfdestruct send into the EOA first now.

for anyone who needs this, I created a simple TS-based script to _raw_ sign EIP-7702 transactions and broadcast them accordingly: https://t.co/RbyUaE53Mm

might come handy if you e.g. use airgapped computers to generate such transactions. The default configuration currently calls the `eip712Domain` of the MM EIP-7702 Delegator at `0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B`

Pectra upgrade is live 🥳; you can now start testing EIP-2935 on mainnet (block hashes 8,191 blocks back) via `0x0e04bDF212088405D1EF8abE507F644a87c17a84`

Most crypto work (partially mine included) runs on some sort of 'hope Microsoft keeps GitHub online' mode. Git is decentralised but GitHub isn't. Shutting down key repos is one of the easiest ways to censor or disrupt upgrades and dev coordination. And yes, Microsoft can do that. There are legit alternatives but none with full feature parity. It's already way too late, but we as an industry must really rethink how we write, collaborate, deploy, and ship code.