How can relay nodes be rewarded?

[Metus]

Miners are rewarded for doing proof of work in the form of transaction fees and mining rewards. But relaying nodes perform important work too as they independently verify the veracity of blocks and propagate them to all participants, especially thin clients that do not propagate a full copy of the block chain. So how can relay nodes be rewarded?

[1715346461]

1715346461

[1715346461]

1715346461

[t3a]

Miners are rewarded for doing proof of work in the form of transaction fees and mining rewards. But relaying nodes perform important work too as they independently verify the veracity of blocks and propagate them to all participants, especially thin clients that do not propagate a full copy of the block chain. So how can relay nodes be rewarded?

I don't think they can. How can you prove that you relayed to other nodes?

The only person who knows that you are relaying is your peers, so in any system rewarding the relayers for relaying, it has to be based on your peers vouching that you are relaying. I don't see how you could have a system like that without a malicious user pretending to be 1000000 nodes and telling the network that they are all relaying to each other.

[justusranvier]

Suppose the transaction fee is split into two fees: one for the miner, and one for a node that relays it to a miner.

The person who creates a transaction would need a method to sign an input that anybody could claim, but in a way that it's only valid if their transaction makes it into a block.

[Qoheleth]

Suppose the transaction fee is split into two fees: one for the miner, and one for a node that relays it to a miner.

The person who creates a transaction would need a method to sign an input that anybody could claim, but in a way that it's only valid if their transaction makes it into a block.

So here's a proposal: let's say you implement one of the recent suggestions, and make an altcoin which uses SNARKs as its transaction validation method. Instead of a block containing inputs, signatures, and outputs, it contains inputs, outputs, and a SNARK that proves that all inputs have been properly signed to some output in the block.

Now, you've got gossips which pass the transaction from the person who originally signed it. With this kind of proof system, it's easy enough to aggregate transactions into a larger transaction, and include as its proof - once again - that all the outputs required by the inputs are being paid. Then, it'd be easy enough for such relays to add their own outputs to the merged transaction (so long as those new outputs don't make output>input). The mining case, then, becomes merely a specific case of this general one - the miner joins the transactions with the coinbase into a final "mining transaction", and pockets all unaccounted-for fees. Miners can't steal relay money because they can't necessarily see the original transaction; all they have is the SNARK-blinded transactions sent by their peers. Unless, of course, they're getting the transactions directly from the users, in which case they're the ones paying for the bandwidth so them getting the reward fee is fine.

[empoweoqwj]

Miners are rewarded for doing proof of work in the form of transaction fees and mining rewards. But relaying nodes perform important work too as they independently verify the veracity of blocks and propagate them to all participants, especially thin clients that do not propagate a full copy of the block chain. So how can relay nodes be rewarded?

Even if feasible, I'm not sure its a good idea. There is hardly any money in transaction fees at the moment. Any reward for being a relay node would be so tiny it wouldn't even register.

Don't miners themselves do the work you refer to?

[Metus]

Suppose the transaction fee is split into two fees: one for the miner, and one for a node that relays it to a miner.

The person who creates a transaction would need a method to sign an input that anybody could claim, but in a way that it's only valid if their transaction makes it into a block.

So here's a proposal: let's say you implement one of the recent suggestions, and make an altcoin which uses SNARKs as its transaction validation method. Instead of a block containing inputs, signatures, and outputs, it contains inputs, outputs, and a SNARK that proves that all inputs have been properly signed to some output in the block

Can you give a link to these SNARK proposals? This sounds interesting as a solution to incentivising people to relay transactions. Can this concept be expanded to incentivise people to validate and relay complete blocks and to store and distribute full or pruned copies of the blockchain?

[Sergio_Demian_Lerner]

Here is an idea that can reward transaction forwarders as long as the block reward exists:

A transaction can be stored in a Packet. Packets travel the network are are included in blocks (as transactions).


A packet contains:

- A transaction or another packet.
- The hash of a ECDSA pubkey (20 bytes)
- A nonce (4 bytes)


The PoW of a packet is computed as Hash ( Hash(Tx) || key || nonce)
When a node receives a packet or a transaction he decides to store it in another packet or forward it as is.
If he decides to re-packet it, the node tries many nonces until a certain PoW is found.

