Is the network in trouble somehow? Why the need to reward people for "relaying nodes"?
+1 
Topic: How can relay nodes be rewarded? (Read 4377 times)
People used to donate to p2pool miners
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.
+1
This also doesn't require any core protocol changes (hard forks).
Proof of Stake doesn't guarantee that you're relaying others transactions.
Also, with ppcoin, I think it works based on interest.
You connect and get x% interest per year on any coins. The more coins the higher your odds, but if you don't get paid the interest, you can get it paid the next time you login.
The benefit of being online all the time is compounding of the interest.
BTW Proof of stake also discourages spending, which is...not sure.
To the OP: perhaps full nodes can be rewarded through an https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts
Proof of Stake doesn't guarantee that you're relaying others transactions.
Also, with ppcoin, I think it works based on interest.
You connect and get x% interest per year on any coins. The more coins the higher your odds, but if you don't get paid the interest, you can get it paid the next time you login.
The benefit of being online all the time is compounding of the interest.
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.
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.)
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.
If a node verified a fraction of transactions, then each node could contribute a little.
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.
This is badly needed.
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.
Rewarding people for relaying nodes does not solve a specific problem. Therefore ..... we don't need it.
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.
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.
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. :/
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. :/
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://bitcointalksearch.org/topic/increasing-anonymity-in-bitcoin-possible-alternative-to-zerocoin-290971.
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.
The most technically interesting tool for compensating transaction relayers that I've seen is https://bitcointalksearch.org/topic/increasing-anonymity-in-bitcoin-possible-alternative-to-zerocoin-290971.
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.
Is the network in trouble somehow? Why the need to reward people for "relaying nodes"?
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.
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?
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 ]. 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.
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
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.
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.
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.
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 blockThe 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.
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?
Jump to: