Smeshers, Coinbases and Rewards

[brusherru]

Context

In the latest version of Node (0.2.16-beta.0) we get rid of

• API endpoint: GlobalStateService.SmesherRewardStream,
• API endpoint: GlobalStateService.SmesherDataQuery
• SmesherId within Reward type (used in GlobalStateService.AccountDataQuery/Stream)

See also: spacemeshos/api#163

Problem 1

Since we can not request rewards filtered by SmesherId, then we need to use a coinbase. It is not a problem to get the current coinbase. But in case if User switched the coinbase we have no history for it.

• So we need to store a mapping SmesherId -> Coinbase[] on fs and use it to request a rewards log.
• PoS data directory seems like a good place to it (next to key.bin file).
• Since go-spacemesh is an independent tool (it runs without any wrappers or clients), then probably the Node should take care of this mapping, as a standard way to store such data.

Problem 2

Since we have no SmesherId in the Reward message, then how we can distinguish our "Reward" from the reward of another Smesher. Example:

• Alice started smeshing for CoinbaseA
• Bob also started smeshing for CoinbaseA
• Then Alice queries for rewards for this CoinbaseA and see rewards from both smeshers (Alice and Bob)
• Which reward came from Alice, and which one from Bob?

---

I assume that these problems are related and probably will have a single solution for both.
If you have any ideas — welcome! :)

cc: @countvonzero @dshulyak @avive @oriya @lrettig

[countvonzero]

i agree that Problem 1 can/should be easily taken care of by go-spacemesh.

Problem 2 sounds more involved.
in this case do you mean Alice and Bob happen to create the same address? or do they deliberately use the same address for smeshing? @brusherru

[brusherru]

deliberately use the same address for smeshing

So it is not a common case. But since we are giving the ability for Smeshers to switch coinbase to any valid address, then we should handle such cases as well. Right?

Btw, a valid address for coinbase is only a single-key wallet address? Or it might be also multi-sig?
E.G. "I decided to smesh and send my rewards directly to some charity fund, represented as a multi-sig wallet, so I've specified this charity fund address as Smesher coinbase"
But actually, I can just send SMH to this charity fund, and it will save only a couple smidge for me, so probably it is a strange case. At least until rewards per layer are greater than a couple of smidges :)

To sum up:

• the second problem is not critical since it is not a common case,
• but in case we'll have a few smeshers for one coinbase — it will be confusing

[dshulyak]

I don't understand why historical coinbases should be stored by the node. Sure technically it is trivial, but it is not in the scope. Node doesn't manage keys, why should it manage addresses of the keys?

[brusherru]

Node doesn't manage keys
What do you mean?

The node creates a key.bin file and put it in the PoS data directory.

Also, Node can start Smeshing (even for the new coinbase, which is changed by Smesher manually in node-config) without any other client-side apps, like Smapp. So it sounds logical to store this mapping I think.
Also, it will provide some kind of "standard way" to store this data and use it even between different client apps (Smapp and Smrepl will have the same behavior by default).

So I don't insist, and it is also trivial to do it on Smapp's side.
But it seems to me the best solution. At least since all clients will have it by default, with the same schema, etc.

Maybe I miss something. That's why I've created a discussion instead of an issue ;)

[dshulyak]

That key is a "protocol" key, we also use p2p key. But it is not related to the wallets/accounts, unlike coinbase.

[lrettig]

The link between the smesher who earned the reward, and the coinbase that receives it, is broken here:

go-spacemesh/blocks/generator.go

Lines 100 to 126 in 35ab2c2

	for _, p := range props {
	if p.AtxID == *types.EmptyATXID {
	// this proposal would not have been validated
	logger.Error("proposal with invalid ATXID, skipping reward distribution", p.LayerIndex, p.ID())
	return nil, errInvalidATXID
	}
	atx, err := g.atxDB.GetAtxHeader(p.AtxID)
	if err != nil {
	logger.With().Warning("proposal ATX not found", p.ID(), p.AtxID, log.Err(err))
	return nil, fmt.Errorf("block gen get ATX: %w", err)
	}
	ballot := &p.Ballot
	weightPer, err := proposals.ComputeWeightPerEligibility(g.atxDB, g.meshDB, ballot, g.cfg.LayerSize, g.cfg.LayersPerEpoch)
	if err != nil {
	logger.With().Error("failed to calculate weight per eligibility", p.ID(), log.Err(err))
	return nil, err
	}
	logger.With().Debug("weight per eligibility", p.ID(), log.Stringer("weight_per", weightPer))
	actual := weightPer.Mul(util.WeightFromUint64(uint64(len(ballot.EligibilityProofs))))
	if _, ok := weights[atx.Coinbase]; !ok {
	weights[atx.Coinbase] = actual
	coinbases = append(coinbases, atx.Coinbase)
	} else {
	weights[atx.Coinbase].Add(actual)
	}
	events.ReportProposal(events.ProposalIncluded, p)
	}

because the proposals (which receive the rewards) are collapsed into a map of coinbase -> value. From the perspective of the protocol this makes sense, because the smesher associated with a particular reward is no longer useful, but it's less than ideal from a usability perspective. We could theoretically add the smesherID back to the reward data type, but that would result in protocol bloat.

@brusherru I think the best thing to do here is just always use the current coinbase when displaying rewards. In other words, just show historical rewards earned by this coinbase. Yes, it's possible that multiple smeshers may use the same coinbase address (which by the way can be any address, including a multisig). If we think this is confusing to users, we can add a tooltip popup in the app to explain it. As you point out it should be pretty uncommon (for home miners) that they'd be using the same coinbase as someone else, anyway. It should also be pretty uncommon for home miners to change their coinbase, so I think this is fine for now.

One more UX note: if we also display predicted, upcoming rewards, these are tied to a particular smesher, not a coinbase. We can add a note to explain this too.

[brusherru]

always use the current coinbase

I like this idea! It makes everything simpler.
Besides this, we can actually show rewards for previous coinbases (Smapp already stores Txs and Rewards on fs).
But in case Smesher deletes this file or runs Smapp on another PC — Smapp will be able to retrieve only historic rewards for the current coinbase. I think it is not a bad compromise. And sounds better than having additional SmesherId->Coinbase mapping or something else :)

if we also display predicted, upcoming rewards, these are tied to a particular smesher, not a coinbase

SmesherService.EstimatedRewards is not implemented yet. And probably is out of scope for now.
But I agree on it and I think we can make it pretty clear for Smesher — you can change your rewards address, but estimated rewards are still the same :)

[dshulyak]

I don't recall if we considered referencing atx id in the rewards. It is almost as compact as using a single address, but provides a reference to both to the coinbase and smesher.

[countvonzero]

yes. we did. and i considered it as the most viable option if we end up having to associate smesher ID with reward.

[brusherru]

To sum up what we decided on a dev call:

1. Problem 1: Avoid storing the history of used coinbases, and just use the current coinbase to retrieve rewards.
   In addition to it, Smapp can store such rewards on fs (actually already does it), and then Smesher will be able to see his rewards for any coinbases. And this file can be recreated only by switching coinbase to previous ones.

2. Problem 2: Seems we might solve the issue, but since it is a very uncommon case, not a blocker and not a bug. Then we decided to postpone this thing as much as possible. So we can return to it when we face such cases in reality.

Hopefully, I don't miss something :)

[lrettig]

That sounds correct. We discussed that the explorer might also want to display these data, and that at present the only way to do so would be to either add the association back in the protocol (which we're not going to do, for now), or else to run some sort of "archive node" that stores the historical data, and also add a new API endpoint to provide it (will note this in spacemeshos/api#163).