[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[Macno]

A friend just sent me this about XMR:

http://da-data.blogspot.de/2014/08/minting-money-with-monero-and-cpu.html

I don`t quite get it, but is this positive or negative for XMR? I`d guess negative (I`d be pissed as a regular Miner), but maybe I don`t get it.
I hope stuff like that is not possible with DRK.

[Jungian]

A friend just sent me this about XMR:

http://da-data.blogspot.de/2014/08/minting-money-with-monero-and-cpu.html

I don`t quite get it, but is this positive or negative for XMR? I`d guess negative (I`d be pissed as a regular Miner), but maybe I don`t get it.
I hope stuff like that is not possible with DRK.

What happened is:

Bytecoin (BCN) took a launched a new currency and completely butchered it. They made it into a premine scam to make it easy money.
Funny thing is: It's actually good tech, and they could have made a killing in scene, but instead they went for the easy buck.
The Monero (no affiliation with the BCN team) team forked this scam. Cleaned up the code and relaunched in fair way.

The blog writer (who writes here under the name 'dga') is quite pro-Monero. You can read his post history yourselves. All the negatives was related to BCN.

[salmion]

Sorry can we stick to DRK here please?

There are enough monero threads/shills everywhere in bitcointalk.

X11 optimisations come out periodically. See latest sgminer. Judging by the heat levels of my rig it's pretty close to max.

[innergy]

We need China 

[coins101]

I think I will set-up a second DRK foundation - it's goals:

1. Make Master Node Operators Rich
2. As above

 

Having read the works of Isaac Asimov, I'm fairly sure you're not supposed to let the first foundation become aware of the Second Foundation for this to work.

This has caused something of stir that I wasn't expecting. I've quite a few PMs asking when this will be put in place

But thinking about it, the issue of the Darkcoin foundation and the Master Nodes is worth considering, IMO.

There were several people who, quite rightly, raised some concerns about DRK the currency, vs. DRK the platform for making money off other services.

Lets face it, platform or no platform Master Nodes are now central to DRK's future success. Their operations can't be impacted too much by a foundation - they are supposed to be the unknown and independent agents of DRK (there is a film there somewhere). They can't join the foundation on mass and declare they have Master Nodes.

The Bitcoin foundation has caused some rifts within the Bitcoin community. But so what? Bitcoin is code. Bitcoin Foundation is talk. Talk is cheap, Bitcoin code isn't.

The real value of a foundation is to put out the correct information, engage to correct any misinformation and to be an advocate.

Master Nodes are now a union. If they do or don't like something they can vote by switching off or increasing in number; that is an indication of whether policies are right or not.

This goes for DRK as a currency too.  

A few thousand pages back there was a discussion about launching a clone of DRK to reduce the impact of other clones. The price of DRK went down, the idea was quickly scrapped (since then we've had every man and his dog launching an anon coin).

This is a lengthy way of saying - I was joking. I am not starting a MN foundation.

But, I still think we should launch a Web 3.0 service for MNs and have all adult content on it. The media and governments would love it. No more accidental images for children to see. Access controls for adult content. Search engines forced to pay MNs to crawl the network and a percentage of revenue to put up their adWords (fuck me we could make a killing just off that bit).

MN operators would become millionaires overnight from the domain name sales, the hosting by adult content providers, the cut on revenue from those that would promote on the network. It would be a free service to users, but not free to those that make money on it.

I think the media would get behind this and they would force politicians to draft laws to force content providers to move to Web 3.0 - the over 18s internet.

The Make Master Nodes Rich Act 2015

This time next year, we'll be rich, I tell you, rich, rich, rich.

[salmion]

We need China 

We need adoption. opensource coming soon will certainly help that.

Be interesting to see how many more devs come on board with bright ideas.

We have some time before iris/darktor so may as well start asking around.

Coins101 - your approaching the gamblers I believe is spot on.

Commence dark use.

[coins101]

We need adoption.

I think we need the right kind of adoption. Merchants seem to be leeches on the price. lol.



People put money into crypto, they buy stuff with their crypto, and the merchants exchange it back for fiat. Reverse pumping. Who knew.

I think this points the way to adoption that has a net contribution to value - fiat being exchanged for DRK (Web 3.0, I know - I'm flogging it as much as possible  ).


#I am looking forward to the mega pump that will come when ETF - ie. pension funds - money starts investing in Bitcoin.

I seriously think we can launch something investable if we have some way to get MN income into an SEC passable entity.

[Terzo]

Adoption and price rise want happen at the same day of RC5 open source .
We are going to need some time . I'm afraid that the week hands are going to sell at the day of RC5

[salmion]

We need adoption.

I think we need the right kind of adoption. Merchants seem to be leeches on the price. lol.



People put money into crypto, they buy stuff with their crypto, and the merchants exchange it back for fiat. Reverse pumping. Who knew.

I think this points the way to adoption that has a net contribution to value - fiat being exchanged for DRK (Web 3.0, I know - I'm flogging it as much as possible  ).


#I am looking forward to the mega pump that will come when ETF - ie. pension funds - money starts investing in Bitcoin.

I seriously think we can launch something investable if we have some way to get MN income into an SEC passable entity.

Absolutely I'm not talking about Dell. I'm talking about small businesses, who might keep some of their profits in dark.
Gamblers and gambling sites (some of these not small) definitely fall into this category. I think you mentioned the adult industry.
Things that are in some countries socially frowned upon. With the official Russian government stance on bitcoin darkcoin will be a far better coin to use there.
My point being adoption is a way bigger term than <insert big retailers name> accepts it. They are the ones who will dump for fiat. It's the other cases where coins will be traded and not necessarily for fiat. The edge cases, societal cases where ecash is most needed.
 

[tungfa]

But, I still think we should launch a Web 3.0 service for MNs and have all adult content on it. The media and governments would love it. No more accidental images for children to see. Access controls for adult content. Search engines forced to pay MNs to crawl the network and a percentage of revenue to put up their adWords (fuck me we could make a killing just off that bit).

this is a really good thought !!
a Darknet, DarkTor,.... whatever network, but true
we can totally control any access regarding age groups and clientele
This is a 'positive' angle on a dark world i have NOT thought about
 

[tungfa]

There is nothing like Masternode payments !!
You have your coffee in the morning, check your MN's
and there it is  ... X MAS every time !
Love it
 

[TsuyokuNaritai]

The media and governments would love it. No more accidental images for children to see. Access controls for adult content

we can totally control any access regarding age groups and clientele

How do you reliably filter out age groups without centralization or compromising principles of anonymity, without there being any slip-ups that media and governments would immediately jump on to demonize the whole thing?

[baddw]

*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.

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?

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.

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.

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.

[coins101]

The media and governments would love it. No more accidental images for children to see. Access controls for adult content

we can totally control any access regarding age groups and clientele

How do you reliably filter out age groups without centralization or compromising principles of anonymity, without there being any slip-ups that media and governments would immediately jump on to demonize the whole thing?

Adults will probably need to take some actions to enable an adult internet.

Getting access codes via something like PGP would at least stop most under 10 from accidental content. But this is not a very user friendly solution for the masses.

But you raise a very good issue that has been rattling around in my head for a bit.

Is this about taking over from TOR, or making money from the masses?

[thelonecrouton]

*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.

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?

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.

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.

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.

[thelonecrouton]

Is this about taking over from TOR, or making money from the masses?

It's about providing a service that is faster and easier to use than TOR, that isn't owned by the NSA. How anyone chooses to use or monetize that service is up to them.

We can eat the cake and still have it. 

[oaxaca]

A German, a Brit and a Spaniard walk into a bar... sounds like a party!!

The Spaniard asks "Hey, can I have a Job?"

The German says "No more bail outs!"

The Brit vomits on his shoes.

[coins101]

Kristov says he is finishing writing up his view on DRK.

http://youtu.be/j6ZRzzTMABM?t=1h23m15s

at ~ 1.23.15

[future_quark369]

*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.

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?

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.

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.

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.

thank you for the explanation
but is shame that price is going constantlyy down

[baddw]

*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.

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?

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.

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.

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.