minerva (OP)
|
|
December 30, 2013, 12:46:49 PM |
|
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?
|
Tip-Jar: 15NN2YwMGAntKopJgAsFBJvfuCARkV62xo
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1025
|
|
December 30, 2013, 12:54:02 PM |
|
The answer seems to be "no".
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
NewLiberty
Legendary
Offline
Activity: 1204
Merit: 1002
Gresham's Lawyer
|
|
December 30, 2013, 02:19:21 PM |
|
That would be a different coin.
|
|
|
|
t3a
|
|
December 30, 2013, 02:33:05 PM |
|
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?
|
Advertise here for 10btc/day
|
|
|
Cryddit
Legendary
Offline
Activity: 924
Merit: 1129
|
|
December 31, 2013, 03:28:14 PM |
|
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
|
|
January 01, 2014, 02:16:17 AM |
|
No I don't think so.
|
|
|
|
Altoidnerd
|
|
January 01, 2014, 03:07:43 AM |
|
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
|
|
January 01, 2014, 03:27:13 AM |
|
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.
|
Advertise here for 10btc/day
|
|
|
dree12
Legendary
Offline
Activity: 1246
Merit: 1077
|
|
January 01, 2014, 03:29:53 AM |
|
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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
January 01, 2014, 09:56:58 AM |
|
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
|
|
January 01, 2014, 10:58:35 AM |
|
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
|
|
January 01, 2014, 02:13:41 PM Last edit: January 01, 2014, 02:44:04 PM by 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
Legendary
Offline
Activity: 924
Merit: 1129
|
|
January 01, 2014, 06:00:44 PM |
|
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
|
|
January 02, 2014, 02:25:58 AM |
|
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
Legendary
Offline
Activity: 1386
Merit: 1009
|
|
January 02, 2014, 12:38:51 PM |
|
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
Legendary
Offline
Activity: 1204
Merit: 1002
Gresham's Lawyer
|
|
January 02, 2014, 12:48:42 PM |
|
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)
|
|
|
|
|
minerva (OP)
|
|
January 03, 2014, 09:19:35 PM |
|
|
Tip-Jar: 15NN2YwMGAntKopJgAsFBJvfuCARkV62xo
|
|
|
Altoidnerd
|
|
January 03, 2014, 11:06:12 PM |
|
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
|
|
January 04, 2014, 02:55:10 AM |
|
Is it relevant to this thread? Care to summarize? I would download and read myself but tend to hate all things Micro$oft
|
|
|
|
|