Add a payment pool implementation

[spalladino]

🎉 Description

This post describes a Merkle tree based implementation for one-to-many recurring payments with minimal gas usage, which is heavily based in what was discussed with Peter Watts.

I believe it is an interesting use case, and we could supply implementations for one-time one-to-many payments, as well as recurring one-to-many payments, using this strategy.

• 🐛 This is a bug report.
• 📈 This is a feature request.

[frangio]

Yes! Fixes #704?

[spalladino]

I'm not sure if one of the goals of airdropping is actually pushing the tokens to the recipients, so they don't have to claim them, and the tokens generate a "hey, what are these tokens doing here?" effect.

[frangio]

I'm not sure either, but it could be.

Where would a user see that balance anyway? Etherscan displays it but I doubt that is a tool that end-users use, and I don't know of any wallets that would show it.

[spalladino]

Maybe a special client app for the token...? Just guessing, though.

…

On Tue, Jan 30, 2018 at 3:16 PM, Francisco Giordano < ***@***.***> wrote: I'm not sure either, but it could be. Where would a user see that balance anyway? Etherscan displays it but I doubt that is a tool that end-users use, and I don't know of any wallets that would show it. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#715 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAaOJIF7tSe4bVgf8UBGvDZy-iFgWnTVks5tP1xogaJpZM4Ryur3> .

[buybackoff]

In the tests withdraw function consumes 155k gas vs c.40k of standard ERC20 transfer.

With a large number of accounts the Merkle proof will grow in size and gas cost will grow as well. Currently there are only 8 accounts in the test. Maybe implementation is raw and could be optimized?

This approach will save gas for the paying side, but users will pay almost 4x higher cost and the total gas is also 4x higher. This scheme shifts the costs to the users, while the paying party just pays for a couple of SSTOREs for N users.

Please correct me if I get something wrong here?

[spalladino]

Without going through the tests in detail, yes, this implementation shifts payment costs to the users, as the total cumulative cost to be paid by the payer is huge.

[buybackoff]

It's strange, because in the blog post the author writes (bold is mine):

we are building an application framework for decentralized applications (dApps) that puts user experience first

[frangio]

The cost per-beneficiary is certainly going to be larger, though I think it could be quite close if the payment pool logic is built into the token itself (though we will probably not do this in OpenZeppelin). FWIW, the Merkle proof size grows logarithmically with the number of accounts.

[trejas]

Not sure what the protocol is for assignment. I have started a PR using the Merkle Tree solution.

Could someone assign this feature to me?

[spalladino]

Just flagged it as in-progress @trejas to signal that it is being worked on, Github won't let me design you as asignee. Thanks for your interest!

[come-maiz]

Hey @trejas, are you still interested in implementing this?