Ethereum dApps will probably move to users signing blobs of data using private keys that don't actually hold any funds. dApp operators will submit txs including these signatures, proving the end user gave the
.
Lets business pay for gas, deal with nonces, retry TXs, etc.
-
Show this thread
-
Attached screenshot is a concrete example for those that know a little bit of solidity. Basically, why does a user of a social network need to submit a TX saying they accept a friend request? Just use the private key to prove you accept and let the biz submit the TX for you.pic.twitter.com/8E9UGJc3I5
12 replies 10 retweets 55 likesShow this thread -
Replying to @backus
Schemes like this are hard to reason about. If failed tx reverts, signed data can be replayed (can be very dangerous in some cases). If nonce included and tx not totally reverted, front-running attacks possible (unless tx sender included in signature).
2 replies 0 retweets 0 likes -
Replying to @naterush1997
Example I proposed was simpler than I think you're assuming. Not just anyone can submit a transaction containing a user signature. Basically, administrators of the smart contract in question can do it no one else
1 reply 0 retweets 1 like -
Replying to @backus
Sure, but see tweet below. If users can unfriend people, they have to trust that the owner will not replay signed data. Obviously, this isn't a huge deal in this case - just an example of how these schemes are hard to reason about.
2 replies 0 retweets 0 likes
It is more complicated but I don't think it is hard to reason about in a way that implies "don't do it." Are there cases where even the onlyOwner example is very security critical? Yeah probably. I'm just talking about general design patterns that I expect to shift though
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.