jxom

@jxom

42 Following

25024 Followers

jxom pfp

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

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

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

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

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

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

It doesn’t need to be “stored” though :)

1 reply

0 recast

0 reaction

jxom pfp

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

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

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

we are making one now :D

1 reply

0 recast

1 reaction

jxom pfp

Usually the app would be communicating via JSON-RPC to a secure wallet environment that holds the passkey (e.g. x-origin sandbox iframe, external popup, browser extension).

1 reply

0 recast

1 reaction

jxom pfp

Isn't this problem orthogonal to 7702 and Passkeys though? You could argue the same for an account controlled by any type of other key (secp, p256, etc).

2 replies

0 recast

1 reaction

jxom pfp

The Wallet would preface with a UI before the end-user signs w/ passkey, no?

1 reply

0 recast

1 reaction

jxom pfp

so you have your passkey and something else as "admin signers"

1 reply

0 recast

1 reaction

jxom pfp

Elaborating on point 3: you can also configure the root admin signer to be of something different to a passkey.

1 reply

1 recast

3 reactions

jxom pfp

interfacing over = displaying tx/signing UI to end-user. passkeys actually makes this easier for tx with SPCs (which are very flexible): https://developer.mozilla.org/en-US/docs/Web/API/Payment_Request_API/Using_secure_payment_confirmation

1 reply

0 recast

2 reactions

jxom pfp

Secp256k1 is even worse, there's no "prompt" at all. ;) We have normalized the pattern of Wallets interfacing over Secp256k1 signing (ie. browser extensions, WalletConnect, etc), so same goes for Passkey signing.

3 replies

0 recast

3 reactions

jxom pfp

Have you seen https://wagmi.sh/react/guides/ethers

1 reply

0 recast

0 reaction

jxom pfp

what’s wrong with Viem?

1 reply

0 recast

0 reaction