ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
June 04, 2014, 05:33:09 PM |
|
Its like this, you can always get a single individual/group to set up up multiple pools in PoW/PoS, or multiple delegates in DPoS and grab more share than what it seems. But the hard cap means that it is more complex to get the same control.
Say, Ghash sets up another couple of pools anonymously (or maybe even does), or makes buddies with a couple of other big pools, then it already has control. In DPoS on the other hand, he/she/they have to go through a lot more trouble (some 50 delegates in case of BTSX) to get the same control.
Besides, say, a pool offers incentives, then everybody will naturally flock to it. Sure, at some they might start getting worried and not go, but as we have seen in the Ghash case, appealing to the better sense of the mining equipment owners doesn't work to well. They might not even be too worried about the long term health as they might be just looking at it as a business. In DPoS, the hard cap means such a scenario is not possible, and you have to also keep in mind that the users of the coin are the ones who are voting.
I think I see which direction you are coming from. But I do not clearly see how a hard-cap is going to solve the problem of a second pool under control of the very same real-world entity. "A lot more trouble" Why? Are existing pools preferred before new ones?
|
|
|
|
clout (OP)
|
|
June 04, 2014, 07:00:03 PM |
|
how could that be a problem. proof of work can be considered a proof of stake system in that you are proving your stake in the collective hashing power of the network. The value comes from the stake not from the cost of proving that you have stake. Thus, the reduced cost of pos mining is not a problem but a solution.
If you don't understand the "nothing at stake problem" aka "very little at stake problem" go back and read this: https://bitcointalk.org/index.php?topic=584703.msg6982574#msg6982574This attack does not apply to DPOS... Oh ok I understand this attack better now. Two questions then:
It seems like this affects NXT but not DPOS, because with DPOS once you miss a chance to produce a block it is gone forever - you cannot use old stake-votes to produce a longer chain if at least 51% of delegates have produced a block since then. Is this right? Also, NXT claims that having clients reject chains built on anything but the most recent block they have seen solves not only this but 51%... this is true in theory but relies on unreasonable network connectivity assumptions. Is this right?
|
|
|
|
toast
|
|
June 04, 2014, 08:32:29 PM |
|
This attack does not apply to DPOS... Oh ok I understand this attack better now. Two questions then:
It seems like this affects NXT but not DPOS, because with DPOS once you miss a chance to produce a block it is gone forever - you cannot use old stake-votes to produce a longer chain if at least 51% of delegates have produced a block since then. Is this right? Also, NXT claims that having clients reject chains built on anything but the most recent block they have seen solves not only this but 51%... this is true in theory but relies on unreasonable network connectivity assumptions. Is this right?
I was asking, not telling. It seems to me like it doesn't apply, but I'd like D&T or other anti-POS pros to explain if I'm wrong.
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
June 04, 2014, 09:21:43 PM |
|
I still do not get the difference between TF and DPoS. They seem equivalent to me. Just newspeak so to say.
|
|
|
|
toast
|
|
June 05, 2014, 12:40:54 AM |
|
I still do not get the difference between TF and DPoS. They seem equivalent to me. Just newspeak so to say.
Very similar. DPoS lets you vote against delegates, has a cap per delegate, and and delegate order is determined once per round rather than after every block (you can't try to pick a "good" block to get you more than N blocks in a row if you don't own more than N delegates)
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
|
June 05, 2014, 03:18:37 AM |
|
This attack does not apply to DPOS... Oh ok I understand this attack better now. Two questions then:
It seems like this affects NXT but not DPOS, because with DPOS once you miss a chance to produce a block it is gone forever - you cannot use old stake-votes to produce a longer chain if at least 51% of delegates have produced a block since then. Is this right? Also, NXT claims that having clients reject chains built on anything but the most recent block they have seen solves not only this but 51%... this is true in theory but relies on unreasonable network connectivity assumptions. Is this right?
I was asking, not telling. It seems to me like it doesn't apply, but I'd like D&T or other anti-POS pros to explain if I'm wrong. Not a pro (and not anti pos necessarily) but I will say this: the extent you rely on delegation/supernodes as a security mechanism is also the extent you dilute the trustless nature of the system and erode true distributed consensus. So depending on the implementation there will be trade offs. You could obviously eliminate the n.a.s. Problem with a central authority but that puts us back at square one. If the dpos uses an automated mechanism to resolve conflicts, then it probably can be attacked by false chains in a similar fashion to the other poS systems.
|
|
|
|
sunny2013
Newbie
Offline
Activity: 6
Merit: 0
|
|
June 05, 2014, 03:40:01 AM |
|
Peercoin
|
|
|
|
toast
|
|
June 05, 2014, 03:57:48 AM |
|
This attack does not apply to DPOS... Oh ok I understand this attack better now. Two questions then:
It seems like this affects NXT but not DPOS, because with DPOS once you miss a chance to produce a block it is gone forever - you cannot use old stake-votes to produce a longer chain if at least 51% of delegates have produced a block since then. Is this right? Also, NXT claims that having clients reject chains built on anything but the most recent block they have seen solves not only this but 51%... this is true in theory but relies on unreasonable network connectivity assumptions. Is this right?
I was asking, not telling. It seems to me like it doesn't apply, but I'd like D&T or other anti-POS pros to explain if I'm wrong. Not a pro (and not anti pos necessarily) but I will say this: the extent you rely on delegation/supernodes as a security mechanism is also the extent you dilute the trustless nature of the system and erode true distributed consensus. Sure, but isn't it an improvement over bitcoin which effectively has delegated-proof-of-work with about 5 delegates selecting blocks on behalf of >80% of hash power? So depending on the implementation there will be trade offs. You could obviously eliminate the n.a.s. Problem with a central authority but that puts us back at square one. If the dpos uses an automated mechanism to resolve conflicts, then it probably can be attacked by false chains in a similar fashion to the other poS systems.
The fork resolution is automatic and is just determined by which chain has more stake-vote counted by delegate signatures. Your next point is exactly what I'm asking - how would an attacker make a false chain using old keys with stake in them, if they cannot ever generate a sequence of delegates where they have more than N delegates in a row? Each round of delegate signatures is done without shuffling in between - if you only have 40% of the stake at any given time you cannot generate a round (~1 hour) where you have more than 40% of the delegates. Once an hour has passed, how would you make a false chain?
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
|
June 05, 2014, 05:08:05 AM |
|
Again, disclaimer: I'm not an expert.
I would dare to say no, it's not an improvement over Bitcoin. With bitcoin's poW, mining pools don't have any special powers that solo miners don't also have. So while the hashing power is "pooled", consensus isn't really "delegated" beyond the same protocol rules that affect everyone.
If you are talking about supernodes solving the nothing at stake problem because they can check signatures in real time, that is definitely taking a step toward trusted authorities. In contrast, proof of work acts as it's own timestamp.
|
|
|
|
toast
|
|
June 05, 2014, 02:17:27 PM |
|
Again, disclaimer: I'm not an expert.
I would dare to say no, it's not an improvement over Bitcoin. With bitcoin's poW, mining pools don't have any special powers that solo miners don't also have. So while the hashing power is "pooled", consensus isn't really "delegated" beyond the same protocol rules that affect everyone.
If you are talking about supernodes solving the nothing at stake problem because they can check signatures in real time, that is definitely taking a step toward trusted authorities. In contrast, proof of work acts as it's own timestamp.
Bolded part is what I believe to be a major misconception. What powers do delegates have that mining pools don't? I even advocated to call them "signing pools" because they play the same role. All they can do is exclude transactions. (I'll tell you one: they have the ability to vote on "alerts"... but bitcoin's alert system is far more centralized )
|
|
|
|
clout (OP)
|
|
June 05, 2014, 02:20:21 PM |
|
Again, disclaimer: I'm not an expert.
I would dare to say no, it's not an improvement over Bitcoin. With bitcoin's poW, mining pools don't have any special powers that solo miners don't also have. So while the hashing power is "pooled", consensus isn't really "delegated" beyond the same protocol rules that affect everyone.
If you are talking about supernodes solving the nothing at stake problem because they can check signatures in real time, that is definitely taking a step toward trusted authorities. In contrast, proof of work acts as it's own timestamp.
How does a mining pool not have power that solo miners do not? A mining pool can produce more blocks than a single miner... I'm absolutely fascinated by your insistence that bitcoin is trustless network. There is no such thing a trustless transaction. You can create an environment that incentivizes a desired outcome. But at the end of the day all of these systems rely on people. Bitcoin is less of mathematical experiment as much as sociological one. We know that public key cryptography works, but what we do not know is whether or not individuals can trust no one while simultaneously trusting everyone. But this is the nature of economics and think it has been empirically proven that I do not have to trust an individual I transact with but rather I can trust society as a whole. I'm not an expert either but I feel that your analysis of bitcoin and related systems lacks understanding of organizational theory. All organization whether virtual or not face the same fundamental constraints and the delegation of power is necessary for scalability.
|
|
|
|
play4ce
Newbie
Offline
Activity: 33
Merit: 0
|
|
June 05, 2014, 02:45:41 PM |
|
NEM, beacuse its Proof of Importance
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
June 05, 2014, 02:54:31 PM |
|
All organization whether virtual or not face the same fundamental constraints and the delegation of power is necessary for scalability.
Well said.
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
|
June 05, 2014, 04:44:31 PM Last edit: June 05, 2014, 06:34:50 PM by jonald_fyookball |
|
Again, disclaimer: I'm not an expert.
I would dare to say no, it's not an improvement over Bitcoin. With bitcoin's poW, mining pools don't have any special powers that solo miners don't also have. So while the hashing power is "pooled", consensus isn't really "delegated" beyond the same protocol rules that affect everyone.
If you are talking about supernodes solving the nothing at stake problem because they can check signatures in real time, that is definitely taking a step toward trusted authorities. In contrast, proof of work acts as it's own timestamp.
Bolded part is what I believe to be a major misconception. What powers do delegates have that mining pools don't? I even advocated to call them "signing pools" because they play the same role. All they can do is exclude transactions. (I'll tell you one: they have the ability to vote on "alerts"... but bitcoin's alert system is far more centralized ) Took another look at bitshares , you may be right. Not sure if it means dpos necessarily immune from n.a.s....If attacker gains several delegates or has the stake to do so.
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
June 06, 2014, 09:51:20 AM |
|
I still do not get the difference between TF and DPoS. They seem equivalent to me. Just newspeak so to say.
Very similar. DPoS lets you vote against delegates, has a cap per delegate, and and delegate order is determined once per round rather than after every block (you can't try to pick a "good" block to get you more than N blocks in a row if you don't own more than N delegates) So, it is basically the same. Thank you.
|
|
|
|
sumantso
Legendary
Offline
Activity: 1050
Merit: 1000
|
|
June 10, 2014, 10:59:50 AM |
|
Its like this, you can always get a single individual/group to set up up multiple pools in PoW/PoS, or multiple delegates in DPoS and grab more share than what it seems. But the hard cap means that it is more complex to get the same control.
Say, Ghash sets up another couple of pools anonymously (or maybe even does), or makes buddies with a couple of other big pools, then it already has control. In DPoS on the other hand, he/she/they have to go through a lot more trouble (some 50 delegates in case of BTSX) to get the same control.
Besides, say, a pool offers incentives, then everybody will naturally flock to it. Sure, at some they might start getting worried and not go, but as we have seen in the Ghash case, appealing to the better sense of the mining equipment owners doesn't work to well. They might not even be too worried about the long term health as they might be just looking at it as a business. In DPoS, the hard cap means such a scenario is not possible, and you have to also keep in mind that the users of the coin are the ones who are voting.
I think I see which direction you are coming from. But I do not clearly see how a hard-cap is going to solve the problem of a second pool under control of the very same real-world entity. "A lot more trouble" Why? Are existing pools preferred before new ones? Thats because you can in PoW, say, put up two pools and grab control. Here you need to set up some 50 odd delegates. Of course, the developer may decide that its popular and its needs more and then the number of delegates can be increased.
|
|
|
|
sumantso
Legendary
Offline
Activity: 1050
Merit: 1000
|
|
June 10, 2014, 11:02:16 AM |
|
Again, disclaimer: I'm not an expert.
I would dare to say no, it's not an improvement over Bitcoin. With bitcoin's poW, mining pools don't have any special powers that solo miners don't also have. So while the hashing power is "pooled", consensus isn't really "delegated" beyond the same protocol rules that affect everyone.
If you are talking about supernodes solving the nothing at stake problem because they can check signatures in real time, that is definitely taking a step toward trusted authorities. In contrast, proof of work acts as it's own timestamp.
The miners contributing to the pool doesn't have any power. The pool owner decides what transactions to include. Also, keep in mind that the miners are not the same as the actual users of the coin. Theres a overlap, but it would have been so much better if all those using it are actually the ones participating.
|
|
|
|
sumantso
Legendary
Offline
Activity: 1050
Merit: 1000
|
|
June 10, 2014, 11:03:36 AM |
|
I still do not get the difference between TF and DPoS. They seem equivalent to me. Just newspeak so to say.
Very similar. DPoS lets you vote against delegates, has a cap per delegate, and and delegate order is determined once per round rather than after every block (you can't try to pick a "good" block to get you more than N blocks in a row if you don't own more than N delegates) So, it is basically the same. Thank you. IMO, the cap means its very different, as I can see the same pooling problem with TF as in PoW. But it seems not many agree with this viewpoint.
|
|
|
|
ChuckOne
Sr. Member
Offline
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
|
|
June 10, 2014, 11:46:04 AM |
|
IMO, the cap means its very different, as I can see the same pooling problem with TF as in PoW. But it seems not many agree with this viewpoint.
So, I ask again: what is this cap good for? Where is the technical difficulty in creating a new pool, when my first pool is capped?
|
|
|
|
toast
|
|
June 10, 2014, 03:01:28 PM |
|
IMO, the cap means its very different, as I can see the same pooling problem with TF as in PoW. But it seems not many agree with this viewpoint.
So, I ask again: what is this cap good for? Where is the technical difficulty in creating a new pool, when my first pool is capped? Yeah the cap doesn't mean much IMO, the "downvotes" are the more important part. The important part is that as a pool operator, you can only pay dividends to all stakeholders and not just to your voters, otherwise you will get voted out. This alleviates economies of scale which lead to centralization.
|
|
|
|
|