a guest Aug 17th, 2019 133 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
- # Sending Funds over Twitter
- The basic idea is to send funds on Ethereum with calls triggered by tweets of a certain format. Still brainstorming the name, but, at the moment, the handle in all examples is `@this_app`. In this post, I discuss my first thoughts on how this might look. There are still many unanswered questions. **Please be critical!**
- ## MVP
- The format of a tweet designed to trigger `this_app` may look something like
- @this_app send @receiver <valid_amount> <valid_currency> <estimated_gas_fee>
- Checks before the send include
- * check that the `@sender` that made the tweet has `free_balance(&sender) > valid_amount` for the `valid_currency` in question
- * check if the `@receiver` already has a counterfactually instantiated account within the context of the DApp `=>` if not, make one; if so, add to their balance and send `estimated_gas_fee` to cover the eventual claiming of the counterfactual contract (assuming it satisfied range bound checks described below)
- **How does it work?**
- * Behind the curtains, the `@sender` might send to a counterfactually instantiated contract that Twitter's auth verification of the `@receiver` might eventually unlock as per the account owner's request `=>` could add 2FA (as an option, not a required feature!) to prevent Twitter from claiming the individual's funds
- **Range Checks on Gas Fee**
- * there is the risk that `sum(Vec<gas_fee>) < gas_fee_at_time_of_claiming_balance` in which case the `receiver` will need to add some `ETH`
- * one way to mitigate `@sender` abuse by sending low `gas_fee` is to include a 4th parameter called `cancel_period: BlockNumber` such that the call is invoked if the `actual_gas_fee` (determined by some oracle) go below the `estimated_gas_fee` `=>` the `estimated_gas_fee` is an upper bound of the amount of gas the sender is willing to pay so it should probably be renamed such that:
- @this_app send @receiver <valid_amount> <valid_currency> <max_gas_fee> <cancel_period>
- Improvements might include
- * not charging gas fees from the user -- meta-transactions?
- * setting limits on `spend_amount` per some `SpendPeriod: BlockNumber`
- The approval (tweeted by `@this_app`) to indicate execution may contain a response to the original tweet of the format
- @sender successfully sent @receiver <valid_amount> <valid_currency>
- If the `max_gas_fee` is not above or at the `actual_gas_fee` provided by the oracle within the `cancel_period` mentioned above, the transaction might not be approved. A cancellation notification might look like (*in response to the original request*)
- @sender failed to send @receiver <valid_amount> <valid_currency>
- ## Advanced Version
- I propose a new command set for interacting with the Ethereum gas market. We should enable participants to specify a range for acceptable gas fees such that the participant's request is automatically executed when the fee is within that range (could instead offer the option to push notifications to the participant when within that range and require additional explicit approval).
- @this_app send @receiver <valid amount> <valid currency> <min_gas_fee> <max_gas_fee> <cancel_period>
- * `cancel_period` implies that if the `actual_gas_fee` (measured by some oracle) is not between the `min_gas_fee` and the `max_gas_fee` within the `cancel_period`, then the transaction is canceled (the canceled transaction elicits a push notification and might allow a tweet by the `@sender` that replaces the `send` command with a `resend` with the same or different parameters)
- **Range Recommendations based on User Risk Tolerance**
- * the DApp should maybe interact with the user somehow and recommend a gas fee range based on the current market dynamics as well as some measurement how much the user wants to ensure the transaction's inclusion within the `cancel_period`
- * a simple MVP might prioritize request execution -- maybe delegate the derivation of the recommended range to a few key stakeholders (or a DAO) to provide some forward guidance-esque mechanism)
- * Note that there might be more commands than `send` such as `cancel` or `resend` (which could overwrite an existing/failed `send`)
- *Less of a priority...*
- * the `gas_fee` parameters are always denominated in ETH, but could eventually consider the possibility of paying gas fees with another token (using Uniswap or something, idk?)
- ## Security Risks
- ### Organization Account
- If the organization is hacked, this could create the illusion of confirmed spends in the absence of actual confirmed spends. It is necessary to closely monitor the account of `@this_app` or manipulation may occur and the reputational damage may be irreparable. Fake confirmed spends could lead to the illegitimate sale of goods/services in which the salesperson is left empty handed with the impression that they have attained access to some digital value.
- ### User Account
- After the send is executed, it not possible to recover the funds. Moreover, Twitter hacks do happen. One way to alleviate the risk of a hack would be to set a limit on amount sent per tweet and a limit on the number of tweets in a time period. This could be set by default to be relatively restrictive until it is more clear how often hacks might occur. To change these limits on tweet frequency and per-tweet transfers, we might require the user to stake some outside collateral (similar to a deposit) -- if the true owner signs a challenge message with their private key before some long enough time period, the collateral is slashed and the previously set limits do not change
- #### Insurance against Twitter Hacks/Abuse
- One solution to alleviate hacker risk could be to construct an insurance market that also indirectly provides a proxy for Twitter's security standards. The basic idea is to design a market that allows buyers/sellers to bet on the frequency of reported Twitter *hacks* related to the DApp. The participants might report hacks every `CensusTime: BlockNumber` to anchor expectations to some real-world outcome measured in the form of the results of a user survey. To hedge against the probability of a payment getting hacked, a user bets on the current `HackFrequency: u32`. A user `survey` (structured like a referendum) could record the reported hacks for the previous `CensusTime` period. The results could be compared against the bets to redistribute the funds used in betting among the market participants according to past accuracy. This keeps the markets honest by anchoring price to an unpredictable data point (assuming sufficient competition in the market...a big assumption!). At scale, *this market optimistically provides a proxy for public sentiment for Twitter's security* while also enabling participants to hedge the counterparty risk implicit in relying on Twitter, a centralized third party service, to send/receive funds.
RAW Paste Data