Open ErikBjare opened 6 years ago
Feedback wanted from @johan-bjareholt @Powersource @patrik-laurell @ahnlabb @vlthr
Initial reaction is that this sounds great. The refunding solves the issue of people not wanting to send funds to someone that will never collect it. Will think about this more.
It just hit me that this could be a huge deal not only for Thankful but for crypto adoption in general, if we manage to get people to donate to a lot of creators. This solution seems almost too good to be true, but I can't see any major problem with it, so lets see how high this rocket can fly :rocket: :moon:
It would make a huge difference to have something like this! We will still be holding the money since the contract won't be autonomous and I'm not sure what that implies legally but it sounds fine. My only worry is the correctness of the contract since it could potentially become a target. Note 1 goes a long way towards solving this; a short and hard-coded time would lower the profit to be gained from exploiting the contract as well as the complexity.
Things I think we need to consider carefully:
Also, I really like what you said about adoption, would generate a lot of goodwill in the crypto community.
What do you imagine on the client-side UX-wise? Specifying an email address instead of an ETH-address?
I made a PR to thankful-contracts
with a WIP contract: https://github.com/SuperuserLabs/thankful-contracts/pull/1
@ahnlabb
It would make a huge difference to have something like this! We will still be holding the money since the contract won't be autonomous and I'm not sure what that implies legally but it sounds fine.
I doubt there could be any legal issue. We should not be considered a money transmitter, just a trusted registrar who maps from emails to addresses (but IANAL).
My only worry is the correctness of the contract since it could potentially become a target. Note 1 goes a long way towards solving this; a short and hard-coded time would lower the profit to be gained from exploiting the contract as well as the complexity.
I thought about that aspect of it, that the expiry reduces the chance of it becoming a valuable honeypot.
Upgrades, we should make as few assumptions about the contract as possible on the client-side. We want to get address and other details dynamically, slipping here could cause major headaches in the future.
Good point, something to consider for the PR I made.
Fail-safes. We should at the very least have some way to disable this feature retroactively in running client versions so that people don't send money to a broken contract.
I've heard this called a 'failsafe' in other places (Augur, notably). Definitely something we'd need.
What do you imagine on the client-side UX-wise? Specifying an email address instead of an ETH-address?
Yes, but either could be provided, no need to make it exclusive. Although an email might be preferred as the owner of the email could be allowed to modify the destination address by contacting us.
This is a crazy idea, but it just might work.
Imagine an Ethereum contract, that when you call the donation method you specify an email address which the donation amount gets stored to.
There exists a mapping from an email to a Donation struct, containing: the donated amount, who donated, an expiry time[see note 1]. is associated with an email, but there is no way for the creator to access the donation that is now stored in the contract.
Now, let me introduce: The email server. We have a server running, watching for changes to the contract, and send out email to creators who have donations pending.
The creators replies with their address to us, we resolve the missing creator in the contract (which we as contract owners have a special right to) and when that is done the donation is sent to the creator.
The email
The email would look something like this:
If the creator doesn't reply to the email in x days, the donation gets refunded.
Issues
Notes
Note 1: Might not store this but instead have it fixed to save on transaction cost and complexity. Another option is to fall back to a default value. We should set this low because we don't want funds to be locked up when there is a small probability it will be claimed.
Note 2: More work to implement early on, we should start simple.