*SNIP* - Yeah, sorry for walls of text.
Am I missing something here? Where is such an "announcement" stored? A masternode can only sign its ping with its provided private key, which has no relation to a DRK address holding 1k except via signed message by the actual address giving authority for said masternode key to act on its behalf.
Am I missing something here? Where is such an "announcement" stored? A masternode can only sign its ping with its provided private key, which has no relation to a DRK address holding 1k except via signed message by the actual address giving authority for said masternode key to act on its behalf.
Yes, and such a message could be put into the blockchain and act as the 'initialization' transaction for a MN. This ties the 1000 DRK to the public address of the MN. From that point on, the 1000 DRK will be watched, and if it moves then the MN will have to be re-initialized before it is capable of being paid again.
Frankly I'm kind of surprised/shocked that such a thing is not already being done. (Although I have been keeping up with DRK for a long time, I have never really looked into implementation details of MNs....) No wonder RC3 had so many damn forking problems! Valid MNs need to show up in the blockchain somehow, otherwise how will you ever have consensus what's a valid MN?
Quote
Perhaps the solution is to have additional space in the blockchain for storing these messages (this is what you were thinking all along, isn't it (you're a genius!))? They'd exist for all eternity unless pruned at some point in the future (though that would need some workaround to keep the blocks paying them in the past valid when the evidence of their being a masternode is removed), but I'm not sure that matters... You would actually be able to make a "list" of sorts then based on the messages in the blockchain, but it wouldn't vary at all from node to node!
Now you get it.
Quote
Assume the same address could initiate a stop command in a future block to not have his old MN clutter up the payments by never responding. However, I don't see any incentive for people to do this, so there needs to be some mechanism where the block finder can insert the stop message on behalf of the masternode. You might think the lingering nodes wouldn't be an issue, but something absolutely has to be able to issue a "stop" command in case the 1,000 DRK move. Unless you could possibly modify the protocol to have nodes reject any tx formed out of the 1,000 DRK input without a "masternode stop" command included in a prior block? If you allow for removal after X number of missed pings, you have the (tiny) vector of the block finder being able to remove a masternode if he found the right blocks, but I don't know of any incentive to do this.
Well, no, I think you're over-complicating things here. There are really kind of 2 lists: one for "valid" MNs and the other for "active" MNs. By creating an initialization transaction and putting it into the blockchain, a MN declares itself as "valid". It remains "valid" for as long as the 1000 DRK does not move. This means that it is *capable* of being nominated and receiving payment, *if* it proves itself to be "active". Upon nomination by block n, it has to ping back in or before block n+2. This proves it as being "active" and eligible for receiving payment in block n+3.
A MN maintains its "active" status as long as it keeps responding to all nominations with pings in a timely manner. If a MN does not respond in time to a nomination, it will be marked un-"active" until the next time that it responds to a nomination. That "activating" ping will bring it back to the "active" list, but it will not be eligible for payment in that block because it was non-"active" for the previous nomination. And again, all of this information will be 100% determinable in the blockchain.
Quote
Now we're just stuck with n block finder (that happens to have his node in the list of candidates) pretending he didn't get pings from some or all of the other candidates. Perhaps this vector is small enough to just discard.
That's the point of having the nomination take place by the hash of block n, and valid+active MNs have to get their "ping" transactions inserted into either block n+1 or n+2. (Maybe this should be lengthened to 3 or 4 or 5. It would require some testing and modeling.) Presumably block n+1 will not be mined by the same miner as block n+2. And then block n+3 is the one that actually makes payment to the winning MN. (Although maybe the payment should actually happen in block n+4, with the winner being determined by the hash of block n+3. So block hash n+3 declares the winner out of the pinging MNs in blocks n+1 and n+2, and n+4 must pay. This may be better than having the block hash of n+2 determining the winner, and being paid in n+3.) The winning MN must be one of the MNs who validly pinged in block n+1 or block n+2 and whose nomination matches block n. It's all right there in the blockchain, so there's no way for anybody to cheat.
And the likelihood of the miner of blocks n, n+1, n+2, and n+3 all being the same person, and happening to be one of the MNs nominated by the hash of n, is so small as to be negligible. I mean this is basically somebody who is 51% attack capable, so we would all be screwed anyway. And as long as the MN payment remains small relative to the block reward (4 DRK to miner, 1 DRK to MN per block) there would be no incentive for a miner to withhold a block in order to wait until he found one that nominated one of his own MNs. Give up 4 DRK in order to possibly earn 1 DRK? It just wouldn't make sense.
I suppose the only way this can really be attacked is by a malicious miner not including any ping transactions in blocks that he mines. This would unduly penalize MNs who don't deserve it. Such an attacker would throw a monkey wrench into the system, but they could not profit from it since the MN payment must still be included in every block.
You have almost described how the current system already works.
The 1000DRK for each MN already live in the blockchain, and those addresses are monitored.
MN votes already accumulate over multiple blocks.
And MN comms are, need to be and will continue to need to be far faster than the 2.5 min average block time.
I realize that the system has similarities. What I believe is novel is the (snipped) "nomination" system based on the hash of the block, the need for the nominated MNs to respond with blockchain-writable transactions within 2 blocks of being nominated, and the deterministic picking of a "winner" based on the responding MNs. This negates the need to maintain an off-blockchain "list" of active MNs, which I believe is what caused the forking problems in previous releases, where some nodes were rejecting blocks off of a belief that the MN receiving payment was not a valid MN, for whatever reason. You can see this in all the questions about "is my MN appearing ok?" It should not be possible for one person's list of active MNs to be different than another person's, yet I believe that this is what we still have today. "I'm seeing 850 active MNs but Joe sees 842" is a very difficult problem to solve, so my proposal moves all MN "activeness" into the blockchain where it becomes indisputable.
