Think about settlement beneficiaries other than the channel participants

[loredanacirstea]

Do we need functionality to have a beneficiary of settlement payouts? Example: embedded devices with their own privatekey that are funded by human user with a different privatekey. This can also apply to third party services that can provide token deposits on behalf of a channel participant for easier onboarding.

[LefterisJP]

I would say not at the moment. If the embedded device is owned by the human user they can always just forward the funds.

I mean it would be convenient perhaps but I would rather keep the protocol as simple as possible and keep only to the "strictly required" at the moment.

[hackaugusto]

I see three options:

• Define the beneficiary address in at the channel creation (bad, currently we required only one node to open a channel, this would required a protocol for opening channels. Additionaly, chaging the beneficiary would require a on-chain transaction)
• Additional field as part of the balance proof (doesnt change channelOpen, but increases the gas cost for storing the beneficiary field on uncooperative close. May be good for upgrading the beneficiary address, with the caveat that older balance proofs are still valid, and under bad behavior an old address may receive the funds)
• As part of the balance proof's additional_hash. (almost the same as the previous option, but we trade storage for code complexity and additional hash computations)