If you mined this block, your client added the pubkey for 14217.
It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:
So if I mine a block I can add any pubkey I want. Correct? No. Its a trustless solution. Its in the code. Then why in the world is there voting code in stratum? Voting result(verified again) should be written to blockchain, that miner do. In RC4 'Masternode payment votes in blockchain' will be removed. https://darkcointalk.org/threads/status-update-7-1-2014.1675/In the works for RC4:
Removal of Masternode payment votes in blockchain
Addition of Masternode voting consensus system
Live ‘spork’ for enforcing consensus system
Anonymity enhancements
For a more detailed explanation of the changes to the Masternode consensus protocol,
please check out the “New Enforcement Strategy” section in this article: goo.gl/pDG9W3
So that can be removed in RC4, then all that's left is giving the masternodes their cut, please see the Freicoin source for a better way to do this. Then you can go back to using standard stratum. Edit: I'm wrong, the transaction to pay the masternode still needs to be included in the block hash. So yes this will require stratum mods either way. |
|
|
|
If you mined this block, your client added the pubkey for 14217.
It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:
So if I mine a block I can add any pubkey I want. Correct? "If you mined this block, your client added the pubkey for 14217." this means a vote, not payee for current block. Each vote in a block will be verified at network. If a vote has six network confirmation, next block will pay the vote. So it's not really a vote at all. As far as I can tell by the code, all it is is a check to make sure the masternode stays online for 6 blocks. Again, why should it be in stratum? |
|
|
|
Glad to see coinmine.pw (not to be confused with coinmine.pl, also fine) are fully update !! I love that pool. Freaky at first, but WOW did that boy do some serious programming... anyway. Unfortunately, just sniffed out another non paying pool. By the way, I think Splawik21 got BANNED from the #Blackcoin pool channel for going there and suggesting they update!! Can you believe this?! C'mon poeple, do your part please As you can see, our efforts are working!! Since Coinotron updated fully (yesteraday), and being one of the bigger pool, MN payments went up sothing like 10%  So please please please folk, contact your pools via IRC, webform or mail ! Special shout-out to Splawik21, we're like Batman and Robin here. Some more help would be appreciated! https://darkcointalk.org/threads/just-had-an-idea-for-us-miner-collectively-help-drk-before-next-fork.1662/These pools_unknown a REALLY pissing me off, espceially not knowing who they are. I'm sure a few are not private, we're just haven't sniffed them out. Look at the last column, which is the one that counts.  Please update your list to reflect the fact that Multipool is in the process of updating, I don't need to be harassed by people who aren't reading the thread. |
|
|
|
If you mined this block, your client added the pubkey for 14217.
It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:
So if I mine a block I can add any pubkey I want. Correct? No. Its a trustless solution. Its in the code. Then why in the world is there voting code in stratum? |
|
|
|
If you mined this block, your client added the pubkey for 14217.
It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this:
So if I mine a block I can add any pubkey I want. Correct? |
|
|
|
- You have to mine a block to vote, the software will automatically vote for the current masternode to get paid.
- You can only enter a new candidate for the block you mined
- You can vote on all other candidates in the previous block
- You can only up vote (+1 to the total)
- If an entry has 5 votes, a new payment is made on the next block (that miner has no choice)
- If a candidate doesn't reach 5 votes in 10 blocks, they're removed.
Hoping to launch some serious testing next week on testnet. Still working out the bugs.
I also modified the block explorer so we can see the votes that are stored in the blockchain.
I'm sorry but you're still not telling me how the current masternode to get paid is determined. Yes, I understand it was determined when the previous block was generated, and is now in getblocktemplate, and when the next block is generated, the software will automatically vote for it, but how was it actually determined in the first place? |
|
|
|
pubkey of payee ?
It's on getblocktemplate
Yes but how is it determined? |
|
|
|
Someone explain to me how this voting works, is it random or what?
i.e. what's to stop me from setting up my own masternode and voting for it in all the blocks Multipool finds, or selling my votes to someone?
Question : https://darkcointalk.org/threads/help-test-rc2-forking-issues.1009/page-12#post-6973Evan's answer : https://darkcointalk.org/threads/help-test-rc2-forking-issues.1009/page-13#post-7060Thanks for the super detailed report. So what you posted actually looks fine. I'll try to explain what's happening. Block 14217 Blockheight Pubkey Votes
14214 fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o 2
14215 nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE 3
14216 QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk 2
14217 Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv 1
If you mined this block, your client added the pubkey for 14217. It's also allowed to increment each existing vote by one if it agrees with it. So the code goes something like this: On block 14214 was the pubkey to be paid fgAKRZmRDp53yEPegeBGu3bKmH2pYjM4o? If yes increment votes from 1 to 2 If no and votes=1, change pubkey to the correct one and don't vote (this only can happen get no voting has happening and it looks incorrect) On block 14215 was the pubkey to be paid nyua6yT2XjttboGdjLdNMWZqSmrtqHeUE? If yes increment votes from 2 to 3 If no, don't vote On block 14216 was the pubkey to be paid QSp8gRBSez2Y6MQCgGSiMsoKxnsa9HVVk? If yes increment votes from 1 to 2 Added block 14217, pubkey Z92SLSwb3z2D47g47Y1E9LczimJiVFtvv, votes 1 Thanks but this doesn't explain where the pubkey to add is coming from. |
|
|
|
Alright cheers, I'm forwarding this to my engineers to see if we could make this work.
We are adapting. The point is via lazy coding you are increasing the number of headaches in my life and I have enough already.
Dear fellow DRKheads, these guys do have a point, stop ragging on them so much. Maybe someone with Evan's ear might mention these issues and see what might be done in future to improve the situation? The whole ecosystem needs to be supported, not just our particular favourite parts of it, anything that can be done to help should be considered.  To expand on this, if you are looking for mass adoption, you want every part of the system to be accessible. Pools do centralize, but fewer pools means more centralization. So creating barriers or unnecessary complications for pools is a bad idea. The ideal situation would be to have the coinbase payments handled within the wallet (and return to me an accurate coinbasevalue when I pull the blocktemplate, with the masternode payout already removed), and have the voting stuff be optional (looks like you have already done that). It seems extremely clunky to me to have stratum-mining be responsible for generating masternode payments. That said, I am intrigued by this voting system and would like to hear more about exactly how it works. There is not much information publicly available about it (other than that it exists.) |
|
|
|
|
Someone explain to me how this voting works, is it random or what?
i.e. what's to stop me from setting up my own masternode and voting for it in all the blocks Multipool finds, or selling my votes to someone?
|
|
|
|
|
Having a working testnet would also help with integration. Does anyone have a testnet addnode? My wallet won't connect.
|
|
|
|
{SNIP}
Multipools support so many coins, and every coin has their way of doing things, and we already have such a huge headache from avoiding forks, mandatory updates (across 40 wallets!!) that when a coin comes along and is like "Hey now you also need custom code, or a stratum update" it throws quiet the fork in to our operations. We don't follow your coins directly (at least I don't) but we are more than happy to comply and make sure your eco system is working-- just make it easy and clear for us to do so, because we have to do it across MANY MANY coins every day.
That's like complaining that you run a travel agency and each airline has different policies and keeping up with them is SUCH a burden. I mean, isn't it kind of obvious that dealing with dozens of coins is going to be challenging? +1 Have you guys thought about that hostility isn't helping your/our case right now? Seriously! Well since my case is 'this is idiotic' I'm hard pressed to find a way to express that without any hostility. |
|
|
|
{SNIP}
Multipools support so many coins, and every coin has their way of doing things, and we already have such a huge headache from avoiding forks, mandatory updates (across 40 wallets!!) that when a coin comes along and is like "Hey now you also need custom code, or a stratum update" it throws quiet the fork in to our operations. We don't follow your coins directly (at least I don't) but we are more than happy to comply and make sure your eco system is working-- just make it easy and clear for us to do so, because we have to do it across MANY MANY coins every day.
That's like complaining that you run a travel agency and each airline has different policies and keeping up with them is SUCH a burden. I mean, isn't it kind of obvious that dealing with dozens of coins is going to be challenging? No, it's not like that at all. The masternode payments code does not belong in the mining software, and should not depend on the mining software. It's making an issue for pool owners where there should be none. |
|
|
|
I wasn't even aware stratum updates were required until about 20 minutes ago. I am asking my developer to merge the changes now.
However, I still think this is stupid and should be done in the wallet code.
Great, thanks for looking into it! I agree that this could have been communicated in a more transparent way. And I see that stuff like this is a huge pain for pools using custom stratum solutions (i.e. multipools).Then once enforcement starts...its a feature  We shall see. I'll be here to say "I told you so" when I see the "EMERGENCY UPDATE FOR MASTERNODE PAYMENTS EXPLOIT" emails going out in 3 months. |
|
|
|
I'm thinking that if.....
....if I am reading TheBlackDoge correctly
You run custom pool software - correct
Then getting DRK software to run on your system would be your issue and not a DRK issue
Introducing a gratuitous incompatibility that makes it harder for pools to mine your coin is a DRK issue as well. Pools are an adaptation to decentralised crypto? Adapt, n'est-ce pas? We are adapting. The point is via lazy coding you are increasing the number of headaches in my life and I have enough already. |
|
|
|
I'm thinking that if.....
....if I am reading TheBlackDoge correctly
You run custom pool software - correct
Then getting DRK software to run on your system would be your issue and not a DRK issue
Introducing a gratuitous incompatibility that makes it harder for pools to mine your coin is a DRK issue as well. |
|
|
|
We support like 40 coins, all of them have something bubbling, for none of them do we have update stratum code unless it's a new algo. First we were told we just needed to update client, which we complied with as fast as we could. If some one could point to some clear instructions on what needs to be done, we would attempt to comply, but so far nothing (something beyond then just "update NOMP" as we have to write the solution custom ourselves.)
Hi, I have to agree with this, there should be no stratum modifications necessary for the masternode payments, they should be done within the coin wallet code, there is code already out there for this, check freicoin or other coins that have automated donations. People are going to exploit this to steal masternode payments. I guarantee it. I can't see how once it's enforced. Care to elaborate ? Blocks not including payment or ones attempting to tamper with it will be orphaned as far as I understand. Yes. That's why I don't understand his statement. It leaves this open as an attack vector. If there is any flaw in the enforcement code it can be exploited. If the code isn't even there yet then it can potentially be exploited right now. |
|
|
|
Thanks for the view from the other side. Yes, the instructions could have been better. On the other hand, the majority of pools managed to implement the MN and surprise surprise - they still mine the coin even when the rate is lower by 20%. However, their compliance is putting them into disadvantaged positions against your pool so it is unlikely this situation will last much longer.
Look we have no problem complying, but 95% of those pools just had to update to the latest version of NOMP (the solution was provided for them) we have to write it custom. We would pay the 20%, and work it in to our formula-- but like I said instructions were not clear, even after we scrubbed through this thread and the darkcointalk one. This is coming from my engineers who spent like the better part of yesterday looking in to trying write in compliance. [/quote] Thanks for coming here and clarifying your points, much appreciated. Up until now I was under the impression that greed is the only factor for not paying the MN :-) [/quote] I wasn't even aware stratum updates were required until about 20 minutes ago. I am asking my developer to merge the changes now. However, I still think this is stupid and should be done in the wallet code. |
|
|
|
We support like 40 coins, all of them have something bubbling, for none of them do we have update stratum code unless it's a new algo. First we were told we just needed to update client, which we complied with as fast as we could. If some one could point to some clear instructions on what needs to be done, we would attempt to comply, but so far nothing (something beyond then just "update NOMP" as we have to write the solution custom ourselves.)
Hi, I have to agree with this, there should be no stratum modifications necessary for the masternode payments, they should be done within the coin wallet code, there is code already out there for this, check freicoin or other coins that have automated donations. People are going to exploit this to steal masternode payments. I guarantee it. |
|
|
|
|
So after the transaction was rebroadcasted wouldn't it show up as confirmed? Why is it still showing conflicted?
|
|
|
|
|
Show Posts
?? - 
