Should nodes receive part of the transaction fee?

[minerva]

Without nodes providing bandwidth and a modicum of CPU power, the Bitcoin network would be nothing.

Should nodes receive a fraction of the transaction fee?

[1714051895]

1714051895

[1714051895]

1714051895

[1714051895]

1714051895

[1714051895]

1714051895

[kjj]

The answer seems to be "no".

[NewLiberty]

That would be a different coin.

[t3a]

Can nodes receive part of the transaction fee?

You can prove that you found a hash below a certain value. Can you prove you relayed a transaction to your peers?

[Cryddit]

I'm of the opinion that the answer should be yes.  But "should" does not affect the reality.  In Bitcoin, they do not.

Also, it isn't clear how to demonstrate the degree to which a client is being useful. 

If you pay them for propagating transactions, then people will make fake (or meaningless) transactions to propagate, and your altcoin melts under a Sibyl attack.  If you pay them for propagating blocks (which seems possible) then the block propagation has to be reported somehow.  Someone pretends he's a thousand nodes, all propagating every block to each other by every possible path, in order to maximize his reward, and then the claims on the award require more bandwidth than there is in the next block.  Lose again.

 

[empoweoqwj]

No I don't think so.

[Altoidnerd]

Can you prove you relayed a transaction to your peers?

Heroes, is there a fundamental reason this is not possible?  Is it theoretically possible to track relays if someone wrote the feature into their wallet program? 

Then the relay#'s themselves could be redeemed...and it sounds like a new coin doesn't it.

[t3a]

Can you prove you relayed a transaction to your peers?

Heroes, is there a fundamental reason this is not possible?  Is it theoretically possible to track relays if someone wrote the feature into their wallet program? 

Then the relay#'s themselves could be redeemed...and it sounds like a new coin doesn't it.

As the others have mentioned, one could simply make 10,000 imaginary nodes that all say they are relaying with each other, when in reality they aren't.

The only person who knows when a transaction is relayed is the ISPs because they are doing the actual relaying.

[dree12]

It's possible and seems to be a good idea, but more research is needed before it is confirmed to be safe from exploits.

See this thread.

TL;DR: More research is necessary.

[RoadTrain]

Well I personally don't think it's needed.
Every holder has an incentive to keep the network operating well, thus to run a full node.

IMO the more important goal is to make running a full node as easy as possible.

[empoweoqwj]

Well I personally don't think it's needed.
Every holder has an incentive to keep the network operating well, thus to run a full node.

IMO the more important goal is to make running a full node as easy as possible.

I agree the more important goal is to make running a full node as easy as possible. How to do that with the increase in blockchain size?

[Altoidnerd]

Every holder has an incentive to keep the network operating well, thus to run a full node.

Just like your roomates in college all had an incentive to do the dishes.  Homo sapiens' performance falls off steeply when gratification is indirect or delayed.

I agree the more important goal is to make running a full node as easy as possible...

mmhmmm, either easier or otherwise more enjoyable for one reason or another.  I run full nodes because of their performance and thus for selfish reasons. You could do a poll, but this is psychology 101... nobody cares about the network.

Interest groups will pop up and pay for it if they need to.  The foundation can send out a DVD of the blockchain that comes with free season 97-99 of south park.

[Cryddit]

I would truly like for there to be a way to do this, but Sibyl attacks are tricky to design around.  If you reward the last few nodes before the miner, then the miner has an incentive to put up a bunch of fake clients to "relay" it the last few steps before he gets it.  If you reward the first few nodes following the transaction origin then the transaction originator has an incentive to put up a bunch of fake clients to "relay" it the first few steps from them.

To minimize the Sibyl vulnerability you need to promote minimum-length propagation paths, so the "time to live" or "hop limit" *is* a relevant response.  With a "time to live" limited by the network the transaction originator doesn't reach as many potential miners if they consume the first bounce with a Sibyl node, so they have a disincentive to do that. 

But if a miner gets a tx with a "hop limit" of four, on the first or second bounce, there is an incentive for the miner to put up sibyl nodes to relay it the last two or three nodes to the miner.  And if a transaction originator knows she's directly connected to several of the leading centers of mining power (pool centers or ASIC farms that will probably make at least one of the next ten blocks), or even directly connected to blocks that are directly connected to centers of mining power, then she has an incentive to put up a few fake  nodes to "relay" it from her to the miners. 

So you need to create a disincentive for the miner to make sibyl nodes.  This could happen if the size of the transaction increases with each bounce (which a lot of these schemes will have happening anyway) and the miner is paid proportional to the *efficiency* (in tx per Mbyte) of his blocks.  With more incentive to keep the transactions short than incentive to add sibyl nodes, the miner wouldn't be putting up fake nodes in order to maximize profits. 

This also provides a disincentive for relay nodes to create Sibyl attacks.  If a relay node knows that the miner will only be putting tx with the shortest paths into the block, then they have a disincentive to lengthen the path, because if they do and the miner then gets the tx from elsewhere with a shorter path, the relay node that put up a sibyl loses. 

What it does not prevent is collusion attacks.  The miner will likely get a transaction hundreds of times before forming a block.  Of those, dozens may travel through a selected node that's directly connected to the miner. If such a relay node and a miner collude, then the miner can, in exchange for a kickback, prefer paths that run through that relay node - unfairly reducing the chance of reward for all non-colluding nodes.

