Content pfp
Content
@
0 reply
0 recast
0 reaction

Jason pfp
Jason
@chaskin.eth
Sample size is small but I made this poll in /ethereum and 19/21 people voted that they want light clients built into wallets. What can we do to push for this? Open to all and any ideas, let's discuss!
4 replies
1 recast
10 reactions

shazow pfp
shazow
@shazow.eth
Good nuance on trusting, but the issue is relying. I don't believe we have a way to build a wallet that does not rely on centralized RPCs (but at least it could verify that they're not lying).
1 reply
0 recast
1 reaction

Jason pfp
Jason
@chaskin.eth
Correct but the goal is to make Ethereum as trustless as possible for the end user and verifying that they aren't lying is a huge step in the right direction The next step would be to increase the number of centralized RPCs you're requesting data from as you only need one to provide an honest Merkle proof
1 reply
0 recast
1 reaction

shazow pfp
shazow
@shazow.eth
Also correct me if I'm wrong, but I'm not sure there's a light client way yet to verify the correctness of the claimed block head? (Aside from doing a simple N of M samples.) From the perspective of threat model that users care about: 1. RPC is down or geoblocked, nothing works. This is 99% what people care about in my experience, most of us have experienced this for one reason or another. (I wanted to address it with vipnode.org a long time ago, but it was a dead end at the time). 2. RPC lies about a response, tricking you into believing some state that facilitates signing a transaction that you otherwise would not have signed? I'm not sure if this has ever happened, and it's hard to imagine a specific scenario. Do you have one in mind by any chance? Still worth protecting against of course, but might be implicitly fixed by solving #1 too.
1 reply
0 recast
1 reaction