I think the biggest difference between POSand POW is:
With POW, the work in the past can't be stolen, which is not the case for POS. That's why POS coins rely on checkpoint so much.
Topic: network split attack on POS coins! techincal discussion (Read 1100 times)
I think DPOS also have similar issues as the POS minting pool: if someone got the 101 delegates' private keys of any point-in-time, he can fake a block chain longer than the main chain, which will be accepted by all the new wallet nodes.
The resulting combination of huge pools and nothing-at-stake attacks would create an unsettling ecosystem, no?
The ppc dev group is trying to fix the nothing-at-stake problem, but I agree that pos minting pool will cause huge problems without careful protocol design.
ugh, in the thread you link to, Sunny King sounds like a "disincentive for pool formation" is a good thing. I disagree, a minting pool will be needed, and it would be great if the pool could work only with the minting key and without actually requiring users to deposit. If there is a PoS block every 10 minutes, but after 90 days as time passes wihtout minting you start to loose interest, then there won't be enough room for everyone to mint and earn their full interest. So only those with high stakes will be able to do it, creating further inequality in the system.
I think the minting pool will cause a bigger problem than inequality, the 51% attack, if the minting keys are reuseable.
Since leaking the minting key does not do harm to the users' coins, the users will tend to share their keys with others easily(move from one pool to another, etc.), which makes it easy for attackers to collect minting keys. If someone collects enough minting keys, they could do 51% attack easily----the attack costs really little.
If we want to avoid such attacks, we must require most users to change their minting key regularly, which I doubt will work smoothly.
So a minting pool seems to be unrealistic without significant changes in the cold minting strategy IMO.
For the margin interest problem, maybe we could alleviate it by lower the hardware costs, such as mobile wallet, lightweight wallet, etc. If the hardware cost is low enough, most users will be able to mint with good interests.
I tried to find the features planned to add to v0.5 but no good, just got this : http://www.peercointalk.org/index.php?topic=3040.msg28438#msg28438
But I think they are going to implement this since mike is in charge of v0.5 developping.
But I think they are going to implement this since mike is in charge of v0.5 developping.
ugh, in the thread you link to, Sunny King sounds like a "disincentive for pool formation" is a good thing. I disagree, a minting pool will be needed, and it would be great if the pool could work only with the minting key and without actually requiring users to deposit. If there is a PoS block every 10 minutes, but after 90 days as time passes wihtout minting you start to loose interest, then there won't be enough room for everyone to mint and earn their full interest. So only those with high stakes will be able to do it, creating further inequality in the system.
The resulting combination of huge pools and nothing-at-stake attacks would create an unsettling ecosystem, no?
I tried to find the features planned to add to v0.5 but no good, just got this : http://www.peercointalk.org/index.php?topic=3040.msg28438#msg28438
But I think they are going to implement this since mike is in charge of v0.5 developping.
But I think they are going to implement this since mike is in charge of v0.5 developping.
ugh, in the thread you link to, Sunny King sounds like a "disincentive for pool formation" is a good thing. I disagree, a minting pool will be needed, and it would be great if the pool could work only with the minting key and without actually requiring users to deposit. If there is a PoS block every 10 minutes, but after 90 days as time passes wihtout minting you start to loose interest, then there won't be enough room for everyone to mint and earn their full interest. So only those with high stakes will be able to do it, creating further inequality in the system.
I tried to find the features planned to add to v0.5 but no good, just got this : http://www.peercointalk.org/index.php?topic=3040.msg28438#msg28438
But I think they are going to implement this since mike is in charge of v0.5 developping.
But I think they are going to implement this since mike is in charge of v0.5 developping.
Maybe rejecting blocks with same stake iteratively for up to 6 times would be safe.
I assumed they would reject the last block recursively until they were from different kernels... as many levels as they find.
I don't know how they are planning to do it but if they did only the very last then yes, it would be slightly mitigated but they would still be vulnerable.
The solution of rejecting both blocks may greatly decrease the chances of successful attack, but I wonder what if some attacker solves 2 successive blocks and broadcasting them (with different txs included) at once? If only rejecting the last block, seems that the network would still be splitted.
The difference is that if one attacker has 10% of all stake available, splitting the network takes about 10 blocks before the fix, while the num grows to about 400 afterward.
Maybe rejecting blocks with same stake iteratively for up to 6 times would be safe.
The difference is that if one attacker has 10% of all stake available, splitting the network takes about 10 blocks before the fix, while the num grows to about 400 afterward.
Maybe rejecting blocks with same stake iteratively for up to 6 times would be safe.
I've found some mentions here: https://bitcointalksearch.org/topic/m.1277594
and here: http://www.peercointalk.org/index.php?topic=1956.0
but they talk about reusing work on multiple chains, not about using this to intentionally create multiple chains in order to split the net
they'll implement this that may help relieve the problem: http://www.peercointalk.org/index.php?topic=2783.msg28885#msg28885
they'd reject both blocks (only latest block of a chain is rejected) if there is a duplicate...
do you think this would solve the issue? I think it might, but until then all pow/pos coins are vulnerable
and here: http://www.peercointalk.org/index.php?topic=1956.0
but they talk about reusing work on multiple chains, not about using this to intentionally create multiple chains in order to split the net
they'll implement this that may help relieve the problem: http://www.peercointalk.org/index.php?topic=2783.msg28885#msg28885
they'd reject both blocks (only latest block of a chain is rejected) if there is a duplicate...
do you think this would solve the issue? I think it might, but until then all pow/pos coins are vulnerable
Hi, there!
quoting the PPC paper:
So, if I find a stake kernel that meets the difficulty, I could use it to generate 2 different blocks with it (by including different tx), send one to half of the nodes, the other one to the other half, and split the network?
generalizing, I could generate N blocks, send each node a different block simultaneously, and partition the network in many many pieces, only with a single POS minting?
"until a successor is received"... but it could be some time... this is specially bad for POW/POS hybrids that already have a relatively low POW hashrate...
Please confirm and expand on consecuences, or explain where am I wrong.
cheers!
gatra
quoting the PPC paper:
Quote
A duplicate-stake protocol is designed to defend against an attacker using a single proofof-
stake to generate a multitude of blocks as a denial-of-service attack. Each node
collects the (kernel, timestamp) pair of all coinstake transactions it has seen. If a received
block contains a duplicate pair as another previously received block, we ignore such
duplicate-stake block until a successor block is received as an orphan block.
stake to generate a multitude of blocks as a denial-of-service attack. Each node
collects the (kernel, timestamp) pair of all coinstake transactions it has seen. If a received
block contains a duplicate pair as another previously received block, we ignore such
duplicate-stake block until a successor block is received as an orphan block.
So, if I find a stake kernel that meets the difficulty, I could use it to generate 2 different blocks with it (by including different tx), send one to half of the nodes, the other one to the other half, and split the network?
generalizing, I could generate N blocks, send each node a different block simultaneously, and partition the network in many many pieces, only with a single POS minting?
"until a successor is received"... but it could be some time... this is specially bad for POW/POS hybrids that already have a relatively low POW hashrate...
Please confirm and expand on consecuences, or explain where am I wrong.
cheers!
gatra
Jump to: