sudo rm -rf --no-preserve-root / pfp

sudo rm -rf --no-preserve-root /

@pcaversaccio

156 Following
2989 Followers
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
No. I'm part of the extended Vyper compiler team.
0 reply
0 recast
4 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
EOF: When Complexity Outweighs Necessity https://hackmd.io/@pcaversaccio/eof-when-complexity-outweighs-necessity A lot of time and energy went into this new deep dive on EOF. We break down its supposed benefits and argue they're more "nice-to-haves" than essential upgrades. Instead of adding complexity, we highlight cleaner, less disruptive solutions that achieve the same goals. EOF's objectives are solid—but there's a smarter way to get there. I would like to highlight that the authors and contributors of this post represent the full EVM stack—from VM and formal specification maintainers to compiler engineers, application developers, and library creators. Please reflect on this guys. If you got feedback, let us know here: https://ethereum-magicians.org/t/ethereum-is-turning-into-a-labyrinth-of-unnecessary-complexity-with-eof-lets-reconsider-eof/23136 https://x.com/pcaversaccio/status/1900200732000759892
2 replies
14 recasts
65 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Not sure what you're showing here but that's not coffee. No coffee needs milk. No coffee needs this size of a cup.
1 reply
0 recast
1 reaction
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Happy π day!
0 reply
0 recast
11 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Look guys, the Pectra fork upgrade issues on Holesky and Sepolia are a stark reminder that even seemingly 'trivial' changes can unravel into major disruptions (check how many days Holesky was down). Complexity isn't always obvious—it lurks beneath the surface, waiting to break things (and it will happen ultimately). And while not the root cause here, adding 19 opcodes while removing 16 in one upgrade is simply reckless, IMHO. The PoS transition was a necessity—EOF is not! We can and should evolve _incrementally_, strengthening Ethereum without inviting chaos.
3 replies
8 recasts
55 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
The latest Vyper version `0.4.1` got released over the weekend and to make anyone's life easy, I just published a 🐍 snekmate release candidate `0.1.1rc1` targeting the latest Vyper version. Simply install via: ``` pip install snekmate==0.1.1rc1 ``` For the full CHANGELOG of the yet-to-be published snekmate `0.1.1` version (expect it in around 2-3 weeks), see here: https://github.com/pcaversaccio/snekmate/blob/main/CHANGELOG.md. Btw, that's how an `erc4626` contract looks like using 🐍 snekmate modules :D https://x.com/vyperlang/status/1896511448492433917
0 reply
1 recast
7 reactions
hww.eth pfp
hww.eth
@hww
I’m honored and thrilled to serve as co-Executive Director of the @ethereumfndn alongside @tkstanczak. Everyone has their perspective on the Ethereum Foundation. Just as Ethereum continues to evolve, so does the EF—but the core values we have upheld for years remain unchanged. A better world is possible when we stand by these values and the people who share them. 🫡
22 replies
51 recasts
279 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
People keep asking me since days how to secure their systems and what the best strategy is. I will be very honest with you all as I'm always. If you want real security (and there will be never 100% security), it's not (just) about tools—it's about fucking mindset. At least 80% of it is pure paranoia. You and your team (can be a small DeFi project, can be a large CEX, ...) need to be paranoid as fuck. Drill it into them. Make it second nature. That's how you cut down risk, big time. The human factor is always the weakest link—no tech can _fully_ fix human fuck-ups. Sure, we'll kill blind signing, we'll upgrade our tools, but people will always be the problem. The only way to fix that? Train them to be fucking paranoid. There are no fucking shortcuts. If you have 900 employees, it's the leader's job to make sure all 900 are paranoid as fuck. You'll say that doesn't scale? Maybe not—but if u don't do it, you're effectively gambling with everything. And when shit goes wrong, the price u pay will be brutal.
2 replies
0 recast
11 reactions
franco pfp
franco
@francos.eth
Check this out if you use Safe. New tool to verify txs before signing by @pcaversaccio @openzeppelin developed a UI for it https://x.com/openzeppelin/status/1894870509608935791?s=46
0 reply
1 recast
6 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Look, it's actually pretty simple: UIs, infra, dependencies etc. can and will be corrupted. When you hit the buttons on the hardware device, that's when you need to be 100% sure what you sign. The MOST important part is the screen on your hardware device and what it displays and that you 100% understand what it implies. If you're not 100% sure, don't hit the buttons. NEVER. People need to become paranoid. They need to understand that you're one signature away from being rekt. It's IMHO 80% at least mindset. That's the price of self-sovereignty and asymmetric cryptography. How to make verification easier is another question, or what kind of guardrails should be built. Nr. 1 priority is that you ALWAYS understand WHAT you sign.
3 replies
11 recasts
81 reactions
Lefteris Karapetsas pfp
Lefteris Karapetsas
@lefteris.eth
This is the biggest blind signing compromise of a multisig to date Bybit lost ~$1.5bn by signing a compromised tx on their safe (more details to be determined) But FOR GOD'S SAKE if you deal with such amounts use verification tools such as the one by @pcaversaccio https://github.com/pcaversaccio/safe-tx-hashes-util
3 replies
3 recasts
26 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
EOF introduces excessive complexity all at once, and the benefits—mainly aiding static analysers—don't justify it, sorry. Dude, I was reading `TXCREATE` this morning again since I wanted to provide feedback on the PR: https://eips.ethereum.org/EIPS/eip-7873#execution-semantics - we do NOT need this complexity in one go. Period.
0 reply
14 recasts
34 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
This is so fucking cool - https://godbolt.org finally supports Vyper code! A s/o to Statemind for shipping the support here: https://github.com/compiler-explorer/compiler-explorer/pull/7088. Now you can visually debug Vyper-generated bytecode. anon, don't be afraid to touch the snake, you will enjoy it :)
1 reply
0 recast
18 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
people start caring about privacy usually when it's already too late. I'm not sure what really can change this. It's like a child burning the fingers - after burning them one, two times you understand it :)
0 reply
0 recast
1 reaction
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
No, I'm saying that solving eg wallet UX issues won't solve onchain scamming itself. It's about the right use cases that truly matter for the entire world population. I'm biased due to my Cypherpunk ethos, but I would like to see simple shielded transactions (native and tokens) and the rest of the world caring about their privacy. Financial privacy should matter for each adult, globally speaking, thus that's what I want and wish to see as killer application.
1 reply
0 recast
1 reaction
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
UX won't solve the incentives.
1 reply
0 recast
0 reaction
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Ethereum is this fucking phenomenal economic playground—the biggest we'll witness in our lifetime. It's a wild frontier, open to boundless experimentation, but that also means it's a hunting ground for criminals. The real issue isn't just scams or crime (and yeah, I'm not downplaying them to be clear); it's that, after a decade, we've utterly failed to deliver killer applications that the average person actually gives a shit about (if you reply with stablecoins I will report your tweet as spam lol). Crime thrives—and screams—because it's one of the only undeniable use cases (so far). The tech itself isn't broken; WE are fucking up its application. The systems we build can't float in some idealistic vacuum—they need to be rooted in social consensus and real-world utility. And so far, we've spectacularly failed to drive mass adoption of anything that truly moves the needle for everyday people.
4 replies
2 recasts
14 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Starting the case here for "hedged signatures". If anyone has a specific view / opinion, let me know in the thread: https://ethresear.ch/t/hedged-signatures-ftw/21757
1 reply
5 recasts
27 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
If you get scammed by presidential meme tokens, that's on you at first. It's your fucking degeneracy that makes you trade real money for pure stupidity. We're all grown-ass adults who can think, right? It's your fucking responsibility to use your brain, or are you just puppets dancing to the next social media post? Let me be very clear here: If you lose money trading meme tokens, you fucking deserve it.
1 reply
4 recasts
19 reactions
sudo rm -rf --no-preserve-root / pfp
sudo rm -rf --no-preserve-root /
@pcaversaccio
Before anyone panics, if wallets strictly follow RFC 6979 (nonces are derived deterministically from the hashed message), their input-to-bytes conversion is not erroneous, and doesn't allow custom nonce injection, everything should be safe. https://github.com/advisories/GHSA-vjh7-7g9h-fjfh I'm all for experimenting with hedged signatures, just like Paul suggests. Thankfully, this time, the vulnerability isn't completely devastating, but who knows what might happen next time. Let's give hedged signatures a try and see how it goes. One thing I personally like a lot is that hedged signatures don't have a single point of failure (eg. the nonce k) but require someone to break randomness _and_ the generation process. https://warpcast.com/paulm/0x2b0097b6
0 reply
2 recasts
16 reactions