And, finally, it creates a very complicated set of payments, which must be subject to more complicated feedback, which must in turn be fixed so there are disincentives to game the feedback mechanism.  To accomplish this in a way that's stable across diminishing block rewards, or even produces predictably sized aggregate block rewards, is nontrivial.   And it also adds the number of bounces to the signature checks that must be performed when checking transactions, and to the size of the blockchain, increasing the compute and bandwidth burden on all nodes.

[empoweoqwj]

I would truly like for there to be a way to do this, but Sibyl attacks are tricky to design around.  If you reward the last few nodes before the miner, then the miner has an incentive to put up a bunch of fake clients to "relay" it the last few steps before he gets it.  If you reward the first few nodes following the transaction origin then the transaction originator has an incentive to put up a bunch of fake clients to "relay" it the first few steps from them.

To minimize the Sibyl vulnerability you need to promote minimum-length propagation paths, so the "time to live" or "hop limit" *is* a relevant response.  With a "time to live" limited by the network the transaction originator doesn't reach as many potential miners if they consume the first bounce with a Sibyl node, so they have a disincentive to do that. 

But if a miner gets a tx with a "hop limit" of four, on the first or second bounce, there is an incentive for the miner to put up sibyl nodes to relay it the last two or three nodes to the miner.  And if a transaction originator knows she's directly connected to several of the leading centers of mining power (pool centers or ASIC farms that will probably make at least one of the next ten blocks), or even directly connected to blocks that are directly connected to centers of mining power, then she has an incentive to put up a few fake  nodes to "relay" it from her to the miners. 

So you need to create a disincentive for the miner to make sibyl nodes.  This could happen if the size of the transaction increases with each bounce (which a lot of these schemes will have happening anyway) and the miner is paid proportional to the *efficiency* (in tx per Mbyte) of his blocks.  With more incentive to keep the transactions short than incentive to add sibyl nodes, the miner wouldn't be putting up fake nodes in order to maximize profits. 

This also provides a disincentive for relay nodes to create Sibyl attacks.  If a relay node knows that the miner will only be putting tx with the shortest paths into the block, then they have a disincentive to lengthen the path, because if they do and the miner then gets the tx from elsewhere with a shorter path, the relay node that put up a sibyl loses. 

What it does not prevent is collusion attacks.  The miner will likely get a transaction hundreds of times before forming a block.  Of those, dozens may travel through a selected node that's directly connected to the miner. If such a relay node and a miner collude, then the miner can, in exchange for a kickback, prefer paths that run through that relay node - unfairly reducing the chance of reward for all non-colluding nodes.

And, finally, it creates a very complicated set of payments, which must be subject to more complicated feedback, which must in turn be fixed so there are disincentives to game the feedback mechanism.  To accomplish this in a way that's stable across diminishing block rewards, or even produces predictably sized aggregate block rewards, is nontrivial.   And it also adds the number of bounces to the signature checks that must be performed when checking transactions, and to the size of the blockchain, increasing the compute and bandwidth burden on all nodes.

To summarize, attempting to reward relays adds a layer of complexity to the network which IMHO, we really don't need. We need to solve the issue other ways.

[RoadTrain]

Every holder has an incentive to keep the network operating well, thus to run a full node.

Just like your roomates in college all had an incentive to do the dishes.  Homo sapiens' performance falls off steeply when gratification is indirect or delayed.

I agree the more important goal is to make running a full node as easy as possible...

mmhmmm, either easier or otherwise more enjoyable for one reason or another.  I run full nodes because of their performance and thus for selfish reasons. You could do a poll, but this is psychology 101... nobody cares about the network.

Interest groups will pop up and pay for it if they need to.  The foundation can send out a DVD of the blockchain that comes with free season 97-99 of south park.

Dunno what you're talking about. Large holders and bussiness operators will run full nodes because of even indirect but significant incentives.
Not everyone is that short-sighted. And the network doesn't require that everybody with a penny runs a node.
Adding complexity to the network is not a wise approach to increase participation.

As I said, the same goal can be reached after we solve 'blockchain problem'. So when core dev team implements UTXO checkpoints or similar compression ideas, the reference client will be much lighter, closer to Multibit, while still being a fully functional node.

[NewLiberty]

Well I personally don't think it's needed.
Every holder has an incentive to keep the network operating well, thus to run a full node.

IMO the more important goal is to make running a full node as easy as possible.

Yes, and

We need to solve the issue other ways.

Adding monetary benefits is not needed if the costs are low enough and use easy enough.  There are other intrinsic benefits beyond monetary. (such as just wanting the block chain data on hand)

[Sergio_Demian_Lerner]

I proposed two protocols that work, without any theoretical problem, and with very little overhead.


https://bitcointalk.org/index.php?topic=385528.msg4155300#msg4155300
https://bitcointalk.org/index.php?topic=385528.msg4154714#msg4154714

In fact the paycket method could be implemented without any type of fork, if miners add after each transaction another transaction that pays to the PayList pubkeys. But the overhead in txs may be 30%


Nevertheless, I'm unsure if they would ever be needed.

Sergio.

[minerva]

http://research.microsoft.com/pubs/156072/bitcoin.pdf
I just want to point this out.

[Altoidnerd]

Interest groups will pop up and pay for it if they need to...

...Large holders and bussiness operators will run full nodes...

I don't think we disagree in principle, if you isolate these two remarks at the core of our thinking.

[empoweoqwj]

http://research.microsoft.com/pubs/156072/bitcoin.pdf
I just want to point this out.

Is it relevant to this thread? Care to summarize?

I would download and read myself but tend to hate all things Micro$oft