@SrPoliloco First, I didn't call you a liar, and I'm very sorry you took it that way. Saying that a position you're asserting is "not true" doesn't mean you're a liar, it simply means you may not be dealing with good information; to me there's a big difference. I was saying that there's a lot of information going around that is not entirely accurate, being posted by people that don't always understand the whole picture. It is *still* not clear that the frozen funds from the soft fork will *require* a hard fork to free them. Many possibilities continue to be investigated by the devs. Again, I apologize for offending you, but that was certainly not my intention.
I am inclined to vote yes for both a soft and/or hardfork. I am particularly interested in the ethpool mining ramifications. I suppose we are voting yes without knowing exactly which soft fork will be used? I am following the Ethcore blog post. Would the fork be a "Dao Rescue Bounty Contract" where miners receive greatly increased rewards for a short period of time?
If this is the case I am concerned about voting yes, specifically because I mine on ethpool which rewards pool members under the credit system, so it seems that I could be mining on the pool but then still miss out on some of the "extra-reward blocks".
Do you have any plans to distribute the extra bounty evenly with the pool, if we do indeed go with this type of fork?
@Amazing This is the active part of the withdraw-DAO code that will replace the current DAO bytecode....
contract DAO is DAOInterface, Token, TokenCreation { /// Just withdraws the weiGiven of the msg.sender, recording /// that no more should be given on subsequent calls. function() { // Figure out how much to return. var r = weiGiven[msg.sender]; // Clear now, so that all subsequent CALLs return nothing. weiGiven[msg.sender] = 0; // Send back the refund to caller. msg.sender.send(r); }
While the interface is exactly the same as the DAO,function() is the only function and is the default function of the Withdraw-DAO contract. This means simply calling Withdrawal-DAO with the account that held tokens in the DAO will return all eth that was sent from that account, apparently during the DAO creation, and not from the state of token balances just prior to the attack. If this is what they actually fork to, it would seem to me that post creation DAO trades would be written off and the original holder is returned ether from tokens they may already have sold....
What ever way this goes, seems Shylock still gets his pound of flesh... more or less.
Already posted this question at the other thread before i remembered that this thread excisted, so repeating the question here.
So with the geth 1.4.8 out, when will you be making the decision to soft-fork or not to? Just asking as to when to expect that announcement, i think there should be adequate time given for people on either side of the vote to change their pool if they desire.
Has their still been no word on when/if Minergate will implement Ethereum DAO voting? They are my preferred miner, but if no word soon I will have to switch over to this pool.
@mksmart, The fork will have a gas limit of Pi Million. The graph apparent shows the evolution of the gas limit up to block 1,800,000 at which point the fork will activate (or not)
According to the current results of the Voting the pool will implementiert the soft fork. More info will follow tomorrow.
There is plenty of time to implement the fork, if 51% of all miners implement it it will take ~ 1 day to lower the gas limit to < 4M. If 100% implement it it will take ~30 mins.
ProFork : 57404 MH NoFork : 17223 MH Don't Care : 1994 MH Not voted : 229242 MH
That makes only 18,76 % of the total hashrate voting for a change from status quo. So why should 100% of the hashing power from this pool be used to enforce the will of the 18,76 %?
That doesn't seem fair or democratic to me.
Considering the blockchain consensus, shouldn't "Not voted" count as "leave it at status quo" instead of "doing what others want" which is actually represented with the "Don't care" option?
@PuebloZag That is definition of being democratic. When you vote for a proposition or funding bill or whatever, you vote yes or no or you don't go to the polling station. The people that don't go to the polling station aren't counted as voting no.
The miners that haven't voted simply don't care or already see that it's a landslide and don't feel they need to vote. People are lazy. I don't want this to sound harsh but you can always vote by going to another pool that represents what you believe.
I just realized that it's indeed democratic and that my problem lies more with the concept of democratic voting itself, as it doesn't seem fair to me that it should be possible for less than 51% to win a vote because someone didn't go cast a vote. Maybe they don't care, but it is also possible that some couldn't cast a vote due to various reasons, even if they actually wanted to.
Unfortunately I don't have a good solution for that problem.
I just realized that it's indeed democratic and that my problem lies more with the concept of democratic voting itself, as it doesn't seem fair to me that it should be possible for less than 51% to win a vote because someone didn't go cast a vote. Maybe they don't care, but it is also possible that some couldn't cast a vote due to various reasons, even if they actually wanted to.
Unfortunately I don't have a good solution for that problem.
They still have the option to join a pool that supports their voting choice, simple as that. If they've been able to join a pool that has/had voting implemented, means that they are capable of joining a pool, therefore they are capable of changing the pool to reflect their voting choice.
ethpool now has also been updated to the latest geth version with the soft for code enabled. this concludes the voting process. Thanks to everybody for participating in the vote and voicing their opinion!
Okay guys, I am really scared right now. Since only 26.7% of the miners voted (21% for yes, 5.6% no), I see a high probability that the outcome would have been another if @Genoil s suggestion was implemented, in which not voting is equal to "no-fork". The rationale behind counting no-votes as "no-fork" (or status-quo) is that we are not holding an election here but rather a referendum, which usually has some overall yes-vote to take, instead of only the majority of votes. If we assume that a big portion of the 73.3% of miners will never vote, that means essentially, that the way the vote is held, will favor the one or the other outcome, giving pool operators the possibility to take an advantage. I also think that the fact I described is the reason some anti-forkers call this a centralized decision, and they are right in a way. This is why I would like to see the community to hold referendums instead of elections on fork questions from now on, so that pool operators cannot be alleged of influencing, in order to increase trust in the ethereum community and especially possible future forks. In other words, I am asking for a quorum next time, although I cannot think of a way to determine a good value for it. (Maybe weak) assumptions made: most of non-voters will never vote; completely ignored the weighting by hashrates.
TLDR: Pool operators can heavily influence a vote as long as there is no quorum.
@cellard0or If someone didn't care enough to cast a vote, why would they care enough to actively change the URL they are mining against to make a choice? Are you saying that apathy should be the determining factor in major network events like forks, where, by your reckoning, the default action is to not support the recommended course of action (there always is one)? I'm guessing you didn't support the soft fork.
Actually, I supported the soft fork, but there was some itching thought which I could not articulate until today. You are absolutely right that apathy should not drive the course of events but still, I am a bit uneasy with some few people having the power to decide what the recommended action should be. I mean in case a pool operator invested in the DAO, it is clear which action he/she would recommend..
Comments
If this is the case I am concerned about voting yes, specifically because I mine on ethpool which rewards pool members under the credit system, so it seems that I could be mining on the pool but then still miss out on some of the "extra-reward blocks".
Do you have any plans to distribute the extra bounty evenly with the pool, if we do indeed go with this type of fork?
contract DAO is DAOInterface, Token, TokenCreation {While the interface is exactly the same as the DAO,/// Just withdraws the weiGiven of the msg.sender, recording
/// that no more should be given on subsequent calls.
function() {
// Figure out how much to return.
var r = weiGiven[msg.sender];
// Clear now, so that all subsequent CALLs return nothing.
weiGiven[msg.sender] = 0;
// Send back the refund to caller.
msg.sender.send(r);
}
function()is the only function and is the default function of the Withdraw-DAO contract. This means simply calling Withdrawal-DAO with the account that held tokens in the DAO will return all eth that was sent from that account, apparently during the DAO creation, and not from the state of token balances just prior to the attack. If this is what they actually fork to, it would seem to me that post creation DAO trades would be written off and the original holder is returned ether from tokens they may already have sold....What ever way this goes, seems Shylock still gets his pound of flesh... more or less.
So with the geth 1.4.8 out, when will you be making the decision to soft-fork or not to?
Just asking as to when to expect that announcement, i think there should be adequate time given for people on either side of the vote to change their pool if they desire.
https://etherchain.org/statistics/dao
There is plenty of time to implement the fork, if 51% of all miners implement it it will take ~ 1 day to lower the gas limit to < 4M. If 100% implement it it will take ~30 mins.
ProFork : 57404 MH
NoFork : 17223 MH
Don't Care : 1994 MH
Not voted : 229242 MH
That makes only 18,76 % of the total hashrate voting for a change from status quo. So why should 100% of the hashing power from this pool be used to enforce the will of the 18,76 %?
That doesn't seem fair or democratic to me.
Considering the blockchain consensus, shouldn't "Not voted" count as "leave it at status quo" instead of "doing what others want" which is actually represented with the "Don't care" option?
The miners that haven't voted simply don't care or already see that it's a landslide and don't feel they need to vote. People are lazy. I don't want this to sound harsh but you can always vote by going to another pool that represents what you believe.
I just realized that it's indeed democratic and that my problem lies more with the concept of democratic voting itself, as it doesn't seem fair to me that it should be possible for less than 51% to win a vote because someone didn't go cast a vote. Maybe they don't care, but it is also possible that some couldn't cast a vote due to various reasons, even if they actually wanted to.
Unfortunately I don't have a good solution for that problem.
If they've been able to join a pool that has/had voting implemented, means that they are capable of joining a pool, therefore they are capable of changing the pool to reflect their voting choice.
The rationale behind counting no-votes as "no-fork" (or status-quo) is that we are not holding an election here but rather a referendum, which usually has some overall yes-vote to take, instead of only the majority of votes.
If we assume that a big portion of the 73.3% of miners will never vote, that means essentially, that the way the vote is held, will favor the one or the other outcome, giving pool operators the possibility to take an advantage. I also think that the fact I described is the reason some anti-forkers call this a centralized decision, and they are right in a way.
This is why I would like to see the community to hold referendums instead of elections on fork questions from now on, so that pool operators cannot be alleged of influencing, in order to increase trust in the ethereum community and especially possible future forks. In other words, I am asking for a quorum next time, although I cannot think of a way to determine a good value for it.
(Maybe weak) assumptions made: most of non-voters will never vote; completely ignored the weighting by hashrates.
TLDR: Pool operators can heavily influence a vote as long as there is no quorum.
I would be happy if someone proved me wrong