|
Title: Should nodes receive part of the transaction fee? Post by: minerva on 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? Title: Re: Should nodes receive part of the transaction fee? Post by: kjj on December 30, 2013, 12:54:02 PM The answer seems to be "no".
Title: Re: Should nodes receive part of the transaction fee? Post by: NewLiberty on December 30, 2013, 02:19:21 PM That would be a different coin.
Title: Re: Should nodes receive part of the transaction fee? Post by: t3a on 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? Title: Re: Should nodes receive part of the transaction fee? Post by: Cryddit on 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. Title: Re: Should nodes receive part of the transaction fee? Post by: empoweoqwj on January 01, 2014, 02:16:17 AM No I don't think so.
Title: Re: Should nodes receive part of the transaction fee? Post by: Altoidnerd on 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. Title: Re: Should nodes receive part of the transaction fee? Post by: t3a on 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. The only person who knows when a transaction is relayed is the ISPs because they are doing the actual relaying. Title: Re: Should nodes receive part of the transaction fee? Post by: dree12 on 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 (https://bitcointalk.org/index.php?topic=51712.0). TL;DR: More research is necessary. Title: Re: Should nodes receive part of the transaction fee? Post by: RoadTrain on 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. Title: Re: Should nodes receive part of the transaction fee? Post by: empoweoqwj on 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? Title: Re: Should nodes receive part of the transaction fee? Post by: Altoidnerd on January 01, 2014, 02:13:41 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. Title: Re: Should nodes receive part of the transaction fee? Post by: Cryddit on 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. Title: Re: Should nodes receive part of the transaction fee? Post by: empoweoqwj on 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. Title: Re: Should nodes receive part of the transaction fee? Post by: RoadTrain on 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. 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. Title: Re: Should nodes receive part of the transaction fee? Post by: NewLiberty on 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) Title: Re: Should nodes receive part of the transaction fee? Post by: Sergio_Demian_Lerner on January 02, 2014, 05:36:51 PM 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. Title: Re: Should nodes receive part of the transaction fee? Post by: minerva on January 03, 2014, 09:19:35 PM http://research.microsoft.com/pubs/156072/bitcoin.pdf
I just want to point this out. Title: Re: Should nodes receive part of the transaction fee? Post by: Altoidnerd on 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. Title: Re: Should nodes receive part of the transaction fee? Post by: empoweoqwj on January 04, 2014, 02:55:10 AM 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 Title: Re: Should nodes receive part of the transaction fee? Post by: Altoidnerd on January 04, 2014, 03:24:31 AM http://research.microsoft.com/pubs/156072/bitcoin.pdf ...Care to summarize?...I just want to point this out. I've summarized it below, partially to help me understand it. From the paper Babaioff, et. al. "On Bitcoin and Red Balloons" http://research.microsoft.com/pubs/156072/bitcoin.pdf Quote abstract + intro Bitcoin relies on a peer-to-peer network...As the protocol ...does not provide an incentive for nodes to broadcast ...Our solution is to augment the protocol...We show that our proposed scheme succeeds ...every change...has to take into account Sybil attacks. simplified model ...we now present our model... ...the network consists of d-ary directed trees of height H ... [there exists] two phases:...a distribution phase and a computation phase... The distribution phase starts when the buyer sends [a tx] to the t roots of the trees which are called seeds... ...information...flows from the root towards the leaves. The depth of a node is the number of nodes on the path from ...[the seed] to the node. Let n = t *[ dH - 1 ] / [d - 1 ] be the total number of nodes... In the computation phase each node ... tries to authorize [the transaction]....[suppose there exists] k such nodes, each [with the] same probability 1/k to be first to authorize... ...k is the number of real nodes...fake identities do not increase the probability [of winning reward]... ...A node v that authorizes the transaction can declare ...[an identity ph]... p1, p2, ..., ph...we call the authorizing chain...ends with ph...starts with p1 [which is] the seed. Each node’s reward is the sum ...of all its identities (true and fake) in the authorizing chain...which we normalize to 1. results A successful reward scheme ... First...[incentivizes] information propagation...to all [said node's] children without duplicating itself ... Second..[makes...] most of the nodes..aware of the transaction..with small rewards..minimizing the number of seeds..to ease.. distribution. ...obviously not a trivial task...[because of] Sybil proofness requirement... The current literature on the Sybil...contains negative results..[because of the assumption that] Sybils will never be profitable. In contrast, we...take an alternative path... guarantee these properties in equilibrium. Suppose ... [there exists a] family of schemes ... almost uniform schemes... Each scheme ... [has associated parameters] height ℋ and reward β ... [and] v [is the] lth node in the chain ..authorized [the tx] If l > ℋ no reward is given... [else] ...each node ..gets reward β ...except node v gets reward 1 + (ℋ - l + 1)β ... ...two values of β...are of particular interest...if β = 1 [then for any ℋ] ... t [can be a constant]...in the scheme (1, ℋ)...total payments [is O(ℋ) ] ... ...if β == 1/ℋ ... [then the scheme] (1/ℋ, ℋ) works if the number of seeds t is Ω(ℋ)...its total payment is 2... ...we combine both [in the hybrid scheme]...using (1, 1+ logd H)...then at least H are aware of the transaction...At the end of the distribution phase, most of the nodes... receive a reward of 1/H... Theorem: In the hybrid rewarding scheme, if the number of seeds t >= 14, the only strategies that always survive iterated elimination of dominated strategies exhibit information propagation and no duplication. In addition, there exists an elimination order in which the only strategies that survive exhibit information propagation and no duplication. Furthermore, the expected total sum of payments is at most 3. Theorem: Suppose that H >= 3. There is no Sybil-proof reward scheme in which information propagation and no duplication are dominant strategy for all nodes at depth 3 or less. ...Our main result is the Hybrid scheme, a reward scheme that requires only a constant number of seeds and a constant overhead.... ...The intuition.. is that decreasing competition by your own descendants might be unprofitable due to possibly losing rewards for relaying, in case one of these descendants authorizes...To see this, consider... a seed. Suppose...that all of its descendants always propagate information... and never duplicate... If the seed does not clone itself then each one of its children spans a d-array tree of height ℋ-1. If it clones itself once, then each one of its children spans a d-array tree of smaller height of ℋ-2, and the number of descendants of the node that receive the information decreases by almost factor d. |