0 Members and 1 Guest are viewing this topic.
Quote from: liondani on May 25, 2014, 11:25:31 amPS + variable number of delegates depending on transactions volume...?Variable number would at least remove the magic number of 100 delegates. Magic numbers is the 1st thing that attracts attention of opponents.
PS + variable number of delegates depending on transactions volume...?
Recent update... the number of delegates must be a ODD number to prevent the potential of a chain split of equal length. We had discussed making the number of delegates PRIME, but this seems to be an unnecessary considering a it does not prevent a 3-way split from potentially forming two equal length chains. At every time interval (30 sec) exactly one block can be produced (or not produced). If the network splits this means that two chains with opposite holes will be produced until the missing delegates are fired. Assuming both sides of the fork replace their delegates at an equal rate then the chain that started out with the most delegates will always have the most blocks and thus be the best. If you get a chain fork that lasts for a prolonged period of time then which ever chain is most effective at keeping delegates online will ultimately win. To be effective at this will require that the delegates that were disconnected be replaced rapidly; however, to replace them requires shareholders to switch votes or to vote against them. This means that the fork is ultimately resolved by how the shareholders are divided by the network split rather than just how the delegates are divided. What will likely happen in the event of such a split is that all shareholders will become aware of the split immediately and also know which side of the split they are on. Many delegates can immediately detect that they are on a minority fork and could choose to let the minority fork die by voluntarily not producing blocks for it. Only in the event of hostile delegates would the minority delegates & shareholders attempt to 'make a run for it'... Conclusion: having an ODD number of delegates makes it easy to identify a minority fork and the shareholders and delegates will act accordingly. There is one last 'far-out-there' attack where the network is divided into 3 or more pieces less than 50%... in this case the delegates would have to stay online producing blocks until they could confirm that their 3rd is the largest 3rd. If they are in the smallest 3rd then they should stop producing blocks to let that third die.These corner cases are all ultimately resolved by the longest-chain standard and it is inconceivable to think that a consensus would not force once fork or another to win out.
Quote from: liondani on May 25, 2014, 08:40:21 amthe possibility both to be wrong is small I guess...(Devil's advocate mode on)The truth is not to be found by voting...(Devil's advocate mode off)
the possibility both to be wrong is small I guess...
Quote from: Come-from-Beyond on May 24, 2014, 03:52:30 pmQuote from: bytemaster on May 24, 2014, 02:23:36 pmI think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.Aye, I thought so too.This is a good sign for both of our communities.
Quote from: bytemaster on May 24, 2014, 02:23:36 pmI think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.Aye, I thought so too.
I think that at the end of the day the primary difference between transparent forging and DPOS is only how the block producers are selected. In one case you do it based upon balance, we do it by vote.
Quote from: bytemaster on May 23, 2014, 10:37:18 pmIf the attacker has 51% then their hidden chain will be longer than the public chain. The attacker have to reveal this hidden chain before the legit chain goes 10* blocks ahead of the fork. Otherwise online nodes won't accept his chain. So after 10 confirmations transactions will be set in stone.---* - actual number depends on statistics, it's set to 720 now.
If the attacker has 51% then their hidden chain will be longer than the public chain.
Thank u. Bitshares looks similar to Nxt, I hope u don't mind if I borrow good ideas.
Quote from: Agent86 on May 24, 2014, 10:46:29 amWelcome to the forum CfB! Thanks for posting! I love to see tech discussion with NXT devs welcome!
Welcome to the forum CfB! Thanks for posting! I love to see tech discussion with NXT devs
Quote from: bytemaster on May 22, 2014, 03:07:15 pmQuote from: atmos on May 22, 2014, 03:01:06 pmBytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?The block producers get to choose which blocks they build off of. They can safely ignore blocks found by the 49%.... sure they 49% will still find blocks, they will just be orphaned.Hi bytemaster attaker have 51"% hash power ,and he does not want chain fork ,but he only have 51% chance to find lucky No. to produce block , others also have 49% hash power ,and have 49% chance find lucky No. to produce block .so the attacker have 0.51^6=0.0175 chance produce 6 continual blocks , others have 0.49^6=0.0138 chance to produce 6 continual blocks, and there are 0.968=96.8% chance of attaker and others producing blocks in 6 blocks if the attacker produce blocks and does not announce it until he produce 6 continual block, this will make chain fork.
Quote from: atmos on May 22, 2014, 03:01:06 pmBytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?The block producers get to choose which blocks they build off of. They can safely ignore blocks found by the 49%.... sure they 49% will still find blocks, they will just be orphaned.
Bytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?
Quote from: bytemaster on May 23, 2014, 08:32:46 pm But a more subtle attack is to only produce the block for 50% of your peers and not give it to the other 50% *AND* to do it at the last possible moment such that some peers include it and others don't. I am not expert, but I remember BTT thread about how Nxt works:Let's say I have 25% of NXT coins. And I want to mount an attack. I need to do the following.1. Wait until I am selected as a forger.2. Create 2 blocks, one for the network and one I hold back.3. Continually add more blocks to the block I hold back. This is my chain I will introduce later as my attack.The problem is step 3. To add another block to my held back block I need to be selected as the forger for that block too. However forger selection is based on the hash of the previous block and my account address.Neither of these I can change quickly enough to be sure I generate the next block. So my probability of being selected to build the next block is 25% for each block.
But a more subtle attack is to only produce the block for 50% of your peers and not give it to the other 50% *AND* to do it at the last possible moment such that some peers include it and others don't.
2) What if you are a new node and you first connect to the network. You see two chains, how do you decide which chain is the 'best' chain?
Alice, Charlie, Alice, Bob, Bob, Charlie, Bob, Charlie, Alice, ...First u receive a block (A) from Alice.Then u receive a block (B) from Charlie.Then u receive a block from Alice, but she wants to eject Charlie from the queue and references block A as the previous block. Ur soft will ignore her block and will wait for the next forger. If the next one is Bob and he references block A too then ur soft will ignore this block too. After a while there will be a turn of Charlie.As we can see bad guys can't "punish" good ones. The effect is exactly the opposite.
Quote from: voldemort628 on May 22, 2014, 02:28:52 pmhttps://nxtforum.org/transparent-forging/is-this-true/msg26631/#msg26631Ignorance is bliss? How on earth can the answer be "no"? In fact for nxt wouldn't it be even worse since most stake is offline and not producing blocks most of the time?Sent from my SCH-I535 using Tapatalk
https://nxtforum.org/transparent-forging/is-this-true/msg26631/#msg26631
Imagine if a lot of people use their votes to vote against delegates and a lot of people also vote for candidate delegates that have less than the minimum needed support to be chosen as a delegate (such as always voting for yourself or a friend to be a delegate).I would think the people that actually end up being delegates might have a very small percentage of the stake supporting them.Example: 20% of stake votes for delegates controlled by some controversial figure(s) and 20% of stake votes against that person's delegates. Then 30% of people vote for candidates that don't have enough support to matter.That leaves only 30% of the stake that are supporting actual delegates. You might be able to get 51% of the delegates with much less than 50% of the stake?Especially because factions can get together and plan to vote for a bunch of delegates all at once before anyone has time to think to vote against them.
Quote from: bytemaster on May 22, 2014, 07:07:48 pmQuote from: gamey on May 22, 2014, 06:59:59 pmI am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority. This could be mitigated by keeping the vote distribution as equal as possible. To do this the client software should have some form of a ordered list of delegates to vote for. So that the one favored guy doesn't get 30% of the votes. (for example) The list will move your vote "down the line" so to speak. This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.There is a maximum vote per delegate equal to 2x what they could receive if all delegates had an equal vote. This means for 100 delegates, the max vote is 2%.Does the client instantly kick the vote back so a person can make another decision? Or is it decided by the network and thus the vote floats around in limbo ? You also need to give delegates some sort of name or otherwise they are just #s to people which will not lead to effective voting choices. Names introduce cognitive biases which aren't exactly good, but it is better than a pure #. Is the name of a delegate a public key ?
Quote from: gamey on May 22, 2014, 06:59:59 pmI am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority. This could be mitigated by keeping the vote distribution as equal as possible. To do this the client software should have some form of a ordered list of delegates to vote for. So that the one favored guy doesn't get 30% of the votes. (for example) The list will move your vote "down the line" so to speak. This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.There is a maximum vote per delegate equal to 2x what they could receive if all delegates had an equal vote. This means for 100 delegates, the max vote is 2%.
I am likely confused here, but the problem seems to occur when your vote distribution is lopsided it opens the process up to being exploited by a minority. This could be mitigated by keeping the vote distribution as equal as possible. To do this the client software should have some form of a ordered list of delegates to vote for. So that the one favored guy doesn't get 30% of the votes. (for example) The list will move your vote "down the line" so to speak. This optimizes the power of each stake's vote and helps prevents situations where a minority is able to have undue influence due to the clumping of the votes towards the most popular delegates.
Quote from: bytemaster on May 22, 2014, 03:07:15 pmQuote from: atmos on May 22, 2014, 03:01:06 pmBytemaster, with all the examples you mentioned you talk about 51% being enough to gain the ability to produce 100% of the blocks. How is that possible if with Bitcoin the chance of finding a block is based on the probability relative to your hasing power? Wouldnt it be the case that 49% of the blocks would still be produced by the 49% minority? The same for NXT because it is also probabilistic. And for the deterministic DPOS wouldnt the non colluding 49% be able to produce blocks as they wish when it's their turn?The block producers get to choose which blocks they build off of. They can safely ignore blocks found by the 49%.... sure they 49% will still find blocks, they will just be orphaned.And the 49% could ignore the blocks found by the 51% So it just means that in the long run the 51% attacker has the longer chain? This would be called a fork then?
Quote from: bytemaster on May 22, 2014, 03:24:06 pmQuote from: toast on May 22, 2014, 03:20:00 pmQuote from: bytemaster on May 22, 2014, 02:00:37 pmRecognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate. It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 51% of delegates by stake?The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.All delegates have equal power in the system as selection of the next delegate is not based upon their net votes. This means a delegate has nothing to gain by having more than 1% and nothing to lose by having less than 1% unless they are not in the top 99. Exactly, so by allowing 51 delegates to fire regardless of stake-vote you are making a 51% attack into a ~40% attack.
Quote from: toast on May 22, 2014, 03:20:00 pmQuote from: bytemaster on May 22, 2014, 02:00:37 pmRecognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate. It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 51% of delegates by stake?The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.All delegates have equal power in the system as selection of the next delegate is not based upon their net votes. This means a delegate has nothing to gain by having more than 1% and nothing to lose by having less than 1% unless they are not in the top 99.
Quote from: bytemaster on May 22, 2014, 02:00:37 pmRecognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate. It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network. 51% of delegates by stake?The bottom 51% of delegates might have less than 51% of stake. I know the clients smooth things out automatically and there are hard caps... make the % cutoff based on those theoretical hard caps.
Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate. It wouldn't actually change the security model, it would simply make it slightly easier to coordinate among the delegates and the rest of the network.