Idea (post-state-v2): Recieve by rep

[My1]

so the State v2 Blocks are seemingly decided to come into Nano, and they have a VERY nifty new field, the signer, which not only would make epoch signing easier (despite it being a very weird concept on the chain only you are supposed to be able to modify), it also allows for some other things, one of which I am proposing now.

one of the very annoying things of Nano is the issue with ready to recieve blocks, which are kinda floating send blocks, as I like to imagine them. This while not only adding confusion to users because "pending" transactions are still final they are not part of the balance yet and are often wrongly seen as unconfirmed sends, a wholly different matter, also has the far bigger issue of these floating nano, not being part of consensus.

This means that for example 2 Million NANO from Binance's second cold wallet are not taking part in the voting process (as well as any other Nano that wasnt properly recieved), on top of that, floating sends cannot just be thrown into pruning or whatever but need to be kept ready to ensure that the account can properly recieve it, which is kinda annoying.

So my Idea would be that with or some time after state-v2 that on a block that only acts as a recieve, the representative of that account has the ability to sign those blocks (if it wants to) so the Nano can stay in the consensus process to keep voting healthy and more Nano online

[PapauloGamerOfc]

I can think of some problems with this.

1. Fork: a fork can happen in the case that someone makes an account_info RPC to get the frontier and publishes a block, but at the same time the representative publishes a receive-by-rep block. And we already know the problems of the fork, like the block that the user created not being confirmed etc.

2. Spam: Let's first assume that the representative is nice. In this case, Alice is the representative of Bob and Jake is the attacker. So Jake has a higher balance than Bob. For example, Bob has 0.1 Nano and Jake has 1 Nano. And Jake spams a lot of 1-raw send blocks to Bob. Alice posts a receive block for every send block. Then, Jake transactions get confirmed because of balance * LRU prioritisation, but Bob's transactions created by Alice don't, so he ends up with a lot of unconfirmed receive transactions and not able to create transactions. If the representative isn't nice, Alice and Jake can even be the same person. He/she may do it so Bob can't change the rep. But I consider the first situation more probable.

PS: I know that pending blocks suck because they difficultate prunning, but these are 2 problems I found that may happen with allowing receive-by-rep.

[My1]

well sending a ton of 1 raws can be devastating in many ways (e.g. pending sends cant be pruned away
also fork issues can be prevented by ensuring a hard priority on owner blocks. that ensures that if a rep is bad the owner can just fork it away.
also creating a fork at some place in unconfirmed by the owner ensures in the same way that a rep cannot accidentially or maliciously make too many problems for an account.

to get your example if Bob needs to line his tx in he can fork the problematic tx away.

[qwahzi]

I'm wondering if this suggestion solves the wrong problem. Rather than allowing reps to sign receive blocks for others (adds complexity & risk), wouldn't it make more sense to just allow receivable vote weight to participate in consensus (e.g. #2379)? Or is there any other benefit to allowing reps to receive on behalf of others?

[My1]

I'm wondering if this suggestion solves the wrong problem. Rather than allowing reps to sign receive blocks for others (adds complexity & risk), wouldn't it make more sense to just allow receivable vote weight to participate in consensus (e.g. #2379)?

I like the idea.

Or is there any other benefit to allowing reps to receive on behalf of others?

well, pruning

[qwahzi]

well, pruning

Ah of course, can't believe I forgot that!