If a packet is received in a block, money is minted specifically to pay for the PoW of the packets (the reward is NOT taken from the fees nor from the block reward).
Suppose that the packet PoW is P, the difficulty of the block is D, and the block reward is R. When a nodes receives a packet in a block,  it creates a "packet coinbase transaction" that pays P*R*C/D  coins to the key specified in the packet (is multiple packets surround a transaction, each key is paid independently), where D is a constant < 1 such as 0.1. Also if a block contains N packets, and the block size is B, then the miner of the block receives an additional reward of N*24*R*D/B, which compensates the miner of the additional space used for the packet overhead.   

Setting D = 0.1 means that nodes are paid much less (10%) of what miners are being paid, which means that the incentive for mining is greater than the incentive for packet forwarding.

So nodes will try to make a rational decision regarding re-packeting a tx considering the hop distance to the miner, the packet size, the reward and the available computing resources. Also they cannot hold the tx for too much time, since the same tx may arrive to the miner from another path and make the node waste the invested packet PoW. Also miners have no incentive to exclude the packets, because they earn an extra reward on packet headers. So as long as there is a block reward, there will be an equilibrium where nodes delay transactions a few milliseconds to collect micro-payments for packet forwarding.

Knowing the current cost of SHA-256 mining vs scrypt mining (with high memory requirements), the network could set a different PoW algorithm for forwarding (such as scrypt) and still assure that the incentive for mining is always much higher than the incentive for adding packet PoWs.


In the next post I propose another way to solve if there is no block reward.
 

[Sergio_Demian_Lerner]

In a state of the system where the block reward has reached zero, the following protocol can work:

As in the previous other proposal each node adds something to the transaction. In this proposal, each transaction is stored in a Paycket.

A Paycket consist of :

- A transaction (Tx)
- A list of payment addresses (PayList) corresponding to the nodes that forwarded the transaction from the source to the destination.

Nodes only append the 20-byte hash of the pubkey to the PayList.
Each node is connected to N peers. For each peer the node maintains a data structure SendTo[N] which is a priority queue of the IPs (or node IDs) where a paycket origination from N should be sent, and in which priority order

When a node receives a paycket, is responds to the sending node with a new pubkeyhash created for that paycket.

When a node forwards a Paycket, it records the IP address (or ID) of the node that sent the paycket and the pubkeyhashes of the nodes where the paycket was forwarded, in SentFromTo[TxHash] --> [From, Map<node_id,pubkeyhash> ]. It also appends his own new address (the one sent back to the sender) into the PayList.


When a node receives a block, it checks each transaction to see it corresponds to any of the transaction in SentFromTo[]. If it does, it checks if his pubkey is in PayList field of the paycket. If it does, then it increases the priority in SendTo[From] to the node_id corresponding to the pubkeyhash that followed himself in the list.
If his pubkeyhash is NOT in the PayList, then it decreases the priority of all nodes in SendTo[From] for which the paycket was actually sent. A node with a priority below a certain threshold do not receive any more transaction from that peer. If the priority reaches another low threshold, they can be directly disconnected.

If the address that follows the node is not in the PayList, it means that the node that received the paycket lied about its address, or any other node following that node (including the miner). The best he can do is decrease the priority of that node, as being less trusted.
 
The addresses in the PayList share a percentage of the transaction fee (e.g. 10%)

After some time, the network will organize itself as a tree with some redundant branches, but where all paths are near optimal paths to the miners.
Also if a miner erases addresses from the PayList to receive a greater share of the fees, nodes will slowly begin to stop forwarding the transactions to that miner (a monetary punishment). Miners that never include addresses in their paylists will be completely banned from the network.

Any new node that tries to connect to the network will start with a low priority, so transactions will not be forwarded to the new node (but blocks will always be).

Note that a similar priority data structure can be used in the other direction to optimally send blocks from one miner to the other and reduce block propagation time. These both ideas are currently under test in the QixCoin alt-coin.

Regards, Sergio.

[t3a]

Here is an idea that can reward transaction forwarders as long as the block reward exists:

A transaction can be stored in a Packet. Packets travel the network are are included in blocks (as transactions).


A packet contains:

- A transaction or another packet.
- The hash of a ECDSA pubkey (20 bytes)
- A nonce (4 bytes)


The PoW of a packet is computed as Hash ( Hash(Tx) || key || nonce)
When a node receives a packet or a transaction he decides to store it in another packet or forward it as is.
If he decides to re-packet it, the node tries many nonces until a certain PoW is found.

