HIP24: Reward Splitting

[jamiew]

Author(s): @ericmheilman
Initial PR: #104
Start Date: 2020-12-26
Category: Technical

Rendered view:

https://github.com/helium/HIP/blob/master/0024-reward-splitting.md

Summary:

This proposal introduces a new transaction, transfer_gateway_v2, which will allow a hotspot owner to irrevocably transfer a percentage of their hotspot ownership to another owner. Percentage of hotspot ownership will be determinant in the payout of HNT rewards (50% ownership -> 50% of HNT, 10% ownership -> 10% of HNT, etc.). This transaction can have an optional amount of HNT associated.

Formerly known as: Transfer Percentage of Hotspot

[GP-Colorado]

I wonder how critical this is to the success of the network. I'm inclined to suggest that we follow the KISS philosophy and resist urge to find new ways to complicate the environment.

[rmichalo]

agree with GP-Colorado - my initial reaction here is that this is a bit overkill.

[GP-Colorado]

agree with GP-Colorado - my initial reaction here is that this is a bit overkill.

Thanks. As we add more complexity to the code, we add more possibilities for compromise and disruption down-the-road. Facilitating various forms of ownership and accounting is not, from my perspective, essential.

Once the system is fully functional, with perhaps hundreds of thousands of hotspots, I doubt that most owners will care in the least about the features being discussed. Look to the future. Let Helium be as simple to understand, secure, and maintain as possible. I expect that the more complex that the system becomes, the less it will appeal to newcomers.

KISS!

[shawaj]

I wonder how critical this is to the success of the network. I'm inclined to suggest that we follow the KISS philosophy and resist urge to find new ways to complicate the environment.

I'd say it's pretty critical, I'm my personal opinion. Especially for setups like Emrit, or for example for paying for a cloud gateway management platform that has running costs...

It needs to be easy for the end user for sure. It doesn't necessarily need to be as easy to the miner / hotspot operators or any other backend stuff.

The potential for 3+ owners and syndicates seems pretty cool too.

[maco2035]

I hope to see if there is a way to make it so that the split is only for X amount of block. So the network checks and says, this transaction only can be split if it under X blocks from the request to split the rewards.

[jsteelel]

I'm new to this community, but I can definitely see a benefit to this. Right now, this network is going to spread by individuals that have been in crypto for long enough to know that this is legit opportunity. Because we can't just create a server farm of hotspots in one location, it's necessary to bring others in that aren't going to do the same amount of research and commit time to figuring out. Those same people will accept a hotspot, plug it in, and take a share of earnings, though, if someone else makes it easier for them. This will help to smooth that process.

[mj0lken]

This is a vital HIP imo: Current and further regulations in EU could potentially put players like Galiot & Emrit in deep doo-doo tax-wise. This technical add-on could prove vital if we want rev splits to still be a thing so that larger patrons can exploit/cover new areas. Lone Wolfs doesn't cut it if we're gonna use this network on a broad scale within a year or two.

[hippolyth]

I think this is super important to grow the network, for example i have a lot of friends where i could place an accespoint and they can't offord to place one so i could easily let them co own it.

[Discodave95]

Being able to have an automatic percentage split with the person I have hosting my hotspot would be very helpful. That would make wider deployment easier. They setup a wallet within the Helium app and the delegated percentage of rewards will be distributed directly to them. Irrevocable maybe until a new new location is asserted.

[daniellundgren]

I see this HIP as a crucial step in order to expand the Helium network. The current process is inefficient and cumbersome for hotspot owners who need to calculate and make payments on an ongoing basis. Calculating taxes, in particular, would become a lot less challenging and complex after this change is implemented. For example, short term capital gains begin to accrue as soon as the HNT is mined, requiring hotspot owners to either cover that cost themselves or themselves or transfer the HNT on a daily basis. Having the ability for a set percentage of the HNT to be deposited directly into the host's wallet at the moment it is mined would automate the entire "payment" process, removing lots of manual steps for the hotspot owner. The hotspot host would then receive their HNT at the moment it's been mined. The option for splitting rewards at 3 levels (owner, host, and referrer) and in increments of 1% seems like an easy-to-understand change that would provide substantial value to hotspot owners, hosts, and referrers alike. One of the challenges faced by hotspot owners is finding placements for devices. Removing the overhead for referral payments helps incentivize hosts and owners to quickly find new placements with hosts. I also second Discodave95's suggestion about making it irrevocable until a new location is asserted.

