This one bugs me for a while now because why serialize the payments history when it's already in the blockchain?
- Writing technology for serializing the Masternode Payments history (to improve the reference nodes accuracy)
So I wrote a little script and invite everyone to pick the algorithm apart for flaws and/or things a Masternode can't do internally:
- masternode list | grep "ENABLED": we now have the IPs of all enabled Masternodes
- masternode list pubkey: we now have the IPs and pubkeys of all Masternodes. Throw away the ones not in 1.
- Scan the blockchain backwards for a certain window of blocks, e.g. 3x number_of_masternodes or whatever is doable with acceptable performance. Select the one with the oldest last payment as payee. All Masternodes should easily find consensus in this case.
- if one or more Masternodes (new ones) don't have a payment in that window chose randomly one of them as payee. If it's TOO hard to find consensus this way we can simple use the one with the lowest IP/pubkey/whatever. It's statistically not an advantage.
1+2 are more or less trivial to implement inside a Masternode, the tricky part is to do 3. with acceptable performance.
Well, Evan announced somewhere that the proof of service (PoSe) for Masternodes could include tests for available RAM, CPU speed and whatnot...so keeping this blockchain-window in memory to speed up 3. would be an useful PoSe test.
Another point which might be a problem: how to avoid "pubkey hopping" (© crowning), means someone simply changes the pubkey of a Masternode after each payment to look like a new Masternode?
Well, with a new pubkey you'd have to move your 1000 DASH payment there. And the vin of this payment has a timestamp. We could just check the timestamp of the vin. If it's inside our history-window (or newer than all other payee-candidates, whatever works best) the Masternode will not be (yet) selected as payee because it's obviously too new.
Thoughts? Flaws? Free beer for crowning?