If a packet is received in a block, money is minted specifically to pay for the PoW of the packets (the reward is NOT taken from the fees nor from the block reward).
Suppose that the packet PoW is P, the difficulty of the block is D, and the block reward is R. When a nodes receives a packet in a block,  it creates a "packet coinbase transaction" that pays P*R*C/D  coins to the key specified in the packet (is multiple packets surround a transaction, each key is paid independently), where D is a constant < 1 such as 0.1. Also if a block contains N packets, and the block size is B, then the miner of the block receives an additional reward of N*24*R*D/B, which compensates the miner of the additional space used for the packet overhead.   

Setting D = 0.1 means that nodes are paid much less (10%) of what miners are being paid, which means that the incentive for mining is greater than the incentive for packet forwarding.

So nodes will try to make a rational decision regarding re-packeting a tx considering the hop distance to the miner, the packet size, the reward and the available computing resources. Also they cannot hold the tx for too much time, since the same tx may arrive to the miner from another path and make the node waste the invested packet PoW. Also miners have no incentive to exclude the packets, because they earn an extra reward on packet headers. So as long as there is a block reward, there will be an equilibrium where nodes delay transactions a few milliseconds to collect micro-payments for packet forwarding.

Knowing the current cost of SHA-256 mining vs scrypt mining (with high memory requirements), the network could set a different PoW algorithm for forwarding (such as scrypt) and still assure that the incentive for mining is always much higher than the incentive for adding packet PoWs.


In the next post I propose another way to solve if there is no block reward.
 

Would this not result in people "mining" for packets?

[empoweoqwj]

Is the network in trouble somehow? Why the need to reward people for "relaying nodes"?

[gmaxwell]

Stuff in this space has been proposed many times before, but inevitably the proposals end up drastically increasing the size of transactions (and thus the blockchain).

The most technically interesting tool for compensating transaction relayers that I've seen is https://bitcointalk.org/index.php?topic=290971.0.

But I don't know that any such scheme would be interesting, at it would just encourage miners to run huge numbers of sybil ingress nodes.

[xZork]

While I know little to nothing (more on the nothing side) it would only slow down the network. There is already debate about increasing the block size due to transaction speed and volume, as I understand. Having a battle over which node handled it wouldn't help. If you are running a node, check your IP on blockchain and get a warm comfy feeling.

I'm not 100% on this, but you could check your peers also.

Code:

http://getaddr.bitnodes.io/

I have had well over 1000 peers. yay, no BTC required. You don't need to get paid for something you believe in.


I need another beer. :/

[Mike Hearn]

You can build micropayment channels to a set of nodes you selected randomly when your wallet first initialised, and which other nodes hint have good uptime. You then make micropayments for services rendered: most obviously, blocks served. This does not require any complicated cryptography.

[empoweoqwj]

Rewarding people for relaying nodes does not solve a specific problem. Therefore ..... we don't need it.

[empoweoqwj]

Rewarding people for relaying nodes does not solve a specific problem. Therefore ..... we don't need it.

But in the future, people running full nodes will be a thing of only a few will be able to do. Already many people purchase VPS just to run a full node so they know they can connect their SPV AKA light clients to and know they can trust it. Those cost money, and those people should be rewarded for it. So thinking about it now yes doesn't make sense but in the future it does and to solve this now would benefit us. Remember they either have to have better pruning for the blockchain which is not an easy task or many central points like electrum servers. You have to pick one for the future as we grow, this is the pros and cons of going bigger and a bitcoins being worth ~$700.

OK, thanks for the insight. Sure there must be a better way than paying people to relay nodes though. Bitcoin needs to be as frictionless as possible to succeed mainstream.

[bitpop]

This is badly needed.

[empoweoqwj]

But aren't there more and more people running bitcoin-qt every week, even with the ever increasing blockchain size? Doesn't sound like people need rewarding at the moment.

[TierNolan]

Distributed verification would help here.  If running a node requires a 100GB virtual host, then fewer people would be willing to do it.

If a node verified a fraction of transactions, then each node could contribute a little.

[Dabs]

This reminds me of Proof of Stake. However bitcoin does not support it. I've only seen it on a few alt-coins. Proof of Stake encourages regular people to keep an open wallet (a full node that relays transactions.)

[t3a]

This reminds me of Proof of Stake. However bitcoin does not support it. I've only seen it on a few alt-coins. Proof of Stake encourages regular people to keep an open wallet (a full node that relays transactions.)

Proof of Stake doesn't guarantee that you're relaying others transactions.