P2P fair play rewards

[igormcoelho]

Summary or problem description The idea is to efficiently distribute network/system fee funds to p2p nodes that actively relay transactions.

Do you have any solution you want to propose? I think we should also try to give some rewards to p2p nodes that routed that transaction, via a fair play strategy. The idea is the following: one node relays the tx to the next, signs a tx transmission payload, and receives a "ticket" from the other side (requires some TCP for that.. which I guess we have). The next would also need to add his payload (and previous ones up to a maximum size), until it reaches the consensus node. So, the speaker could "unpack" these signatures and partially distribute funds to these nodes. To prevent corruption, nodes that actively relayed tx and got certificates could verify that their funds were not "erased" in the path, and if this happens, the p2p node would be locally downrated. In time, this strategy would probably converge into a fair play system, with high rated neighbor "peers" that should typically play fairly. A fraction of network/system fee could be given to these nodes by the speaker, and some basic proof-of-work could be required (like padding certain zeros in tx hash before signing), and these could help growing/incentiving the network of p2p nodes. I think that every p2p node would only need to check the previous signature (if it matches the ticket transmission), and the rest would only be checked by consensus node when entering mempool (wrong/bad payloads are discarded, but tx is kept intact). This could also help companies to sponsor promising p2p nodes (with more network participation).

Neo Version (BOTH)

• Neo 2
• Neo 3

Where in the software does this update applies to?

• Consensus
• Network Policy
• P2P (TCP)

[vncoelho]

This is a great type of feature and it has real potential of being integrated in the future generation of blockchain systems, P2P has a crucial role on the network and needs its recognition. While computational cost involved in this strategy is local and minor, there is a great incentive for improving overall network quality.

Finally, this is also aligned with the concepts of multi-agent systems, in which autonomous agents optimize selfish interests, and is also related with the Byzantine consensus running on NEO.

[shargon]

a node can remove your signatures, and broadcast again the tx, how can you prevent this?

[igormcoelho]

a node can remove your signatures, and broadcast again the tx, how can you prevent this?

The general idea was presented above, I'll put more details and one example. During p2p handshake I get your IP and pubkey, now I send you a tx (with extra fields) and you give me a signature of this extended tx. Then you remove the rest of tx and put yours, you send to someone else and get their signature... when tx gets published, and values redistributed, you get your part, and I don't get mine... since you accepted my tx, this means that you are intentionally winning and I'm losing, so I stop sending tx to you (a byzantine p2p node). Another strategy is: you get a tx, remove the rest, send to another machine you own.. then, that machine will earn something, and I cannot suspect you, because you didn't get anything too... so, on general, a p2p node can try to maximize its earnings, ranking the peers that give most benefits to it, which I believe will lead to a fair play system, where everyone will try to play fairly, in order to keep competitive. Like I said, there could be some extra PoW, if signature is not "hard enough", to desincentive nodes to try to earn multiple times (they would become slower than others, thus, not receiving any reward). In any case, the peers that "cheat on their peers" will endup being "less profitable" to them, and they would prefer sending their tx to someone else.

[erikzhang]

When I received a transaction, I can attach 100 signatures on it. How to stop me?

[igormcoelho]

When I received a transaction, I can attach 100 signatures on it. How to stop me?

I, peer A, am sending a tx at Time 0.0s to peer B (byzantine) and peer C (good). I spend more0.1s to put my signature and relay (and possibly a small PoW, maybe not necessary since signing already takes some time...), and that's when peer B and peer C receive my transaction. The interesting part is: peer C will just do the same, and at Time 0.1+0.1=0.2s and then peer D will start working on my tx. Peer B, decided to remove my profit signature, and put 100x different reward signatures... it spends 100 * 0.1 = 10s, and then relays it to peer D, but peer D has already relayed this tx to its peers... maybe tx has already reached consensus nodes, so peer B has wasted its efforts. The relay logic on mempool could store the smallest extra payloads possible, so if it receives a smaller one, it keep compressing (like a "shortest path" approach).

So, putting signatures (and "maybe" a small extra PoW) takes time, and makes you less competitive in p2p arena. But now, let's suppose that peer B succeeded in putting 100 signatures (and didn't remove original signature from A), thus arriving at consensus node for splitting the rewards into: 1/101 for A (around 0,99%) and 100/101 for B (around 99,01%). If this happens frequently, peer A will find out that sending his tx to peer B gives him 1% reward, while sending to peer C gives him 50% reward... so, in time, it's not possible that a node is "stealing" from others "in large scale" and still receiving most tx.

Example: Tx -> TxA = Tx + sig(Tx; pubkeyA) -> TxAC = Tx + sig(TxA; pubkeyC) -> .... Since signatures are cummulative, one cannot simply "partially remove" the history, or even sign multiple times in parallel (it's a sequential process).

What may happen is that a node may still eventually put two or more signatures, getting some "extra" rewards, and pass undetected, but I don't see this as highly damaging to the network. For me, as long as there are people making some money with the fees, there will popup a lot of new P2P nodes, and eventually, the fees will become very low after splitting, some people would give up... then fees would naturally rise again (or committee could decide to raise fees a little bit, I don't know), but at least there will be another mechanism for incentiving new people to join.

You want to pay for your NEP-5 transfer? You set up a node for quite a few rounds, get a very little gas, then you do your transfer. It's theoretically possible.

P.S.: honestly speaking Erik... in the forseen future, people would use "nodes" that are developed by Core Devs or Communities... this means that, almost everyone would use official C# node, some could use variants of Python and Go nodes, and that's it. People could "hack" it and try to make more profit? Yes, they could. But this requires efforts to change the code, not very hard (at all) to us, but it's also another kind of incentive for people to understand the code and try to make profit with it. More interest in it, better to Neo.

P.S.2: I also think that's it's healthy to the network if there was many "stealth" p2p nodes... nodes that relay, but don't add any new signature. This is specially important to avoid complete tracing of the network (at least, to make it harder...), so these nodes wouldn't provide any "receipt ticket" and could vary their IPs frequently... as long as consensus nodes are not surrounded by Byzantine (stealing signatures) p2p nodes, this should work fine. At the same time, as discussed with YongQiang some time ago, a simple strategy to detect "observer" p2p nodes is to send a tx to them, and then request that tx in the future... if they won't send it to you, you could disconnect, as they aren't willing to help you.

[ediopia]

What if we can tell an address of the node owners in transactions so we can program smart contracts to pay rewards for using the node.

[igormcoelho]

@ediopia this looks like a very good idea... as long as rewards are paid on p2p, node could advertise their own address or any other to receive the fees (even a smart contract one), no need to be the same as local pubkey (it's even safer to NOT be the same...).