http://107.170.30.182/security/delegated-proof-of-stake.php
http://107.170.30.182/security/delegated-proof-of-stake.php
Why not publish / announce it on BTT so that people can give feedback and criticize it? This might uncover overseen flaws / inefficiencies before it is put into practice. This might also draw quality people / developers to the Bitshares community if they find the approach innovative (easy way of quality recruiting) and see an opportunity within the bitshares ecosystem and community to expand on their intellectual unrest. There also was a lot of good feedback for the BTS X attack vectors...
Lastly, proof of work creates a barrier to entry that prevents incumbents from being easily displaced. Compared to Bitcoin, DPOS is at least 10x more decentralized in block production and perhaps infinitely more decentralized relative to market competition.
The process behind DPOS when combined with TaPOS produces a network that has more provable consensus behind it than Bitcoin, Peercoin, and Nxt by a factor of 3 or more.
http://107.170.30.182/security/delegated-proof-of-stake.phpExcellent. +5%
This is very exciting; a really promising advancement. I have some concerns about their implementation, however:Quote2.1 Becoming a Representative
To become a representative you must register your public key with the network and be assigned a 32 bit unique identifier. This identifier can then be referenced in the header of every transaction.
32 bits only provides about 4 Billion possible IDs. Assuming that many will be lost, forgotten, etc., I think that this is not nearly enough. This is exactly the problem that currently plagues IPv4 and is the main reason why a transition to IPv6 is currently underway. There is no reason not to use 64 bits (or even just 48) as a rep's ID, and it provides the overhead that will assure that there will be enough unique IDs for the next hundred or even thousand years. 32 bits is emphatically not enough.
I understand that only 100 reps are working at a time (but why only 100?), but since being a rep is well-compensated, I foresee that most users of a currency that adopted this system would also "throw in their hat" to be potentially voted to be a "working" rep (among the 100) - and they will all need IDs.QuoteIt may be possible for a single individual or organization to control multiple representatives in the chain, but this process would involve deceiving a large percentage of the shareholders into supporting sock-puppets.
This seems to just brush off the issue. I see no actual methods, incentives or reasons that would prevent sockpuppet representatives - after all, on the internet, nobody knows you're a dog (or a sockpuppet). The author assumes that "deceiving a large percentage of the shareholders" is somehow inherently more challenging than getting them to vote for a legitimate representative, but it certainly isn't as I can see it. Shareholders are still not going to be meeting most of these representatives in real life.
The only possible solution I can see to this would be a strong Web of Trust that can trace any sockpuppets to a common source - but since most trust signing is going to happen between pseudonyms on the internet, anyway, even this would probably just become "some silly formality" that users engage in without really understanding what they're doing, and a new sockpuppet would have no problem finding itself well validated in the web in a short time.
All in all, it's a very promising idea, and I don't think that these challenges I've described are impassible. I would look forward to a response (and perhaps even an updated proposal) from the author(s) on these concerns.
Without the barriers to entry caused by proof of work, the honest majority would identify the attack and issue a fork of the code that ignored blocks produced by the attacker. It would be disruptive, but not fatal.
all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block.
nice job.
In a previous thread a requirement was mentioned for each representative having to put up some coin in holding to be eligible for this task? did you determine that this was no longer necessary?
in section "Keeping Representatives Honest", your explanation states that it would be up to the wallet software to prevent new transactions tagged with an invalid-signing-representative id. why wouldn't the network itself prevent these new transactions? Or the network could allow these transactions but overwrite with null for a representative id. if some popular wallet software had a default representative id, and this representative was coerced or somehow turned malicious, the wallet might not prevent new transactions and thus the users could all still vote for the problematic representative. I think the network itself needs to prevent this case I'm not rely on the wallet software.
Valid transactions from any source are included
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Nothing prevents Ripple from doing this..
From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Nothing prevents Ripple from doing this..
The difference is: It wouldn't make much of a difference towards the current state of ripple because they control more than 50% of the money supply anyway... The more distributed BTS are the more decentralized it is!!
From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884Sounds great on paper - hoping to see it implemented somewhere soon!
Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?
Nothing prevents Ripple from doing this..
The difference is: It wouldn't make much of a difference towards the current state of ripple because they control more than 50% of the money supply anyway... The more distributed BTS are the more decentralized it is!!
Inside Ripple the 90% are divided among many players..... so it may still be of some use to them... especially if they ever want to sell.
For example, each node should measure:
1. The average latency of each representative
2. The ratio of transactions included in blocks versus the total number of transactions broadcasted (with enough fees).
3. The number of transactions rejected by this block without any reason (discrimination)
4. The number of times a representative has failed to broadcast the block
5. The number of times a representative has cheated by sending his block before his time slot.
6. The number of coins a representative has. (this could be computed if the representative uses the same pubkey for all his coins)
1.3 Ripple Consensus
The Ripple consensus algorithm allows a group of nodes to agree to reach consensus based upon the concept of a unique node list. The initial unique node list is like a club where 51% of the club members must vote to include a new member. Consensus will follow this core 51% and those outside have no influence. Because this club starts out “centralized” it will remain “centralized” and if it ever becomes corrupted there is nothing the shareholders can do. Like Bitcoin and Peercoin, Ripple separates shareholders from voting rights and is thus much more centralized than other systems.
2.5 Are 100 Representatives Decentralized?
The definition of decentralized is hard to pin down because it has become a buzzword. We consider the free market to be the ultimate form of decentralization and barriers to entry to be the basis of all centralization. Like many things, there are degrees of centralization so we will instead compare the relative centralization of Delegated Proof of Stake to the other alternatives.
3.1 Preventing Exclusion of Transactions
Having 100 representatives each elected by the shareholders and being required to take turns means that any transaction that is approved of by even 1% of the shareholders can be included in less than 30 minutes. This means that no representative can benefit by excluding transactions that vote for other representatives.
<h4>4.0 Transactions as Proof of Stake (TaPOS)</h4>
Every vote for a delegate can be either *for* or *against* them. A delegate is ranked according to the sum of the votes for them minus the votes against them. With this process in place it is now possible for delegates to be fired relatively easily for misbehaving even if the vast majority of a delegates supporters are lazy and not paying attention.
2) When making a normal transaction the user's wallet always votes for the delegate in their top 10 list with the least votes and pulls votes from the delegate with the most votes. This will tend to rebalance a user's votes over 10 delegates and help keep the delegate pool well balanced.
For these representatives, since they know they will generate the certain block at certain timeslot, I think they could define, generate and add some specific tx to the block they made based on the analysis of all the TXs in their hand before they produce the next block. By doing this, they could get additional profit. It's not fair to other players in the market since they manupilate the market directly although on a slight level.
In longterm, maybe we have to take this previlege and its profit as necessary cost of system, but not sure how this will impact the whole market operation and people's confidence to the market. However, during the group discussion of my friends, we have an idea which may resolve this issue.
As mentioned in whitepater, the activity of excluding some TXs on purpose will be found later then that representative might be removed from the list. But the key of this kind of manupilation is the representative could add his/her own tx after he/she checked up all the other TXs, which is almost impossible to be found and punished. So we should split all/each TX in 2 parts. In part one, the TX broadcasted w/ the detailed trade reques content "enclosed". When the representative receive it, he/she could just add this TX into the block to confirm that this TX is valid but no trading actually happened at that time. Then in next block, the part 2, the next representative's job is to "open the envelope" and complete the trading(e.g. match buy orders and sell orders ). Thus, meaningless to add TX even you know what the best deal for this block since the new added order could just be completed at next block.
Not sure if above proposal("envelope transaction") is technically possible and make sense for marketing perspective. Just want to raise this concern and idea for discussion in case the DPOS is so important and we all want to make it as better as possible.
Thanks.
Could we link the BOD with their individual keyhotee ID such that cheating really hurts?
So I can 'downvote' his keyhotee id if he messes things up?
I have been putting together more detailed algorithm documentation here:
http://bitshares.org/documentation/group__dpos.html
If you see anything that needs correction or clarification let me know... the webpage is generated from the following doxygen file:
https://github.com/BitShares/bitshares_toolkit/blob/master/libraries/blockchain/dpos.dox
At all times every share is either voting for or against some delegate but not both.Are shares already voting at genesis?
Every transaction moves a vote from one delegate to either the same delegate or another delegate.Just a single vote or proportional to stake of transaction inputs? If the latter, then proportional to CDD, input BIPS, or what?
All delegates must register a unique identifier, that can be used to vote for or against them [...] delegates are registered using the bts::blockchain::claim_name_output classHow is the chain bootstrapped i.e. how are the first blocks created so that prospective delegates can register identifiers? What is the minimum number of delegates needed for the chain to operate?
When registering an identifier a signup fee equal to 100 times the average revenue per block must be paid. This will insure that a delegate must produce at least 1000 blocks to break even and discourage people from running for the delegate position that are not serious.So a delegate receives 10% of the transaction fees for a block it signs, while the remaining 90% become company dividends?
Voting Algorithm [...] Delegate Scoring [...]Is this simply the particular voting and ranking strategy that will be used by the reference wallet implementation?
Yes it does. 30 sec or better.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
so if there were not this overarching sentiment in the crypto space around decentraliztion the trustee model would win out?
We should have P2P fully integrated and tested this week under the trustee model. At this point we will launch the chain with an intention of doing a hard-fork to activate DPOS once enough delegates have been elected and the system is sound.
I don't know whether this has been discussed before (if it is, do excuse me) but:
What is the incentive of the user to vote in the first place?
I'm talking about a direct incentive here.
Reason I'm asking is because of this:
Heavycoin had/has its 'revolutionary' block reward voting. I personally couldn't be arsed to change the presets of the miner I downloaded off the pool website.
I don't know whether this has been discussed before (if it is, do excuse me) but:
What is the incentive of the user to vote in the first place?
I'm talking about a direct incentive here.
Reason I'm asking is because of this:
Heavycoin had/has its 'revolutionary' block reward voting. I personally couldn't be arsed to change the presets of the miner I downloaded off the pool website.
Users don't have to think about it... their client will automatically vote against anyone who is not performing and otherwise vote for the default clients. Through observation it all clients will learn who to vote for.
Users don't have to think about who to vote for, it is all automatic unless they want to override the automatic settings. Those wishing to become delegate must market and campaign for people to override the defaults. This means they must provide motivation for people to take action such as:
1) increasing user dividends
2) offering other services as a side benefit
I don't know whether this has been discussed before (if it is, do excuse me) but:
What is the incentive of the user to vote in the first place?
I'm talking about a direct incentive here.
Reason I'm asking is because of this:
Heavycoin had/has its 'revolutionary' block reward voting. I personally couldn't be arsed to change the presets of the miner I downloaded off the pool website.
Users don't have to think about it... their client will automatically vote against anyone who is not performing and otherwise vote for the default clients. Through observation it all clients will learn who to vote for.
Users don't have to think about who to vote for, it is all automatic unless they want to override the automatic settings. Those wishing to become delegate must market and campaign for people to override the defaults. This means they must provide motivation for people to take action such as:
1) increasing user dividends
2) offering other services as a side benefit
Is that 10% fee definite or can it float?
Is that what you meant by: "increasing user dividends"? Meaning a delegate could say I'll just take 8% commission and thus leave 92% to the shareholders.
'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.'
How are the shareholders divided?
Are they (the shareholders) actually divided? or only their vote/s is divided.
Not sure there is a much better one, but making number of delegates odd, seems like an ad-hoc bandaid solution to a fundamental problem.
Sent from my iPhone using Tapatalk
When designing a DPOS you have to assume that at some point the delegates may decide to act together and coordinate in their own interest and misrepresent information. Are there mechanisms in place to prevent that from happening?
Sent from my iPhone using Tapatalk
Perhaps their income stream could be locked for a certain length of time sufficient enough to encourage good behavior. Like what they get paid is actually payable within the next year in chunks. Just a thought.
When designing a DPOS you have to assume that at some point the delegates may decide to act together and coordinate in their own interest and misrepresent information. Are there mechanisms in place to prevent that from happening?
Sent from my iPhone using Tapatalk
Assuming 51% of the delegates decide to collude they could block transactions just like a 51% in bitcoin. However, they could not sign alternative blocks without getting fired. If the average shareholder elects people that will collude to harm the network then the network will end up getting hard-forked and continue with new delegates... not pleasant but not the end of the world and certainly much better than Bitcoin mining pools colluding.
If less than 51% are colluding they will get fired for signing false blocks and would certainly get caught.
Light weight clients could query multiple delegates which are unlikely to collude to defraud them... this is a similar principle to Ripple.
As the delegates have a stake in the network, an income stream, and their ability to retain control after attempting to harm the network is near 0 I don't see this as a legitimate threat.
Perhaps their income stream could be locked for a certain length of time sufficient enough to encourage good behavior. Like what they get paid is actually payable within the next year in chunks. Just a thought.
Sent from my iPhone using Tapatalk
What about will the tx fees be for a DPOS tx? It should be the same no matter how high tx volume is because, as far as I know, the reward for the delegates should depend on the tx volume?
So if the average byte size of a block is small but I post a tx with a lot of bytes, than that wouldn't cost me much? That would not be a good incentive structure... Would it?What about will the tx fees be for a DPOS tx? It should be the same no matter how high tx volume is because, as far as I know, the reward for the delegates should depend on the tx volume?
TRX Fee is proportional to the number of bytes for most transactions. Fee adjusts like bitcoin difficulty does... if the block sizes get too big the fee goes up, if they shrink the fee falls.
The network only makes a lot of money once transaction demand starts to be more than bandwidth allotments.
Min trx size is 140 bytes.sorry bm dont wanna keep you from work... I wanted to estimate the tx FEE not the tx size...
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
What about would the tx fee be when the (average or individual? See question above in this post) tx byte size is the one of a simple tx (transfer tokens from adr. A to Adr. B)?
1 share per byte.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
Dpos aims for a max around 8 trx per sec.+5%
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
If you increase the min fee to $0.01 then the network would earn $5 per min and a delegate would earn 0.005 per min. 0.30 per hour for a total $600 per year.
We can therefore calculate the delegate pay based upon the average dollar value of the trx fee.
The challenge is pegging the fee to a dollar amount in some reasonable way.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
If you increase the min fee to $0.01 then the network would earn $5 per min and a delegate would earn 0.005 per min. 0.30 per hour for a total $600 per year.
We can therefore calculate the delegate pay based upon the average dollar value of the trx fee.
The challenge is pegging the fee to a dollar amount in some reasonable way.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
what is the operating time for a day? 24 hours?
Base on this
0.005/min 0.30/hour ??/day 600/year <--- how did this calculated ?
If you increase the min fee to $0.01 then the network would earn $5 per min and a delegate would earn 0.005 per min. 0.30 per hour for a total $600 per year.
We can therefore calculate the delegate pay based upon the average dollar value of the trx fee.
The challenge is pegging the fee to a dollar amount in some reasonable way.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
what is the operating time for a day? 24 hours?
Base on this
0.005/min 0.30/hour ??/day 600/year <--- how did this calculated ?
I did that wrong $2628 per year is the proper number.
I calculated it as if it were a salary for 2000 hours per year.
If you increase the min fee to $0.01 then the network would earn $5 per min and a delegate would earn 0.005 per min. 0.30 per hour for a total $600 per year.
We can therefore calculate the delegate pay based upon the average dollar value of the trx fee.
The challenge is pegging the fee to a dollar amount in some reasonable way.
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
I have changed the spec for DPOS to select the delegate randomly rather than sequentially to prevent an attack whereby a delegate could tweak their vote so they are always scheduled to be the next delegate.
The random number selection is also useful for lotto dac.
I have changed the spec for DPOS to select the delegate randomly rather than sequentially to prevent an attack whereby a delegate could tweak their vote so they are always scheduled to be the next delegate.
The random number selection is also useful for lotto dac.
I have changed the spec for DPOS to select the delegate randomly rather than sequentially to prevent an attack whereby a delegate could tweak their vote so they are always scheduled to be the next delegate.
The random number selection is also useful for lotto dac.
I think there is a list of delegates ordered by the number of votes they got that goes beyond 100. I guess the list is as long as there are delegates that fullfill the requirements and have at least one vote for them... I think I read it in the whitepaper somewhere implicitly.
Would it be a good idea to "fire" every X time the last y (even number) delegates (with the lowest votes) from the 99 first delegates even if they have a good reputation so the other delegates on the list (after the 99 first) have the chance to proof they can make also a very good job and collect more votes after they proove it.The same time everybody on the list compete each other to give the best results (having excellent equipmment etc.) so they try to be as higher on the list as possible ... Could it be the case that the first 1-2 years nobody get fired because they are all "trustfull" (until they proove the opposite) and when we really need new "realy" trustfull delegates we don't find them anymore because they don't are anymore on the waiting list? Maybe my suggestion is worthless because I don't understand the concept verry well... at least I am trying to help :)
I'm confused about something.
Here's what I'm imagining:
Phase 1: Establish Large Stake
a] Borrow 1 million USD
b] Purchase 1 million USD's worth of BTS (or 4% of the total or whatever).
c] Send these transactions to yourself a few times, using these votes to appoint different versions of yourself as a few delegates in a row. Play by the rules for now, including saving up as much coin age as possible.
d] Sell BTS for ~1 million, right as your delegates are in a row (you may have some profit or loss here).
e] Repay your loan.
Phase 2: Build Fake Chains
a] Enter a VM/Supercomputing environment where you can easily do many calculations per second.
b] Take the current blockchain from point (1.d), where you have a few delegates in a row.
c] Using the existing 'real' transaction history, build several thousand parallel chains, one with the 1d sale transaction (which is broadcast), but all others without (which are private).
d] When the last delegate-controlled-by-you is up, proceed to Phase 3.
Phase 3: Profit
a] Broadcast the fake chains, and have your last delegate sign them all quickly (you won't even have to validate, as you know your own chains inside the VM). The thousand attack-chains are now the longest, but none include the 1c sale transaction. Have your delegate refuse to sign the 'real' chain (although you can claim he just 'did not get to it' in time with so many other chains to sign).
b] The next delegate will pick the longest chain (the attack chain) and sign it.
c] One or all of your delegates will be fired (or, possibly, the average user will never notice that anything happened, and none will be fired).
d] In a few blocks, double-spend-sell BTS in step 1d for 1 million.
e] Free million!
What are the problems with this?
Wouldn't it make sense to lower the number of delegates at the beginning when there are probably just a few candidates that are known and can be trusted. When the thing gets as bigger and more people know about it we will have more trustworthy people with real world identities...Any opinion on this bm?
Wouldn't it make sense to lower the number of delegates at the beginning when there are probably just a few candidates that are known and can be trusted. When the thing gets as bigger and more people know about it we will have more trustworthy people with real world identities...Any opinion on this bm?
Wouldn't it make sense to lower the number of delegates at the beginning when there are probably just a few candidates that are known and can be trusted. When the thing gets as bigger and more people know about it we will have more trustworthy people with real world identities...Any opinion on this bm?
No, I am saying you have a few delegates in a row, and attack within a single round.
The attack only works if you buy 51% of the delegates because regardless of how much computational power you have you can only produce one block per delegate per round (a round is where every delegate produces a block).
Lastly, once you did reveal your secret chain (or if it were accidentally discovered) evidence that you signed two blocks with the same timestamp will get you fired from both chains.I know.
Conclusion: this attack is just the 51% attack carried out with leverage. However, it has one other problem. The main chain ignores all forks older than a certain date provided you have the majority of delegates producing blocks on your fork. The secret chain wouldn't be accepted even if it were 'longer'.
Would it be a good idea to "fire" every X time the last y (even number) delegates (with the lowest votes) from the 99 first delegates even if they have a good reputation so the other delegates on the list (after the 99 first) have the chance to proof they can make also a very good job and collect more votes after they proove it.The same time everybody on the list compete each other to give the best results (having excellent equipmment etc.) so they try to be as higher on the list as possible ... Could it be the case that the first 1-2 years nobody get fired because they are all "trustfull" (until they proove the opposite) and when we really need new "realy" trustfull delegates we don't find them anymore because they don't are anymore on the waiting list? Maybe my suggestion is worthless because I don't understand the concept verry well... at least I am trying to help :)
This is an interesting concept. Effectively all you are doing is increasing the number of delegates and forcing the lower delegates to 'take turns'.
No, I am saying you have a few delegates in a row, and attack within a single round.
The attack only works if you buy 51% of the delegates because regardless of how much computational power you have you can only produce one block per delegate per round (a round is where every delegate produces a block).Lastly, once you did reveal your secret chain (or if it were accidentally discovered) evidence that you signed two blocks with the same timestamp will get you fired from both chains.I know.Conclusion: this attack is just the 51% attack carried out with leverage. However, it has one other problem. The main chain ignores all forks older than a certain date provided you have the majority of delegates producing blocks on your fork. The secret chain wouldn't be accepted even if it were 'longer'.
The whitepaper says:
2.4 Resolving Chain Forks
Like proof of work and other proof of stake systems, the best block chain is the longest valid chain.
But, how does the the software know which chain is valid? If two blocks are signed, the delegate is fired, but which block succeeds? I assume the NEXT delegate (which I also control) will decide, that is how I double spend.
2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
Quote2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
This is not possible, someone with a minority of shares cannot elect 100 delegates. All shares are voting for someone at some time. You can change your vote, but not create new votes. End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.
You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.Quote2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
This is not possible, someone with a minority of shares cannot elect 100 delegates. All shares are voting for someone at some time. You can change your vote, but not create new votes. End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.
I don't have a minority, I have all the votes, don't I?
You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.Quote2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
This is not possible, someone with a minority of shares cannot elect 100 delegates. All shares are voting for someone at some time. You can change your vote, but not create new votes. End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.
I don't have a minority, I have all the votes, don't I?
Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.
You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.How does a node which just connected 10 minutes ago know which of the two realities is 'alternate'?
Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.
If you go all the way back to the genesis block and have 10% in the genesis block balance... you will never be able to produce a chain more than 1/10 the length of the public chain. It just is not possible.Only at first. Eventually I am producing a block every 30 seconds with all the delegates I control. In my alternate reality I am, temporarily, only broadcasting the transactions which allow my delegates to take over. Don't the transactions elect delegates? And everyone is fired after one round for failing to produce a block, anyway.
Remember: a block is not produced every 30 seconds unless all delegates are on line. If a delegate is not on line to produce a block in that timeslot the time slot is skipped and that chain is forever one block shorter than it could have been.
random seed updating might need to involve more secrets etc....
Thinking about following case, two continuous delegate are happen to be the same, for example
Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block
So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...
random seed updating might need to involve more secrets etc....
Thinking about following case, two continuous delegate are happen to be the same, for example
Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block
So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...
random seed updating might need to involve more secrets etc....
Random Seed Updating uses the following forumula:
R = HASH( R + revealed_secret ).
Alice will not know R until the future and thus in the present cannot choose secret for x+1.
Thinking about following case, two continuous delegate are happen to be the same, for example
Delegate Alice finds that she happen to be the delegates of two continuous block (she can check that while mining, 1% chance each block), x block, and x+1 block
So in the x block, Alice know that she will be the delegate of x+1 block (1% chance), and maybe she can selectively choose the secret_x for x + 1 to publish, to make the updated random seed[x+1] as she wish, making that she will be the delegate of x+2 block, and so on...
random seed updating might need to involve more secrets etc....
Random Seed Updating uses the following forumula:
R = HASH( R + revealed_secret ).
Alice will not know R until the future and thus in the present cannot choose secret for x+1.
In Alice's turn x, Alice will reveal the secret he created before, and current random seed R[ x ] is known of course, according to this he could calculate out next random seed R[x+1], to check whether x + 1 will or not be her turn.
If x and x + 1 are both Alice, and she knows that now in x, then she can selectively choose the secret which she will reveal in x+1, to make R[x+2] = HASH(R[x+1] + revealed_secret) and decide x+2 will be Alice's turn.
The condition is that Alice has to wait for two continuous turn x , x+1, which is not very difficult 1 - (99%)^x.
True that Alice could not determine who will be the next delegate, but with known that x, and x+1 are both her turn, she can choose to create attack and determine the delegate of x+2, in current seed update algorithm.
I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho +5%
they do ...I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho +5%
The development team has really come together these past few weeks. Things are happening faster, work is being divided more efficiently, communication is improving. I can really feel the difference and the github commits will reveal it as well.
I am pretty impressed on how fast things move currently ... having a hard time following all updates!! .. and thats a good sign imho +5%
The development team has really come together these past few weeks. Things are happening faster, work is being divided more efficiently, communication is improving. I can really feel the difference and the github commits will reveal it as well.
they do ...
+5%
Thanx for all the hard work to all of you!!!!
You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.Quote2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
This is not possible, someone with a minority of shares cannot elect 100 delegates. All shares are voting for someone at some time. You can change your vote, but not create new votes. End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.
I don't have a minority, I have all the votes, don't I?
Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.
If you go all the way back to the genesis block and have 10% in the genesis block balance... you will never be able to produce a chain more than 1/10 the length of the public chain. It just is not possible.
Remember: a block is not produced every 30 seconds unless all delegates are on line. If a delegate is not on line to produce a block in that timeslot the time slot is skipped and that chain is forever one block shorter than it could have been.
You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock.Quote2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key.
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
This is not possible, someone with a minority of shares cannot elect 100 delegates. All shares are voting for someone at some time. You can change your vote, but not create new votes. End result is that if you control 10% of the shares, you can only effect 10% of the delegate selection and thus your secret chain would only ever be able to produce 1/10 of the blocks of the public chain.
I don't have a minority, I have all the votes, don't I?
Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.
If you go all the way back to the genesis block and have 10% in the genesis block balance... you will never be able to produce a chain more than 1/10 the length of the public chain. It just is not possible.
Remember: a block is not produced every 30 seconds unless all delegates are on line. If a delegate is not on line to produce a block in that timeslot the time slot is skipped and that chain is forever one block shorter than it could have been.
So what if people are willing to sell their private keys to addresses, such as those in the genesis block, that are now empty. People will be happy to sell this info because it doesn't cost them anything. They might not even be invested in the chain anymore. And you can use these old keys to build your alternate reality where you control a bigger stake.
Suggestion:
Try to make voting "anonymous". I think it is not desirable if a delegate can buy votes (selectively give back transaction fees to those that vote for the delegate).
An attacking entity can operate at a loss and pay people to vote for their delegates.
awesome work guys. this may seem like a strange request, but would any of you guys mind sharing some newer photos of the office, your workstations, or maybe a pic of the recently united crew? i know yall are busy and its an exciting time... but im excited too damnit! I wanna see some of the cool stuff thats happening over there, and i know im not the only one! Plus photos are very... tangible and can go a long way in helping people feel connected to a project or experience
awesome work guys. this may seem like a strange request, but would any of you guys mind sharing some newer photos of the office, your workstations, or maybe a pic of the recently united crew? i know yall are busy and its an exciting time... but im excited too damnit! I wanna see some of the cool stuff thats happening over there, and i know im not the only one! Plus photos are very... tangible and can go a long way in helping people feel connected to a project or experience
Actually, Brian plans to make a video of life on the BitShares Bridge and take you deep inside the BitShares Bunker. He will be filming it on Monday.
Can it be detected is a delegate hosts his server with amazon or another cloud service. If that is the prefered method and it is not detectable but Amauon knows what they are hosting this could be a point of control by central entities?
See https://bitsharestalk.org/index.php?topic=4813.15
It can't be detected, and the most Amazon/DO/etc would be able to do is shut down the delegate... or steal the privkey ?!
It can't be detected, and the most Amazon/DO/etc would be able to do is shut down the delegate... or steal the privkey ?!
...You only got the votes in your separate private chain though, the rest of the network probably would not accept you alternate reality, provided it doesn't go back all the way to the genesisblock....Quote2] You go back in time, and build a large fake chain which ONLY contains a new series of transactions, all of them from address A to other addresses for which you have the private key....
3] You use these transactions to elect an entirely new set of 100 delegates (as you control the only votes). This may not be possible quickly, but when you cant, you simply claim that the other delegates (who aren't here) failed to sign your block (and disqualified them). For a while, there might be only 3 delegates actually signing on this chain, but you quickly establish 100.
Or are you talking about isolating unsupecting people in your alternate reality, that would require quite a bit of control over network connections as well, but would not affect the main network I suspect.
So what if people are willing to sell their private keys to addresses, such as those in the genesis block, that are now empty. People will be happy to sell this info because it doesn't cost them anything. They might not even be invested in the chain anymore. And you can use these old keys to build your alternate reality where you control a bigger stake.
It doesn't matter, after a few rounds of 99% delegate participation the chain declares an automatic snapshot. So the longest chain is only a short-term metric.
To try again...
A new node connects and sees two chains:
Chain 1 : 100 + 99 + 98 + 100 + 100 + 97 + ... + 100 + 99 = 4589 blocks of a possible 5000
Chain 2 : 100 + 99 + 49 + 49 + 49 + 52 + 59 + 60 + 100 + 100 + 100 + ... + 100 = 4590 blocks of a possible 5000
Both follow all the rules, have snapshots, etc. Which chain does this node select as reality?
I assumed that the network still operates if 51% of the delegates are tracked down and murdered, and their computers destroyed. Perhaps that assumption was false?
I control the secret chain, and the transactions in it.
Therefore, I control "input from the shareholders necessary to change votes away from the non-participating delegates"?
If not, how does that input come about?
After the secret chain is built, I can add in transactions from the original chain, just a little later.
I control the secret chain, and the transactions in it.
Therefore, I control "input from the shareholders necessary to change votes away from the non-participating delegates"?
If not, how does that input come about?
After the secret chain is built, I can add in transactions from the original chain, just a little later.
In addition to owning a few accounts which were once delegates, I own an account which once held 10% of the total BTS. I can send these amounts to myself, while excluding all other transactions.
For a time, I control 100% of the votes seen by the attack-chain.
Assume there are 1234 votes.
I control 10%, or 123 of them.
However, I also control the delegate, who can exclude transfers. So I exclude all the votes that aren't mine.
Votes cast: 123, Votes controlled by me: 123
I control 123/123 = 100% of the votes.
I collect old accounts totaling >50%
Would it make things more robust if there was a delay between the time that a delegate got the number of votes needed and the time they actually became an active delegate? The reason I ask is we have the ability to vote against a delegate, but if whenever we try to vote against a delegate, the voters for that delegate just quickly all switch to another delegate (controlled by the same person) the people trying to vote against them might have to give up because they can't keep track of trying to switch their votes fast enough to keep that person from being a delegate? I was also thinking if you register a delegate but fall below some minimum threshold of support for that delegate for a certain number of blocks, the delegate becomes inactive and is subject to the waiting period before it can become an active delegate after getting votes. This way people will have a much shorter list of active delegates and delegates with at least minimum support to consider when deciding to vote for or against them and they can't be surprised by a delegate coming out of left field.
Also for down the road, I agree with others that "100 delegates" strikes people as a magic/arbitrary number and maybe we can explore what are the pros and cons of more or less delegates, What would be involved with changing it later... hard fork? Could it be dynamic? or have shareholders also vote for the total number of delegates?
Would it make things more robust if there was a delay between the time that a delegate got the number of votes needed and the time they actually became an active delegate? The reason I ask is we have the ability to vote against a delegate, but if whenever we try to vote against a delegate, the voters for that delegate just quickly all switch to another delegate (controlled by the same person) the people trying to vote against them might have to give up because they can't keep track of trying to switch their votes fast enough to keep that person from being a delegate? I was also thinking if you register a delegate but fall below some minimum threshold of support for that delegate for a certain number of blocks, the delegate becomes inactive and is subject to the waiting period before it can become an active delegate after getting votes. This way people will have a much shorter list of active delegates and delegates with at least minimum support to consider when deciding to vote for or against them and they can't be surprised by a delegate coming out of left field.
Our protection against this is that the registration fee is equal to about two weeks' worth of block production, so this attack will drain their stake. Each delegate's stats are visible in the client and eventually you will have the option to let your client auto-downvote misbehaving delegates.
This particular attack would only matter if the attacker had 51% of the delegates. They get in power and the only thing they can do is 'not produce a block' or 'not include a transaction' and thus I do not see what they could gain.
Could it be dynamic? or have shareholders also vote for the total number of delegates?
Could it be dynamic? or have shareholders also vote for the total number of delegates?
+5% for dynamic number of delegates
Sent from my ALCATEL ONE TOUCH 997D using Tapatalk
I collect old accounts totaling >50%
You are right, I assumed this wasn't possible.
Two points:
* Remember it has to be >50% stake within a particular 1 hour window. I think it'd be *more* difficult to do this than getting 50% of the current stake. "Buying all old keys with nonzero balance between 12 and 1am on DD-MM-YYYY. Don't tell any delegates or else they'll add a checkpoint!"
* Even so, this would only affect nodes that have never been online and are trying to sync for the first time, since we do not look back farther than a few rounds of full participation when considering forks.
I collect old accounts totaling >50%
You are right, I assumed this wasn't possible.
Two points:
* Remember it has to be >50% stake within a particular 1 hour window. I think it'd be *more* difficult to do this than getting 50% of the current stake. "Buying all old keys with nonzero balance between 12 and 1am on DD-MM-YYYY. Don't tell any delegates or else they'll add a checkpoint!"
* Even so, this would only affect nodes that have never been online and are trying to sync for the first time, since we do not look back farther than a few rounds of full participation when considering forks.
How does a checkpointing change anything?
In this scheme, "a checkpoint" seems to be exactly the same as "a new block was discovered/signed", which would make it irrelevant...the attack nodes can have their own 'checkpoints'.
Your attack requires cooperation of shareholders to give up their original keys.... it is not worth considering if there is a large number of initial shareholders.HI BM
Delegates just sign blocks .. they do not need to reveal their IP address ..Your attack requires cooperation of shareholders to give up their original keys.... it is not worth considering if there is a large number of initial shareholders.HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould, what if many delegates are attacked by DDOS?
BR
there are many methods and not diffclut to find the IP of delegateDelegates just sign blocks .. they do not need to reveal their IP address ..Your attack requires cooperation of shareholders to give up their original keys.... it is not worth considering if there is a large number of initial shareholders.HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould, what if many delegates are attacked by DDOS?
BR
Also one can set up backup-delegate machines to take over. I dont see any problems here.
BTW. you can even run a delegate through the onion network tor
No need for replacing .. just unlocking the wallet and let the other machine start signing the blocks .. easy handoverthere are many methods and not diffclut to find the IP of delegateDelegates just sign blocks .. they do not need to reveal their IP address ..Your attack requires cooperation of shareholders to give up their original keys.... it is not worth considering if there is a large number of initial shareholders.HI BM
I saw many discuss about the 51% attack, these attacks are done by stakeshould, what if many delegates are attacked by DDOS?
BR
Also one can set up backup-delegate machines to take over. I dont see any problems here.
BTW. you can even run a delegate through the onion network tor
yes, there are backup-delegates , and how many delegates can been replaced one round?
Also all nodes and all traffic is encrypted so you would have to be directly connected to a node to find out if they are the one to produce the block and they might not even be the one that produced it they could just be the first one to have received it.Hi BM
Sent from my iPhone using Tapatalk (http://tapatalk.com/m?id=1)
let's assume, when bitshares release, Chinese network cut off from American,
2 seperate bts chain is running well in each network.
one day, the network is connect again.
which chain will win?
For btc, it's simple, the longer chian win.
From test these days, many chains run seperate without merge.
I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot, English is not my native language , I hope I can been understood.
1. The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2. Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot. We also can set the confirm time of this block is longer than others, maybe need all delegates honored.
3. Each block after this snapshot include the status if honor this snapshot.
4. Each translation include the status if honor this snapshot
5. if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot. The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot , if select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6. If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant, if N equal 100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume + volume of 34 days translation. It doesn’t increase as time passing .
6. If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant, if N equal 100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume + volume of 34 days translation. It doesn’t increase as time passing .
to download the chain , for a new node ,first get the current block No. Nc, , then download the block from Nc-(Nc Mod N) , and check the comfirm status of this snapshot that every was included in blocks , if this snapshot is comfirmed by N blocks , the client don`t need to download the blocks before this snapshot ,otherwise, downland the prevoius N blocks .I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot, English is not my native language , I hope I can been understood.
1. The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2. Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot. We also can set the confirm time of this block is longer than others, maybe need all delegates honored.
3. Each block after this snapshot include the status if honor this snapshot.
4. Each translation include the status if honor this snapshot
5. if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot. The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot , if select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6. If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant, if N equal 100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume + volume of 34 days translation. It doesn’t increase as time passing .
Solid idea. The challenge is in defining what to include in the state and how to download it. With DPOS we have some options not available to other systems, but it is still challenging.
to download the chain , for a new node ,first get the current block No. Nc, , then download the block from Nc-(Nc Mod N) , and check the comfirm status of this snapshot that every was included in blocks , if this snapshot is comfirmed by N blocks , the client don`t need to download the blocks before this snapshot ,otherwise, downland the prevoius N blocks .I am a little investor of AGS and PTS, I have an idea about how to reduce volume of block chain using snapshot, English is not my native language , I hope I can been understood.
1. The purpose of snapshot in my express is different from normal , this snapshot is to replace blocks before them to reduce this size of block chain.
2. Perform a snapshot per N block; and the next block is a special block , its header include the hash both previous block and this snapshot. We also can set the confirm time of this block is longer than others, maybe need all delegates honored.
3. Each block after this snapshot include the status if honor this snapshot.
4. Each translation include the status if honor this snapshot
5. if the snapshot was honored by N block, and was honored by translation witch hold 90% stockholder , this snapshot is a formal snapshot. The blocks before this snapshot can been ignore . ignore the blocks before this snapshot have risk ,so there have N block time to check if there is no attack/ scam in the snapshot , if select N equal 100,000, it mean , every delegate check this snapshot 1000 times if there are 100 delegates, and every client also check this snapshot when a translation is done, and the meantime ,any node can select to keep all block for checking.
6. If all process was finished smoothly, block chain only include a snapshot +N blocks no matter how many years this chain have been running , the volume of a snapshot maybe is constant, if N equal 100,000, consider 30 sec per block , it is about 34 days , so all the size of block chain is equal a constant volume + volume of 34 days translation. It doesn’t increase as time passing .
Solid idea. The challenge is in defining what to include in the state and how to download it. With DPOS we have some options not available to other systems, but it is still challenging.
I feel like the current delegate voting system could use "refinement".
The purpose of voting is to try to accurately reflect the views of the stakeholders. I don't think this is sufficiently accomplished in the current proposal.
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support. This will give a much clearer picture of how the community really feels.
In the current system, in order to "downvote" someone who does something like excludes transactions, you unfortunately must withdraw your support for someone you want to support in order to cast your downvote. It's also a strange balancing act where the vote you would like to cast is dependent on the votes cast by others. If a candidate has all the votes they need, you need to go find another candidate to vote for. If a candidate is going to be downvoted out of being a delegate by others, there's no need for you to use your stake to downvote.
I propose you just vote for any delegate you support. Delegates are selected on how broad their appeal is to stakeholders. There could be a minimum of 97 delegates but an uncapped maximum where everyone who has over 50% community support is automatically a delegate. This seems fair to me. It would be great if all our delegates had over 50% community support backing them (also gets rid of "magic" number of delegates).
If a delegate messes up it's no problem to withdraw your support for that delegate without affecting your support of others.
Delegates could also see if they have lots of community support or if they are "on thin ice". If a delegate had a ton of community support e.g. 95%, It might be rational for them to decide to run an additional delegate and they could have 2 delegates. I might be happy to vote for a trusted core developer to run multiple delegates, say 5 delegates, but at some point I'm not willing to vote for their 6th delegate because I think that is starting to get greedy. So people with lots of community support can gauge that support and potentially run more delegates than someone with less community support.
You sound like the most self-doubtful person I have ever met (other than myself).I guess I'm trying to talk more broadly about what method of electing delegates will be most fair, hardest to game etc. It seems like there may be a lot of people that want to be delegates especially if they are well compensated.
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…
You sound like the most self-doubtful person I have ever met (other than myself).I guess I'm trying to talk more broadly about what method of electing delegates will be most fair, hardest to game etc. It seems like there may be a lot of people that want to be delegates especially if they are well compensated.
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…
I think that if you run under 49% of all delegates and you are doing it under Agent86 you will be safe. Just learn from other people’s mistakes and never post before logging off from the main account…
keep them delegates of yours below 50%, never post before logging off from the main account…Ok, I guess you're saying I'm a sockpuppet? Sorry I missed it; not the case.
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support. This will give a much clearer picture of how the community really feels.
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support. This will give a much clearer picture of how the community really feels.
I think there is diminishing returns in making things more complicated.I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support. This will give a much clearer picture of how the community really feels.
+5% +5% +5%
but with well studied restrictions like...
a)vote for X delegates max.
b)my first voted delegate takes Y points, the second Y-1 points .... etc...
c)make your suggestions...
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support. This will give a much clearer picture of how the community really feels.
This is already how it is, you can split your stake however you like.
I propose instead of having to choose 1 delegate to vote for or against, allow people to vote for however many delegates they want to support. This will give a much clearer picture of how the community really feels.
This is already how it is, you can split your stake however you like.
There is a qualitative difference between:
1 BTS supports delegate 1
1 BTS supports delegate 2
1 BTS supports delegate 3
1 BTS supports delegate 4
1 BTS supports delegate 5
compared to:
5 BTS supports delegates 1,2,3,4 & 5
I hope you can see the difference here.
It is MUCH easier under the current system for a person with a big stake to vote themselves to be a delegate without appealing for broad community support.
Under my proposal it is possible for a delegate to show that over 50% of stake supports their position as delegate. Under current proposal this is not possible.
Current proposal appears to me to make buying votes possible. My proposal I don't believe it is possible.
Downvoting under the current system requires people to remove their support for their desired delegates in order to downvote. Your client seems like it has to do some complicated analysis to constantly monitor which of your liked delegates need support and which don't. Why not just allow people to state who they want as their delegates and express that will all their stake?
Your proposal would require every transaction to update N delegates where N is unbounded.
I think that it is perfectly fine for someone to vote for themselves without broad community appeal. They have appealed to a 'broad' percent of the shareholders (themselves) and thus have equal rights as any other similar group of shareholders.
They cannot do much harm and if they did attempt to harm then they will generate broad community disapproval pulling a relatively little amount from many candidates to concentrate it as a negative vote on one candidate.
By your proposal, the more people you vote for, the more your vote matters. Someone voting for 100 delegates will have 100x more voting power than someone voting for 1.That's not true. How so? You can't vote for the same delegate 100x times.
How exactly would you tally votes in this scheme?
By your proposal, the more people you vote for, the more your vote matters. Someone voting for 100 delegates will have 100x more voting power than someone voting for 1.That's not true. How so? You can't vote for the same delegate 100x times.
If you want to throw as much weight as you can behind one candidate you support them exclusively (just denying support to potential competitors).
You could make 1000 delegates and vote for each of them but that gets you nowhere because they still each only have as much support as your personal stake can provide. No one else has any reason to vote for them. Other candidates on the up and up will get much more broad support and your delegates will never become delegates.How exactly would you tally votes in this scheme?
You tally votes by simply ranking delegates by total amount of stake that supports them. Top 97 delegates are active or anyone with over 50% even if that means more than 97 active delegates.
To clarify what may be a misunderstanding, I'm am proposing to eliminate the ability to "downvote". You either support someone to be a delegate or you don't: it's binary. (right now it's positive, neutral, down)
As soon as you see one of your delegates behaving badly you automatically pull support.
To clarify what may be a misunderstanding, I'm am proposing to eliminate the ability to "downvote". You either support someone to be a delegate or you don't: it's binary. (right now it's positive, neutral, down)
As soon as you see one of your delegates behaving badly you automatically pull support.
If you don't have downvotes you incentivize centralization because a delegate can offer to pay dividends to only his supporters.
Lack of support in a system where there's no cost to supporting someone isn't a punishment
The issue is in tracking total stake that supports them. That means every 'balance' in the blockchain would have to have N delegates attached to it instead of just 1. When you spend that balance you subtract from N delegates and reallocate your votes for those shares to M delegates.I don't think you need to "subtract from N delegates" each time you spend.
What you are asking for is that each delegate sink or swim based upon an independent election. This is no longer 'delegation' but rather popularism.I guess if you make that distinction, then delegation encourages delegates to support the interests of the faction that delegates to them, popularism encourages delegates to appeal to all shareholders and support the interests of the whole DAC.
If you require all delegates to get at least 51% net support then you are asking all of the users to evaluate all of the candidates and that is much to high a burden. If you lower the threshold then it opens the network up to attack by individuals with large minority shares that can move faster than people can 'vote out' their candidates.There is no bottom "threshold", It's basically the 100 accounts that have the most support are active delegates. So no chance that no one reaches the threshold. (I said that 50% could be used as a threshold to add additional delegates only in the situation that all active delegates already have over 50% support)
So I see such a system resulting in either no delegates getting to the threshold or an attacker creating 10000 delegates giving them all a bunch of support faster than anyone can vote them all out. It would become very costly to vote against 10000 delegates produced by the attacker.
This seems to be a long thread and this topic could be buried in here somewhere, but did anyone consider the approval voting system or rank voting when putting the ideas in place for this system? I am sure that if DPOS is a success, copy cats will use alternate voting processes.
http://en.wikipedia.org/wiki/Approval_voting
http://en.wikipedia.org/wiki/Ranked_voting_system
I suppose we should read from here down and consider what the various tradeoffs would imply in a DPOS system
http://en.wikipedia.org/wiki/Approval_voting#Effect_on_elections
Approval voting can be extended to multiple winner elections. The naive way to do so is as block approval voting, a simple variant on block voting where each voter can select an unlimited number of candidates and the candidates with the most approval votes win. This does not provide proportional representation and is subject to the Burr dilemma, among other problems.
Other ways of extending Approval voting to multiple winner elections have been devised. Among these are proportional approval voting[48] for determining a proportional assembly, and Minimax Approval[49] for determining a consensus assembly where the least satisfied voter is satisfied the most.
Regarding multiple-winner approval voting:So the wiki has a sentence that says it's not good for multi-winner voting (without citation). However following their links shows that multi-winner approval voting is the preferred method of:QuoteApproval voting can be extended to multiple winner elections. The naive way to do so is as block approval voting, a simple variant on block voting where each voter can select an unlimited number of candidates and the candidates with the most approval votes win. This does not provide proportional representation and is subject to the Burr dilemma, among other problems.
Other ways of extending Approval voting to multiple winner elections have been devised. Among these are proportional approval voting[48] for determining a proportional assembly, and Minimax Approval[49] for determining a consensus assembly where the least satisfied voter is satisfied the most.
How much damage can a delegate that turns bad do if they aren't voted out instantly? I feel like bytemaster has said a bad delegate can't do much damage and can't gain much but I would like clarification.
it is very easy for an attacker to max out the bandwidth, forcing other people to pay a higher transaction fee once they want to vote using the stake they received from him (trx fee is per-byte).I think I addressed this by allowing a transaction to simply state "all prior delegate selections are void" It doesn't need to individually specify to not vote for each delegate that was previously selected.
More importantly, storage requirement (not the blockchain, the constructed chain DB) increases to the same amount as it would be if you put the entire new vote set in each transaction.I'm not sure I agree with this either. The constructed database doesn't even have to specify which particular stake each vote comes from, it just needs to collect the aggregate votes for each delegate and then add or subtract from that accordingly.
A bad delegate can:
* exclude transactions
* miss blocks on purpose (delay confirmations)
* exacerbate an current fork by a block
* pay only his supporters out of his income
The last one is the only one that could complicate things. The only stable situations I can imagine are if he would always get voted out in favor of someone paying normal dividends, or if every delegate is paying only his supporters and the situation looks almost identical.
it is very easy for an attacker to max out the bandwidth, forcing other people to pay a higher transaction fee once they want to vote using the stake they received from him (trx fee is per-byte).I think I addressed this by allowing a transaction to simply state "all prior delegate selections are void" It doesn't need to individually specify to not vote for each delegate that was previously selected.
More importantly, storage requirement (not the blockchain, the constructed chain DB) increases to the same amount as it would be if you put the entire new vote set in each transaction.I'm not sure I agree with this either. The constructed database doesn't even have to specify which particular stake each vote comes from, it just needs to collect the aggregate votes for each delegate and then add or subtract from that accordingly.
QuoteA bad delegate can:
* exclude transactions
* miss blocks on purpose (delay confirmations)
* exacerbate an current fork by a block
* pay only his supporters out of his income
The last one is the only one that could complicate things. The only stable situations I can imagine are if he would always get voted out in favor of someone paying normal dividends, or if every delegate is paying only his supporters and the situation looks almost identical.
I think "approval voting" will not reward vote buying. So I'm not worried about delegates only paying their supporters using approval voting. Bad delegates will get voted out even if it isn't immediate and it doesn't seem like they have much to gain by misbehaving.
If all delegates only pay their own supporters the situation is not at all "almost identical." It means that delegates can't give money to a developer or spend money on a marketing campaign that benefits everyone, because their voters just want as much of a kickback as they can get. It's not a good situation. If delegate positions can be bought than someone can buy over 50% of the delegates.
I would be very surprised if we don't eventually move away from the current voting proposal or get out-competed by someone else who does it right. I'm not saying it would be an immediate disaster because there probably isn't anyone interested in creating problems.
Also from a user experience perspective it is way easier to just select the delegates you like, rather than having these trust scores and balancing which stake goes to which delegate and when to downvote etc. It's a turn off, hard to understand, and is flawed anyway. Why try to get people used to it?
+5%
No, I think you can't get around storing the votes because you have to know who to subtract the vote from (or with diffs, who you are allowed to subtract from). I think it is amortized w.r.t. transaction fees paid but it will still increase our max blockchain size by a large constant factor, terabytes instead of 100s of GB.
Let's try to think of a solution to the storage requirements for approval voting.
I am already assuming compression and maximum pruning. A side chain doesn't save space since it is required for validation.
Sent from my SCH-I535 using Tapatalk
I am already assuming compression and maximum pruning. A side chain doesn't save space since it is required for validation.
Sent from my SCH-I535 using Tapatalk
So if you prune the vote sidechain every week (or day) it still blows up so much to be an issue? Wow. I guess I can see that with the possible number of delegates etc. I always kinda assume my suggestions are obvious to you guys, but I post them on the off chance they're not.... never know.
I am already assuming compression and maximum pruning. A side chain doesn't save space since it is required for validation.
Sent from my SCH-I535 using Tapatalk
So if you prune the vote sidechain every week (or day) it still blows up so much to be an issue? Wow. I guess I can see that with the possible number of delegates etc. I always kinda assume my suggestions are obvious to you guys, but I post them on the off chance they're not.... never know.
If you could prune the sidechain every week then you could prune the main chain every week too. As long as you need the sidechain to validate a block then it's pointless to not just include that data in the main chain, the client will need both.
. What am I missing that dictates the voting information has to be stored indefinitely ? Once someone changes their vote why do you need to keep around all the historical votes ?
Toast is right you need to store who everyone is voting for (multiple delegates instead of 1), If you make a transaction that says I only want to vote for delegate 4, You need to know that your stake was previously voting for delegates 1,2,&3 to know who to take votes away from. (sorry, I posted without thinking)QuoteMore importantly, storage requirement (not the blockchain, the constructed chain DB) increases to the same amount as it would be if you put the entire new vote set in each transaction.I'm not sure I agree with this either. The constructed database doesn't even have to specify which particular stake each vote comes from, it just needs to collect the aggregate votes for each delegate and then add or subtract from that accordingly.
No, I think you can't get around storing the votes because you have to know who to subtract the vote from (or with diffs, who you are allowed to subtract from). I think it is amortized w.r.t. transaction fees paid but it will still increase our max blockchain size by a large constant factor, terabytes instead of 100s of GB
1) most users are lazy and will not vote, if they did vote most users wouldn't know how to evaluate delegate performance. This means the voting process needs to be simple with a reasonable automatic voting algorithm based only on statistical data about a delegates performance.Bytemaster, the users you're calling "lazy" are the shareholders and this community! If the shareholders don't care who does? I think you'll find people care more than you think, especially if delegates are paid well. Ignoring poorly designed incentives means you rely on writing a client that votes in a sort of automated altruistic way and hoping people don't care enough to change it. It's like having no mandatory transaction fees but writing a client that pays them by default and hoping people are too lazy to change the default.
3) Voting is a way of exercising your influence over a percent of the block production proportional to your stake via a delegate. It should not result in the majority dictating the rules on who all delegates should be or those with a minority opinion will have no representation among the delegates.I think this tyranny of the majority fear is a misunderstanding. All these institutions and DACs are "majority rules." They are all subject to 51% attacks by the majority. DACs are great in that they allow very low barriers to entry/exit and everyone is part of the DAC by their own volition; it's a free market with lots of options.
It should not result in the majority dictating the rules on who all delegates should be or those with a minority opinion will have no representation among the delegates.
Recognizing this reality, we can embrace it fully and allow 51% of the delegates to fire any other delegate… All networks are only as secure as the trust you place in the 51%.
3) Voting is a way of exercising your influence over a percent of the block production proportional to your stake via a delegate. It should not result in the majority dictating the rules on who all delegates should be or those with a minority opinion will have no representation among the delegates.
Toast is right you need to store who everyone is voting for (multiple delegates instead of 1), If you make a transaction that says I only want to vote for delegate 4, You need to know that your stake was previously voting for delegates 1,2,&3 to know who to take votes away from. (sorry, I posted without thinking)
Maybe people would have less reason to split up their stake to vote for different people?
I think people have to pay an annual registration fee for delegates so maybe this keeps people from registering junk delegates?
Ok, my solution to "lazy" voters. Voters should have: THE RIGHT TO ABSTAIN.
For instance: I am a shareholder but I know that I'm a busy guy with other things going on and there are other shareholders who are more on top of things. I am going to put my shares in cold-storage for a year. I should have the right to send those shares to cold storage in a state of abstention where I am removed from the voting process. It doesn't make sense to have your shares voting for a particular delegate when your shares are in cold storage and you have no idea what the delegate you are voting for is doing. I think this is especially useful for approval voting. I think it will make the system more reactive and efficient.
In the current implementation you could probably just downvote an untrusted delegate on purpose (of course I'm not a fan of current implementation for many previously mentioned reasons.)
Ok, my solution to "lazy" voters. Voters should have: THE RIGHT TO ABSTAIN.
For instance: I am a shareholder but I know that I'm a busy guy with other things going on and there are other shareholders who are more on top of things. I am going to put my shares in cold-storage for a year. I should have the right to send those shares to cold storage in a state of abstention where I am removed from the voting process. It doesn't make sense to have your shares voting for a particular delegate when your shares are in cold storage and you have no idea what the delegate you are voting for is doing. I think this is especially useful for approval voting. I think it will make the system more reactive and efficient.
In the current implementation you could probably just downvote an untrusted delegate on purpose (of course I'm not a fan of current implementation for many previously mentioned reasons.)
Ok, my solution to "lazy" voters. Voters should have: THE RIGHT TO ABSTAIN.
For instance: I am a shareholder but I know that I'm a busy guy with other things going on and there are other shareholders who are more on top of things. I am going to put my shares in cold-storage for a year. I should have the right to send those shares to cold storage in a state of abstention where I am removed from the voting process. It doesn't make sense to have your shares voting for a particular delegate when your shares are in cold storage and you have no idea what the delegate you are voting for is doing. I think this is especially useful for approval voting. I think it will make the system more reactive and efficient.
In the current implementation you could probably just downvote an untrusted delegate on purpose (of course I'm not a fan of current implementation for many previously mentioned reasons.)
You need them to vote by default so that the network is optimized on performance metrics.
What do you think about giving everyone a downvote and an upvote ? You're the one that realized that downvoting has a large opportunity cost if we start to pay delegates much. So what would happen if they added a vote in both directions? I am not pushing the idea, but it is one possible solution. Make either vote optional and independent of each other. It would increase the complexity of the type of games that could be played with voting, but it does remove the one problem of downvotes having opportunity cost.
You need them to vote by default so that the network is optimized on performance metrics.I agree that you want to encourage participation and informed voting (client watches delegate performance and gives voting alerts or auto votes)
How do you vote if you do not have transaction? What I am missing?You don't, voting requires a transaction.
"-Is it as easy to vote out bad delegates?"
Yes. In fact it's much easier to vote out bad delegates than in the current system and much less likely that bad delegates get voted in in the first place. In the current system if someone has enough stake to vote themselves in as a delegate (less than 1% required) it will be next to impossible to get rid of them as a delegate if they want to vote for themselves.
It will take a lot of broad trust to get in in the first place, you have to convince a lot of people that you are a trustworthy, capable member of the community to make the grade. If you betray that trust, I believe your reversal of support will be swift and vigorous."-Is it as easy to vote out bad delegates?"
Yes. In fact it's much easier to vote out bad delegates than in the current system and much less likely that bad delegates get voted in in the first place. In the current system if someone has enough stake to vote themselves in as a delegate (less than 1% required) it will be next to impossible to get rid of them as a delegate if they want to vote for themselves.
I have not gone into the details of your voting system (yet) but it is guest like the regular ‘majoritarian voting system’ – over 50% of votes you are in, less you are out.
In that system voting out somebody is not direct. It is more voting somebody else in, which is my main concern i.e I kind of like ‘direct firing’ of bad actors/delegates.
Dan and I talked some more over dinner today and I think we have won him over.
Once he was convinced that there is unlikely to be a large honest stakeholder who does nothing but downvote bad delegates at huge opportunity cost then cat&mouse becomes unsolvable and that is the core issue behind all the reasons Agent86 listed. After thinking through some possible transaction compression techniques and realizing that it only makes the transaction about 3x as large, I am happy to announce that we are probably going to go with approval voting.
Some things to discuss: Should you still be able to downvote delegates with your stake? We are leaning towards yes but have not thought through it very carefully.
x-posting from here: https://bitsharestalk.org/index.php?topic=5164.msg68359#msg68359Dan and I talked some more over dinner today and I think we have won him over.
Once he was convinced that there is unlikely to be a large honest stakeholder who does nothing but downvote bad delegates at huge opportunity cost then cat&mouse becomes unsolvable and that is the core issue behind all the reasons Agent86 listed. After thinking through some possible transaction compression techniques and realizing that it only makes the transaction about 3x as large, I am happy to announce that we are probably going to go with approval voting.
Some things to discuss: Should you still be able to downvote delegates with your stake? We are leaning towards yes but have not thought through it very carefully.
x-posting from here: https://bitsharestalk.org/index.php?topic=5164.msg68359#msg68359Dan and I talked some more over dinner today and I think we have won him over.
Once he was convinced that there is unlikely to be a large honest stakeholder who does nothing but downvote bad delegates at huge opportunity cost then cat&mouse becomes unsolvable and that is the core issue behind all the reasons Agent86 listed. After thinking through some possible transaction compression techniques and realizing that it only makes the transaction about 3x as large, I am happy to announce that we are probably going to go with approval voting.
Some things to discuss: Should you still be able to downvote delegates with your stake? We are leaning towards yes but have not thought through it very carefully.
I am totally not surprised by this development.
Too bad there's no prediction market for these things