[jamiew]

@Discodave95 @daniellundgren please note this proposal is for a truly irrevocable transfer of reward %, and would not be suitable for common hotspot hosting setups. Those can be managed through one of the many community apps for that purpose, like Hotspotty or Patrium.

The rationale for this is discussed in the HIP and above. To re-iterate:

• Anything added to the blockchain causes bloat and blockchain bloat is a serious long-term concern
• Any changes to blockchain logic are serious and heavily reviewed. Thus any "on-chain host management" would be severely limited, and receive slow and infrequent updates. Ideally it would never be updated.
• Revocable payments to hosts can be managed off-chain. Additionally, because these are centralized web applications, the business logic can be easily upgraded and new features added. Other currencies, fancy referral stuff, whatever.
• By contrast, trustlessly transferring an irrevocable % of rewards is not possible off-chain. This feature would enable unique opportunities for securitizing rewards and financing hotspot deployment operations.

In summary if you were to use this feature, you could not take that % of rewards back. The recipient would need to voluntarily transfer it back to you.

If that point is not abundantly clear, this feature might be too dangerous to be rolled out. There's no undo.

[Discodave95]

@jamiew irrevocable is fine. If it can be voluntarily transferred back even better.

[daniellundgren]

@jamiew, Thanks for the clarification. That makes sense. If the irrevocable % of rewards can be voluntarily transferred back, I still see that as a workable solution. For example, in the case where a % holder wants to remove themself from the arrangement or perhaps have another person step in to take over their percentage, they could voluntarily transfer their percentage to attach it to another wallet. It could almost function like shares in a company at that point.

[MarkJelic]

In summary if you were to use this feature, you could not take that % of rewards back. The recipient would need to voluntarily transfer it back to you.

If that point is not abundantly clear, this feature might be too dangerous to be rolled out. There's no undo.

I think this is dangerous and can cause all sorts of legal issues. The owner should always be able to make adjustments... Maybe the host realises there are extra costs and wants a greater reward? Or if the Hotspot gets moved, then a new host address and percentage needs to be added, and this time there wasn't a referrer.

I really don't like the word "irrevocable". The owner should always have last say, and if the host or referrer see they are getting diddled by the owner, then they simply unplug the device and get their own! That alone is enough to keep the owner honest.

[birbrayerb]

Couldn't this issue be resolved with a simple pointer to two wallets after the coins get issued to the original wallet? For example, from within the app, you select what percentage of incoming HNT per miner should be forwarded to another address, leaving whatever not sent within the original wallet. Thus only through the creation of new transactions is the "split" distributed. Seems like an easy workaround in my opinion.

[daniellundgren]

Couldn't this issue be resolved with a simple pointer to two wallets after the coins get issued to the original wallet? For example, from within the app, you select what percentage of incoming HNT per miner should be forwarded to another address, leaving whatever not sent within the original wallet. Thus only through the creation of new transactions is the "split" distributed. Seems like an easy workaround in my opinion.

I like that option as a potential solution, but I do see some potential issues. I'm curious about the mechanics of how this could work. Would the automatic transfer require DC to be spent as a normal wallet transfer does? If this is happening with every little mining reward,that could add up. Perhaps there could be an option to sync up at the end of the day? Also, for taxes, it would matter whose wallet it was deposited into initially. Part of the appeal of sending the rewards directly into the separate wallets is that each stakeholder receives their portion directly and immediately upon being mined, so no HNT has changed hands.

[cvolkernick]

What is the status on this? This would massively simplify the revshare aspect of the common operator/host model despite what minimal overhead it might add. My understanding is that there is community-provided code (thanks @ericmheilman ) written for this that has just been sitting waiting for some action to be taken in an official capacity. Could we kick the tires a bit and either move forward or gather some productive feedback for the developer to implement?

