What if you needed 51% of all he coins in existence before you could fork the chain ?
The likelihood of any 1 attacker having that many coins is what ?
Topic: Poll - Should Proof of Stake be implemented in Litecoin? - page 2. (Read 4707 times)
If you'd be so kind, please answer the basic question: do you have a suggestion regarding how to cement a checkpoint block (that cannot be reversed by 51% attack) in a way that doesn't require proof-of-stake?
With LDD WBC, there is no need for a specific checkpoint block, every block becomes a checkpoint after it is buried deep enough.
Say we use the last 5,000 blocks as our LDD metric. The average LDD in each block is say, 1,000.
You, an exchange, are interested in a transaction in block 2,001.
Block 2,002 comes along with 1,050 LDD.
Block 2,003 comes along with 800 LDD.
Block 2,004 comes along with 1,500 LDD.
Block 2,005 comes along with 1,110 LDD.
Block 2,006 comes along with 900 LDD.
Block 2,007 comes along with 1,200 LDD.
Block 2,008 comes along with 1,500 LDD.
Block 2,009 comes along with 1,300 LDD.
Block 2,001 becomes cemented because there are 6 blocks that follow that meet or beat the average LDD. This is a client-side operation and the software must notify the user if a competing chain attempts to reverse block 2,001, but it will NOT automatically replace it. In reality, litecoin would probably use 20-30 blocks before cementing since its block time is 2.5 minutes instead of 10. An hour should be more than enough time for that block to have propagated the network. If you're extra paranoid, you could wait until block 2,009 is cemented.
If you do not have faith that blocks will be properly passed around to achieve this, then you can't possibly have faith that the proof of stake signatures will be immune to the same problem. If you're worried about some miraculous chain of events that might cause a significant, temporary fork, then use more blocks to be safe. You have suggested 100 blocks to be a checkpoint for PoS, the same number could be used for the LDD WBC. But I think it's overkill considering, AFAIK, bitcoin has never gotten past 1 orphan block. I do not know about LTC, but it would be interesting to see since it's 4 times faster. Is 1 block still the biggest orphan?
Days destroyed weighted block-chain advantages:
* Clients have a say in the matter. Every client. Miners are forced to include every transaction possible because if someone else comes along and does them one better, their block may be invalidated. Even if only a single miner is doing the right thing, the clients will be using his chain over a malicious one. So as long as one miner is honest, the honest network wins.
* Clients have the power to choose which block-chain is the correct one, not basing it off of hashing power. This is the ultimate blow to any 51% attack. Want to create a monopoly? Oh well someone else came along and is offering cheaper tx fees, goodbye.
* Absolutely no additional data is added to the block-chain. Nothing to keep track of except mini-forks which may be slightly more likely depending on how the final algorithm works.
* Money is given no more power than it already has. There is a veritable check and balance system between clients, miners, and the wealthy.
* Difficulty CAN GO DOWN without opening the network to attack. This means transaction fees can go down. And stakeholders don't have to be paid to cancel out this effect.
* Clients have a say in the matter. Every client. Miners are forced to include every transaction possible because if someone else comes along and does them one better, their block may be invalidated. Even if only a single miner is doing the right thing, the clients will be using his chain over a malicious one. So as long as one miner is honest, the honest network wins.
* Clients have the power to choose which block-chain is the correct one, not basing it off of hashing power. This is the ultimate blow to any 51% attack. Want to create a monopoly? Oh well someone else came along and is offering cheaper tx fees, goodbye.
* Absolutely no additional data is added to the block-chain. Nothing to keep track of except mini-forks which may be slightly more likely depending on how the final algorithm works.
* Money is given no more power than it already has. There is a veritable check and balance system between clients, miners, and the wealthy.
* Difficulty CAN GO DOWN without opening the network to attack. This means transaction fees can go down. And stakeholders don't have to be paid to cancel out this effect.
Quote
I'm asking about the basic concept, please avoid the added complexities of cementing 6 consecutive blocks and consider the proof-of-stake cementing of the 100th signatures block. With proof-of-stake, we can cement the (say) 100th block with signatures that cannot be faked by an attacker with 51% hashpower, so everyone can protect themselves from a double-spending attack by waiting past the checkpoint signatures block in order to be sure that the relevant transactions couldn't be reversed.
"rah rah rah my idea is better and I won't read what you've written throughout the thread or attempt to understand because clashes in the face of what I think is right so I will therefore treat you like an idiot"
I use the word "cement" or "solidify" to represent the idea that the distributed network arrives to an agreement on a special checkpoint block that won't be reversed, which determines the true blockchain even if a 51% attacker prepared the branch that ends in a special checkpoint block. If the word "cement" also has other meanings, please choose a different word for what I described to be sure that we discuss the same thing. It's true that I haven't read yet your other ideas, because I'm trying to understand first whether your ideas solve the same problem or different problems. If you'd be so kind, please answer the basic question: do you have a suggestion regarding how to cement a checkpoint block (that cannot be reversed by 51% attack) in a way that doesn't require proof-of-stake? I don't claim that there isn't such a way, I've tried to think of another way to do it for several minutes, but didn't come up with anything.
If your ideas are orthogonal and try to solve/improve other properties of the Bitcoin protocol, what are the (supposed) deficiencies of Bitcoin that you're trying to improve? Is it waste of energy of PoW, or other deficiencies?
are you suggesting that each node will simply cement after seeing 6 consecutive blocks?
No, but the proof of stake wiki is. But then it turns around and says it's all up for grabs depending on what the stake holders do.
I agree that proof of stake will likely add a lot of bloat to the blockchain and possibly add a lot of strain to the network to propage all those signatures. Etlase2, I am also thinking about your days destroyed solution. It seems like a good solution, but can you think of how it can help solve the problem of an attacker forking the chain for 10 blocks so that he can do a double spend on the exchange?
This would have to be part of the design algorithm. Something that first needs to be designed, tested, and fine-tuned.
I think a good place to start is for each client to follow the block-chain back a couple thousand blocks or so and see what the typical Litecoin Days Destroyed is for each block, and use that as a base line. If 6 blocks in a row meet or beat the average LDD, the 6th block (in bitcoin terms, perhaps this would be 20 or so in litecoin, but 6 may still be fine, needs testing) in the past could be cemented in stone and can only be replaced if the user agrees to it. If the LDD is say, between 20-40% below normal, it will take perhaps 4x the 6 or 20 blocks before this block will be cemented unless 6 or 20 blocks come after that meet or beat LDD avg. If it's 40-60% below normal, then 8x, and so on.
Something along those lines. An exchange could wait a few extra blocks to be fairly sure that everyone has the block it is interested in cemented.
The *only* theoretical problem that PoS solves that LDD WBC doesn't is a huge network split. And PoS does not completely solve it because signing is optional. With the LDD WBC individual clients will have to choose which chain they want to use. This will probably be apparent in the closest potential real-world scenario such as an individual country cutting off its people from the internet at large. It will be obvious for those users when and if they reconnect that they must use the chain that the world is using and not their split. In the case of a split like this, because mining would also be heavily reduced, blocks will come in much slower and the LDD will be much lower so they will not even likely cement any blocks unless the split is for a very significant period of time.
I don't understand, are you suggesting that each node will simply cement after seeing 6 consecutive blocks? That would cause the blockchain to fork into many branches that will never reunite.
I'm asking about the basic concept, please avoid the added complexities of cementing 6 consecutive blocks and consider the proof-of-stake cementing of the 100th signatures block. With proof-of-stake, we can cement the (say) 100th block with signatures that cannot be faked by an attacker with 51% hashpower, so everyone can protect themselves from a double-spending attack by waiting past the checkpoint signatures block in order to be sure that the relevant transactions couldn't be reversed. Do you claim that it's possible to cement a checkpoint block (with this desirable property of protecting from an attacker with 51% hashpower) without proof-of-stake? How?
What is LDD? Litecoin Days Destroyed? How is it relevant?
I'm asking about the basic concept, please avoid the added complexities of cementing 6 consecutive blocks and consider the proof-of-stake cementing of the 100th signatures block. With proof-of-stake, we can cement the (say) 100th block with signatures that cannot be faked by an attacker with 51% hashpower, so everyone can protect themselves from a double-spending attack by waiting past the checkpoint signatures block in order to be sure that the relevant transactions couldn't be reversed. Do you claim that it's possible to cement a checkpoint block (with this desirable property of protecting from an attacker with 51% hashpower) without proof-of-stake? How?
What is LDD? Litecoin Days Destroyed? How is it relevant?
* Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.
This does not require any form of proof of stake and can be implemented on its own. It is inherent in the design of a proper algorithm for a days destroyed weighted block-chain.
This does not require any form of proof of stake and can be implemented on its own. It is inherent in the design of a proper algorithm for a days destroyed weighted block-chain.
How do you cement a checkpoint block without proof-of-stake?
It's written right there in the wiki quote for proof of stake. The stake is not required to cement a block, it is up to the client. A "dumb" way to do it is to just to cement 6 blocks in the past, but this leaves everyone open to the sustained 51% attack still, though it does prevent private in parallel mining to rewrite history. A smarter way to do it is base it around LDD so that an attacker can't sustain a 51% denial of service attack.
There is the potential with proof of stake that there exist two forks and both have less than 50% stake signing it. The only penalty for abstaining from a stake signing is that you lose reputation. That is not a sufficient penalty. In this scenario, the forks can stay completely unresolved. Regardless, a competitor may offer lower tx fees but the stakeholders refuse to sign and so on. It takes power away from the people.
Using the LDD model and user intervention, the people get to decide which fork they want to use. Monopolies can be prevented. Selective transaction approval can be prevented. Sustained 51% attack can be prevented. Proof of stake does not prevent monopolies, it does not prevent selective transaction approval, and its 51% attack prevention is only as good as whatever automated code selects the correct chain for the stake signers. And if stake signers manually choose, then you may as well give that ability to everyone so that everyone can determine what is in their best interest, not a select few. Aren't we all about overthrowing the establishment and such around here? Why is anyone looking to hard-code that in?
One question that keeps coming up to me in this debate about proof of stake:
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
It's a free market, you collect fees by signing the special checkpoint blocks, so you should evaluate the risk of your wallet being stolen versus the reward. I suppose that with grandma's PC it's better to skip trying to collecting signing fees, but for someone with a properly secure computer it should be fine.
In one sense having an incentive to keep coins under your control and continuously use them actually contributes to the health of the network, because with Bitcoin there appears to be a trend to send your coins to 3rd-parties that (supposedly) give you high interest or simply the convenience of using an online wallet, and this should be even more risky than someone hacking into your personal computer.
* Cementing is a node's reluctance to do a blockchain reorganization. A node will reject any new block found if it contradicts a 6-block deep branch it is already aware of and currently considers valid. That is, once a node receives 6 confirmations for a block, it will not accept a competing block even if it is part of a longer branch.
This does not require any form of proof of stake and can be implemented on its own. It is inherent in the design of a proper algorithm for a days destroyed weighted block-chain.
This does not require any form of proof of stake and can be implemented on its own. It is inherent in the design of a proper algorithm for a days destroyed weighted block-chain.
How do you cement a checkpoint block without proof-of-stake?
@coblee, thanks for fighting the good fight 
51% of the universe's computing power should be enough for anybody.
-MarkM-
-MarkM-
and also, the community needs to seriously consider whether we want to be "artificially" tougher against 51% and maybe throw the entire thing out of balance or if we should consider 51% "attacks" a feature/characteristic of sorts of the currency. any modification to the design might make it inherently unsafer. security is the lack of functionality, and complexity (even if sometimes introduced to bring in "additional security") more often than not, due to various factors leads to insecurity.
As the Ben Laurie hyperbole originally put it, bitcoin is not secure unless 51% of the universe's computing power is securing the network. So I don't think it is possible to come up with anything worse. 51% attacks are most certainly not a feature and saying it is is like agreeing that 640K should be enough for anybody.
i think etlase's proposal sounds more decent (and less broken) if it can be implemented decently.
i still think new ideas (no matter which) should be tested in a separate test blockchain/currency to hopefuly correct any implementation errors and possibly deal with new not so intuitive attacks which were not considered during the initial discussion/implementation, though.
and also, the community needs to seriously consider whether we want to be "artificially" tougher against 51% and maybe throw the entire thing out of balance or if we should consider 51% "attacks" a feature/characteristic of sorts of the currency. any modification to the design might make it inherently unsafer. security is the lack of functionality, and complexity (even if sometimes introduced to bring in "additional security") more often than not, due to various factors leads to insecurity.
i still think new ideas (no matter which) should be tested in a separate test blockchain/currency to hopefuly correct any implementation errors and possibly deal with new not so intuitive attacks which were not considered during the initial discussion/implementation, though.
and also, the community needs to seriously consider whether we want to be "artificially" tougher against 51% and maybe throw the entire thing out of balance or if we should consider 51% "attacks" a feature/characteristic of sorts of the currency. any modification to the design might make it inherently unsafer. security is the lack of functionality, and complexity (even if sometimes introduced to bring in "additional security") more often than not, due to various factors leads to insecurity.
Why are you whining? what the heck does it matter? There is a valid discussion regardless if it has strayed slightly off-topic.
One question that keeps coming up to me in this debate about proof of stake:
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
They wouldn't have to keep the wallet online, there are solutions to this.
You can send a network message committing your coin for the next N blocks.
Everyone, PLEASE DO NOT USE THIS THREAD TO DESIGN OTHER ALTERNATIVES.
You can open a dedicate thread an link to it, and post occasional message about them, but don't do the design work on top of this thread.
Wouldn't Coin-Day-Destroyed allow me to trigger a reorg by simply stocking up on old coins and sending them to myself without broadcasting (I'm a miner, remember) just to "increase weight" of my blocks ?
Assuming a thriving network, you would have to control some not insignificant portion of the network's GDP and the hashing power for this to matter.
Quote
Wouldn't that make Finneys and other such small doublespend-reorgs easier to make (you just need a big stash of old coins in the right time) ?
A big stash of old coins to pull off tiny heists, plus significant enough hashing power to create your own blocks. In the standard bitcoin and litecoin model, you only need significant hashing power.
Quote
Wouldn't it also make "deep" reorgs (and big doublespends "eating" 5 confirms or more) easier for a 51 attacker with a big stash of old coins (just increase the "weight" of your chain by stuffing your own old-coin spending tx-es into them) ?
No, because you prevent deep-reorgs without user intervention. The only time a deep reorg could ever possibly happen is in one of two scenarios: 1) the network is unhealthy and has split, 2) someone is attacking the network. 1) means there are already other massive issues, 2) means the network is being attacked and it's probably an idiotic idea to reorg but bitcoin will do it anyway for the sake of unity.
One question that keeps coming up to me in this debate about proof of stake:
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
Why would those with large wallets of Litecoin, KEEP THAT WALLET/CLIENT ON LINE 24/7?
If I had a particularity large wallet of litecoins, I would keep it on an USB drive only to be used when I needed to do a transaction, and keep a much smaller wallet for quick access.
It seems to me, that this would put the exchanges and large pools in charge of signing the blocks, and we know they are susceptible to DDoS.
Wouldn't Coin-Day-Destroyed allow me to trigger a reorg by simply stocking up on old coins and sending them to myself without broadcasting (I'm a miner, remember) just to "increase weight" of my blocks ?
Wouldn't that make Finneys and other such small doublespend-reorgs easier to make (you just need a big stash of old coins in the right time) ?
Wouldn't it also make "deep" reorgs (and big doublespends "eating" 5 confirms or more) easier for a 51 attacker with a big stash of old coins (just increase the "weight" of your chain by stuffing your own old-coin spending tx-es into them) ?
Wouldn't that make Finneys and other such small doublespend-reorgs easier to make (you just need a big stash of old coins in the right time) ?
Wouldn't it also make "deep" reorgs (and big doublespends "eating" 5 confirms or more) easier for a 51 attacker with a big stash of old coins (just increase the "weight" of your chain by stuffing your own old-coin spending tx-es into them) ?
Proof of stake was designed without any real thought behind it. It won't work on any reasonable scale.
Please don't hijack this thread for designing other, alternative improvement.
Can you create another dedicated thread?
Can you create another dedicated thread?
Jump to: