jxom pfp

jxom

@jxom

43 Following
15155 Followers
jxom pfp
jxom
@jxom
Viem doesn’t default to it right now though. Maybe we should if there are obvious benefits.
0 reply
0 recast
1 reaction
jxom pfp
jxom
@jxom
Is there really a performance benefit as everyone is on HTTP/2 now?
2 replies
0 recast
1 reaction
jxom pfp
jxom
@jxom
Simple answer: update vocs to latest
0 reply
0 recast
1 reaction
jxom pfp
jxom
@jxom
Feel free to open a PR adding it!
0 reply
0 recast
2 reactions
jxom pfp
jxom
@jxom
🫡
0 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
wow you got me
0 reply
0 recast
1 reaction
jxom pfp
jxom
@jxom
Your cast is trending!
1 reply
1 recast
5 reactions
jxom pfp
jxom
@jxom
jxom casted for the first time in a while
16 replies
8 recasts
121 reactions
jxom pfp
jxom
@jxom
check out https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7851.md
0 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
thought we were talking about the case where we are not persisting the private key ("forgetting"). nevermind.
1 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
so for this case, you want to rotate for the case where it may take a billion years to crack the private key?
1 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
sure we can easily upgrade signers on SCA to be PQ-safe, but this wouldn't suffice because everything else would be screwed, so we need a backwards compatible way to secure the vulnerable keys.
1 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
yeah, the idea is that EOA key will be deactivated. so signature verification for that EOA won't work on execution / onchain.
0 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
there are also proposal addressing PK deactivation: https://github.com/ethereum/EIPs/blob/d96625a4dcbbe2572fa006f062bd02b4582eefd5/EIPS/eip-7851.md
1 reply
0 recast
1 reaction
jxom pfp
jxom
@jxom
why is it weird? if it's a post-quantum concern, then the issue is orthogonal as majority of multisig & execution signers are not PQ safe right now.
3 replies
0 recast
1 reaction
jxom pfp
jxom
@jxom
It doesn’t need to be “stored” though :)
1 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
for e.g., you can set up a "session" key with some application server. 1. Application Server sends Application Client a Secp256k1 signing key to authorize on the account. 2. Application Client sends request to Wallet to authorize this key as a "session" key 3. Once key is authorized, Application Server can perform calls on behalf of the account.
1 reply
0 recast
2 reactions
jxom pfp
jxom
@jxom
i see the ideal Ethereum Account model as "an account consisting of signing keys" – those keys can either be "admin" or "session" keys. - "admin" keys are of equivalence to the root EOA signer: can send any tx, sign any data, no expiration, etc. can exist in the form of P256, Secp256k1, or WebAuthn key. - "session" keys are temporary and more restricted keys: must have execution guards (rules on transactions), can send transactions under those rules, cannot sign data (impossible to scope), must have expiry.
1 reply
0 recast
1 reaction
jxom pfp
jxom
@jxom
we are building it into porto: https://github.com/ithacaxyz/porto/tree/next so it will be built into its EIP-1193 Provider (`porto.provider`)
0 reply
0 recast
0 reaction
jxom pfp
jxom
@jxom
we are making one now :D
1 reply
0 recast
1 reaction