No, not really, and there are few issues.
You mentioned history but this history has to be build somehow and voting process is the weak chain here. Due to network propagation issues different nodes can see slightly different results (vote count) when new block is mined/arrived and some of them might not agree that the fee value stored in such block is valid which will cause a permanent fork because such block is now violating consensus rules (from their perspective). You can probably solve this by allowing some arbitrary margins but this is yet another magic number unless there is a clear mathematical model behind that.
Ok, so you are saying that not all nodes can see all masternodes. And as such they will feel the result at which the rest of the network has arrives is bogus. Interesting. How come this does not happen when the normal proof of work happens, and one node presents a number of transactions and links them all in a block?
Can't we mimic such a system? With change of vote from masternode being equivalent to a transaction. And sometimes those votes are not instantaneous, and might take some time to be stored in the blockchain, but it's no big deal. When the node stores the new block, it also stores the new median, with all the transactions, and all the new votes. If someone cannot see one of the vote, it should be like when someone in the bitcoin network not seeing one of the transactions. I am not sure what happens in that case, but shouldn't be that different.
The only real problem I see is with masternodes going offline. Because that is something that should be istantaneous, while all the change-the-vote is not istantaneous. But maybe we can accept there is a bit of echo.
(If I need to read something like how Dash POS is different from bitcoin POW please let me know and send me the link. As I said I feel I am on uncertain ground, which for a mathematician feels weird. We are used to tautologies ;-) )
And even if you have a common history, there is yet another issue - it's not guaranteed to have you fee-tx included in the very next block because you never know when the new block is going to be mined, so it's quite probable that you'd need to wait for (at least) a block. It can happen so, that the fee was adjusted in that new block and now it turns out that your fee-tx has not enough fees included, so you just lost money for nothing, basically. You can probably solve this too by paying more, again by some margin, plus a higher miner fee to make sure it's included in blockchain as soon as possible but I guess there will be people/wallets trying to minimize the cost especially if min fee is already high. As a result this will cause a lot of issues and complains and I'd prefer to avoid that on protocol level
.
This is how I see it: people present a proposal with some fee. There are two options:
(1) the fees are enough
(2) the fees are not enough
In case one the fees get paid, and any extra is sent back. So you pay 3 Dash, the fee-tx is 2.5, 0.5 is sent back to your address.
In case two the proposal remains suspended. You can retire it in any moment. If you do not retire it, in any moment in which the fee is higher than the fee tx the proposal gets accepted and it goes to point 2. Any proposal that is not accepted after "magic_number" blocks gets rejected and the money goes back.
I don't see any complain with this. Said that
an alternative option is that the masternodes when they vote, next to the vote they also insert how much should the tax be for the proposal they are voting for. And again you take the median. In this way the masternodes have the possibility to punish people who keep disturbing them with silly proposals (like ours
, not sure if I like this idea ).
In a sense right now many people are already inserting as the cost 5 dash, to pay back for the proposal. And if the proposal is not accepted, the next proposal will cost 10 dash. This will take care of it. And the tax becomes really a tax. Maybe masternodes who vote yes will (or should) only vote 0 as tax. Meaning an accepted proposal should cost nothing to the proposer. This is a bit like the Italian legal system where when someone sues someone else, the loser has to pay the cost of the process for both, and the winner pays none.
Also, I see "you want the network to be as responsive as possible" statement as a false premise because I don't want that actually, at least not on a 15-minute/10 block basis, not at all
The truth is you can't fight spam with fast reaction because at the moment you start reacting you already lost - if it's economically reasonable I can create spam txes and consume all available resources at enormous rate in no time, by the time you start reacting network is already overwhelmed with spam and/or dead. With this in mind, I actually want network to be pretty conservative to keep it's security, ability to provide service to legit users and discourage spam attacks, yet adaptive to allow new possibilities in mid/long term.
You are thinking boolean, open to spam? True/False.
But this is a continuous variable. It is not that at some values you get million attacks and then at another the spam attacks all go away. As the value raises (and the median raises slowly, because every two new vote raising can at maximum raise it by one person) the proposals that go through will diminish more and more. Of course there will be some false positive (spam proposals that pass through) and some false negative (serious proposals that don't make it). But the system will adjust rapidly, and even when the value will be low, it will still be high enough to stop the great majority of spam. Really, you are thinking discrete, this is continuous.
One point, if you are facing a intelligent operator, it might not send any spam for a long time, wait for you to lower your shields, and then send it all at once. In this case the defence is continuous but the attack is discrete. For this we need to rely on the wisdom of the masternode never to lower the fee too much. But this attack could happen exactly the same if people could vote their fee tax every cycle. With the added damage that then they cannot change their vote until the next cycle.
Ok, I hope this helped.
I am looking forward to learn more about how the Dash blockchain works differently from the bitcoin one
.
Cheers,
Pietro
