Donate to creators without addresses

[ErikBjare]

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:

Hello creator!

Someone donated ${amount} ({amount} {currency symbol}) to you using the free and open-source donation tool Thankful.

They donated this using {currency name} and in order for you to claim the donation you have to register an address. To do this, create a {currency name} wallet and reply to this email with the address. You will get a confirmation email when we have processed your claim (done manually, might take 24h) shortly after which you will receive your donation.

Alternative (immediate) registration method:^{[see note 2]} Send a link which contains a URL including a secret key to a server we run where one can enter the address.

The donation will be refunded if the donation is not claimed before {expiry datetime}

About Thankful: {pitch}

Keep creating awesome things!
// The Thankful developers

If the creator doesn't reply to the email in x days, the donation gets refunded.

Issues

• How much gas will it take? (how large will the transaction fees be?)
• Where are transactions fees payed?

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.

[ErikBjare]

Feedback wanted from @johan-bjareholt @Powersource @patrik-laurell @ahnlabb @vlthr

[Powersource]

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.

[ErikBjare]

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 🚀 🌔

[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. 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:

• 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.
• 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.

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?

[ErikBjare]

I made a PR to thankful-contracts with a WIP contract: SuperuserLabs/thankful-contracts#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.