lightclient pfp

lightclient

@lightclient

11 Following
471 Followers


lightclient pfp
lightclient
@lightclient
The Ethereum Foundation is seeking highly talented and motivated p2p engineers to lead work that will impact the future of Ethereum! Please see this posting for more info and feel free to DM with any questions. https://jobs.lever.co/ethereumfoundation/aa63583e-49a3-45b1-8a80-4b8eca2fc562
0 reply
3 recasts
15 reactions

0age pfp
0age
@0age
Nothing beats when the EVM enters a new “weird era” First: introduction of DELEGATECALL to replace CALLCODE Then: CREATE2 (this was a huge game-changer & really kicked off my personal journey in understanding yhe EVM) Now: AUTH & AUTHCALL — so much to be (re)built and reconsidered And just wait until EOF 🤯
3 replies
1 recast
27 reactions

lightclient pfp
lightclient
@lightclient
Have you concocted the most insane way AUTH/AUTHCALL could be used yet? I recall HomeWork!
1 reply
0 recast
1 reaction

lightclient pfp
lightclient
@lightclient
Okay @daws officially farcaster pilled me.
2 replies
0 recast
4 reactions

lightclient pfp
lightclient
@lightclient
hello 😇
0 reply
0 recast
1 reaction

lightclient pfp
lightclient
@lightclient
An invoker should only require one 3074 AUTH msg to initiate the delegation, then with a different key you can make more regular signatures over tx batches and the like.
0 reply
0 recast
0 reaction

lightclient pfp
lightclient
@lightclient
I made my first cast! Hello world!
3 replies
1 recast
9 reactions

lightclient pfp
lightclient
@lightclient
🤝
0 reply
0 recast
0 reaction

lightclient pfp
lightclient
@lightclient
Our DMs are open! Please reach out if we can help.
2 replies
0 recast
4 reactions

lightclient pfp
lightclient
@lightclient
Over the last several years, we've spent a lot of time developing hypothetical scenarios on how it might be used and abuse. We're excited for these ideas to begin being productionized. But we're also cognizant that this is the hard part.
1 reply
0 recast
4 reactions

lightclient pfp
lightclient
@lightclient
It is possible to integrate and use 3074 safely. If any wallets have questions on how they can do this, please don't hesitate to reach out. As authors of 3074, we're currently figuring how we can best help this standard in its next phase of life.
1 reply
1 recast
5 reactions

lightclient pfp
lightclient
@lightclient
Yes, 3074 is putting a lot of trust into wallets. But look, we are already trusting them with securely our private key! There isn't a higher level of trust.
1 reply
0 recast
6 reactions

lightclient pfp
lightclient
@lightclient
Wallets must clearly display each op you're signing over. This way, it is easy to notice "I was only planning to make a single trade, but this signing request is having me do a dozen transfers also". It will be impossible to detect this if batching available via blind signing.
1 reply
0 recast
3 reactions

lightclient pfp
lightclient
@lightclient
Assuming a wallet securely integrates 3074, it is still possible for an account to be swept. This is a fundamental property of batch txs. It as easily allows you to send multiple ops as it allows an attacker to trick you to send a batch of assets to an address they control.
1 reply
1 recast
3 reactions

lightclient pfp
lightclient
@lightclient
At minimum, wallets should make signing a 3074 message a big deal. This is like exporting-your-private-key level of big deal.
2 replies
0 recast
6 reactions

lightclient pfp
lightclient
@lightclient
So if wallets insecurely integrate 3074 *and* users do not verify the invoker they're interacting with, it is possible to delegate to a malicious invoker. However, it is possible to undo by sending a single tx from the EOA. This revokes all "in-flight" AUTH signatures.
1 reply
0 recast
5 reactions

lightclient pfp
lightclient
@lightclient
For 1) we hope wallets understand that 3074 invokers are more akin to extensions of their code than they are contracts. Wallets don't give users the freedom to run arbitrary code with access to their pk; similarly, they shouldn't allow users to delegate their account arbitrarily.
1 reply
0 recast
4 reactions

lightclient pfp
lightclient
@lightclient
For an account to be drained 1) the wallet will need to allow users to sign to any invoker address and 2) the users must not verify the invoker is trustworthy. Do either of those and there is not an issue.
1 reply
0 recast
3 reactions

lightclient pfp
lightclient
@lightclient
The auth msg which the signature is constructed over have the below fields. Importantly, it includes an invoker address. This is the only address under which the signature will be considered valid by AUTH.
1 reply
0 recast
4 reactions

lightclient pfp
lightclient
@lightclient
Depending on how wallets integrate 3074, they could create a situation where their users can more easily be exploited. To understand this, we need to make sure we understand how 3074 signatures work.
1 reply
0 recast
4 reactions