[jamiew]

@cvolkernick could you provide some links to the community-provided code you mentioned? That seems like the most relevant status update. I believe this HIP has some community support, but as-described it is completely irrevocable, and all of the questions and comments seem related to that very important (and potentially confusing) detail.

[cvolkernick]

@jamiew I don't have any direct link that was just the last thing I had read on the discord from the HIP author / developer @ericmheilman -- he would probably be the one to provide that.

[cvolkernick]

@jamiew here it is, just got it from @ericmheilman

helium/blockchain-core#729

[Ernestoxx]

if i understand this correctly, i think this will be beneficial. because people like me dont have mine farms or multiple houses etc to put their hotspots so we rely on friend's houses and give them a % of the profit. this will make it easier for us to split the rewards.

this is a good idea

[kuniholm]

This is a good idea. Shared ownership of hotspots creates growth. Making it easier improves growth. As long as the owner can always adjust designated reward sharing, this is no different than any other transfer of funds on the network, which are also "irrevocable." The mechanics of accounting for shared ownership are a pain, and this would ease it.

Now it is true that if there were, say, 10 owners, that that means 10x reward transactions, which are far more than are created by monthly payouts, e.g., so it does indeed increase the number of transactions on the Blockchain.

It would be great if this could be done with validators as well. That is far fewer transactions, both per node and overall.

Could there be a way to reduce the number of reward transactions and accumulate them to ease this burden?

[cvolkernick]

For what it's worth, it seems as if there may be a major component to this that is either under-appreciated or being missed entirely, with regard to positions supporting layer 2 approaches.

It seems that the major blocker for layer 2 payment solutions is the automation and/or scheduling of manual or batch payments. Because each transaction needs to be signed with the payor's private key, and because an automated payments system of this kind is not air-gapped by design, it presents an inherent security flaw / risk in these instances.

Allowing for on-chain assignment of earnings splits would resolve this issue, as the involved parties would not need to apply any PK signatures beyond the initial assignment transaction.

I realize that there have been some discussions around what the constraints might be around odd splits, which party / parties hold authority to sign these transactions, etc...however, IMO the most obvious solution is to keep things simple:

1. Same baseline constraints as multipayments; no more than 49 unique addresses (Not sure if multipayment tx can be invoked by another type of tx, but if so that would essentially provide the "engine" of this HIP, or at least provide an analogous starting point to model from).
2. All assigned splits must total exactly 100%, with no fractional percentages assigned.
3. Hotspot owner address has sole authority to set/reset splits.*

*Not certain if possible, but theoretically you could accomplish multi-party signing of splits by using sharded keys as the hotspot owner

@kuniholm -- see my above comments Re: multipayments.. ;)

Now it is true that if there were, say, 10 owners, that that means 10x reward transactions, which are far more than are created by monthly payouts, e.g., so it does indeed increase the number of transactions on the Blockchain.
...
Could there be a way to reduce the number of reward transactions and accumulate them to ease this burden?

Multipayment documentation found here.

I think this could actually have the potential to lead to less transaction bloat. Consider the fact that all of these payment transactions are happening one way or another -- it's simply a matter of whether they are batched/bundled or not.

If payments were issued in an inherently batched way, a lot of these would end up being bundled together (which, IIRC, is technically more efficient; i.e. a single 10-address multipayment is less costly than 10 separate, individual payments of the same amount & destinations). "Worst case" scenario then is if every single payment was done as a one-off regardless....which is where we currently stand.

[jamiew]

The issue has been relatively contentious and fraught with technical challenges (e.g. reward txn chain bloat). @ericmheilman has indicated on Discord that this could be closed. So if there's no other objections, I'd like to nominate this to be closed.

[capjbadger007]

The issue has been relatively contentious and fraught with technical challenges (e.g. reward txn chain bloat). @ericmheilman has indicated on Discord that this could be closed. So if there's no other objections, I'd like to nominate this to be closed.

Seconded for closing this and archiving the related HIP discord channel.