Concerns for DIP3

[camosoul]

Two points.

First, is that the permission granted by the operator key is inappropriate. The Operator can, at will, decide to take more money from the Owner's payment. The payment belongs to the Owner, not the Operator. This makes MN Operator services no longer trustless.

Second, it's based on a percentage. I shouldn't have to explain volatility. The only way this appears useful is if you trust the Operator to constantly rescale this to a fiat number in real-time. Yes, still tied to fiat, because the Opertor's costs of operating are still tied to fiat.

I'm not suggesting that these changes will cause the sky to fall. I'm pointing out that this fundamentally isn't trustless anymore. The second function's usefulness seeming predicated upon not being trustless anymore...

To the point that the second feature was the goal, which the trustless nature of the system was compromised expressly to make that possible.

This change in dynamics was not openly mentioned or discussed. So there are many who may not understand that the consequence is no MN service will be truly trustless anymore. Sure, it seems like the 1000 collateral are still safe (assuming no unmentioned changes occurred there), but none of your payments are.

What other unmentioned changes have been made which may have a similar impact on trust/privacy?

Yes, yes. DASH is making changes as it Evolves. To be expected for a project that deliberately moves it's own goalposts for it's own betterment. Often mid-process and mid-development of those stated features. I'm not advocating for a freeze, or any old-system puritanism. Just that you've got be be more outspoken about things that detract from a previously accept foundational premise.

Clearly, one can point out that "If you don't rust your operator, why is s/he your operator?" Sure.

Being unaware that trust has now become an element may lead people to not even consider a need for trust, since the system had previously been fully trustless.

We recently had a rather high profile (alleged) incident of someone not even knowing that much (supposedly) losing an MN worth of DASH to a node hosting scam. It was a painfully obvious scam for which the victim has no one to blame but himself, but nonetheless...

If you have been told for years that MasterNodes are trustless, but then suddenly they're not anymore... And nobody tells you of this change... There could be some problems.

 

[camosoul]

Secondly, your market price is rapidly approaching the point that MasterNodes may no longer be able to pay for their own hosting...

I know that even the leadership of DASH likes to advocate that everything will just get better again for no reason all by itself, but it won't...

You need to do something productive or you're headed for the single digits. Then, it'll cost more to run a MasterNode than it pays. The point at which it won't be worth doing will come well before then, because breaking even is dumb, and there are plenty of hands-off investments that pay more than running an MN already... MNs are down to roughly 6% ROI. For anyone that has investments of this value level (1000 DASH), there are plenty f better places to earn more money with less effort and lower risk. 6% ROI is low-risk payout, on a super-high risk investment... Already not worth it to people with a big-picture view.

 

[UdjinM6]

There is no additional trust in operator, that's not the case - the only special tx operator can sign to update any mn data is ProUpServTx.

An operator can update the IP address and port fields of a masternode entry. If a non-zero operatorReward was set in the initial ProRegTx, the operator may also set the scriptOperatorPayout field in the ProUpServTx.

i.e. operator can only update node IP and an address he would like to get his share of the reward to and that's it.
Pls see https://github.com/dashpay/dips/blo...ng-service-features-from-operator-proupservtx

EDIT: In fact, there is now _less_ trust in operator because the voting key is now a separate thing.

 

[toknormal]

The Operator can, at will, decide to take more money from the Owner's payment.

How is this possible ? Surely if the payments are made to the collateral address then they're under control of the "owner", not the operator.

 

[camosoul]

There is no additional trust in operator, that's not the case - the only special tx operator can sign to update any mn data is ProUpServTx.

i.e. operator can only update node IP and an address he would like to get his share of the reward to and that's it.
Pls see https://github.com/dashpay/dips/blo...ng-service-features-from-operator-proupservtx

EDIT: In fact, there is now _less_ trust in operator because the voting key is now a separate thing.

I keep reading it and I keep seeing the same thing... The Operator can change the payout percentage... But, even if I'm reading it wrong, over a dozen times now.

Now, if the operator CAN'T change the payout amount, and it's set to X% by the Owner, uh, that's going to go haywire with every market adjustment...

DIP3 is not adequately/accurately explained... I don't get it. I've read that info many times.

 

[camosoul]

Every masternode operator would have to keep a script running, constantly resigning that variable to assure his payment was the proper fiat equivalent...

Or, simply ignore that feature and keep paying monthly or quarterly like we do now... Vestigial before launch... ergh...

 

[camosoul]

"If a non-zero operatorReward was set in the initial ProRegTx, the operator may also set the scriptOperatorPayout field in the ProUpServTx."

Is that not the second sentence of the second paragraph in the very document you linked?

 

[UdjinM6]

I keep reading it and I keep seeing the same thing... The Operator can change the payout percentage... But, even if I'm reading it wrong, over a dozen times now.

Now, if the operator CAN'T change the payout amount, and it's set to X% by the Owner, uh, that's going to go haywire with every market adjustment...
...

Only the Owner can set the percentage. I don't see an issue with that because even now operators can charge in Dash. IF it's not what the Operator wants, he can simply charge as usual (i.e. the Owner gets 100% and pays X USD at the end of the month or in any other way the Owner and the Operator agreed). It's just an option.

"If a non-zero operatorReward was set in the initial ProRegTx, the operator may also set the scriptOperatorPayout field in the ProUpServTx."

Is that not the second sentence of the second paragraph in the very document you linked?

scriptOperatorPayout is basically a Dash address where the Operator wants his share to be delivered, payout percentage is set by the Owner via operatorReward field of ProRegTx.

 

[camosoul]

Only the Owner can set the percentage. I don't see an issue with that because even now operators can charge in Dash. IF it's not what the Operator wants, he can simply charge as usual (i.e. the Owner gets 100% and pays X USD at the end of the month or in any other way the Owner and the Operator agreed). It's just an option.

scriptOperatorPayout is basically a Dash address where the Operator wants his share to be delivered, payout percentage is set by the Owner via operatorReward field of ProRegTx.

I think I'm still misunderstanding how this is supposed to work... Maybe I was seeing the path to a cool feature. If one trusted a Service/Operator to change the percentage, that Operator could much more easily integrate an automatic price adjuster than expect the Owner to constantly monitor and adjust it.

But as it is, we can just ignore this feature and continue on as usual.

While it makes it somewhat less trustless, I think my original, inaccurate, notion would be worth it... The feature doesn't seem workable if the Owner has to monitor and sign adjustments in anticipation of payment.

...unless that's going to be built in?

 

[thephez]

While it makes it somewhat less trustless, I think my original, inaccurate, notion would be worth it... The feature doesn't seem workable if the Owner has to monitor and sign adjustments in anticipation of payment.

...unless that's going to be built in?

Can you explain what part of this you see as less trustless than before?

These are the ways it is more trustless:

1. Voting: The ability to vote is now completely unrelated to the operation of the masternode. The operator can only manage the hosting and nothing else.
2. Hosting payments: The ability for an owner and operator (if they want) to agree on a hosting cost that is on-chain so that payments are automatically split with no manual action required.

As @UdjinM6 pointed out, the operator percentage can only be changed by the owner. The ProRegTx is the only place the operator reward can be set and that transaction can only come from the owner.

There's nothing that would prevent someone from building on top of this to automate some things, but I don't see a built-in scenario where an operator has the freedom to modify their portion of the reward without interaction with the owner. That would definitely compromise the trustless nature of masternode hosting.

 

[Cofresí]

Yeah, I think Camo's automatic operator reward adjuster would be a bit clumsy to build right now.

It definitely won't ever work without interaction with the owner (KeyIdOwner, collateral signature needed)
Right now I guess you could "overwrite" a registered masternode with a new ProRegTx spending/referencing the same collateral and keeping everything equal except for the operator reward to be changed. But that would deactivate the old masternode and create a new one with a new protx hash and put that new masternode at the very start in the payment cycle. To really enable such a feature for a masternode operator where the former could send a message to the owner with his updated terms and the ProUpRegTx parameters already preset just waiting for the owner's signature to confirm acceptance of such would require to update the ProUpRegTx with a new field for changing the operatorReward too. I guess if the community of masternode operators would love such a feature we will hear from them and make a new version of the ProUpRegTx.

 

[camosoul]

Can you explain what part of this you see as less trustless than before?

These are the ways it is more trustless:

1. Voting: The ability to vote is now completely unrelated to the operation of the masternode. The operator can only manage the hosting and nothing else.
2. Hosting payments: The ability for an owner and operator (if they want) to agree on a hosting cost that is on-chain so that payments are automatically split with no manual action required.

As @UdjinM6 pointed out, the operator percentage can only be changed by the owner. The ProRegTx is the only place the operator reward can be set and that transaction can only come from the owner.

There's nothing that would prevent someone from building on top of this to automate some things, but I don't see a built-in scenario where an operator has the freedom to modify their portion of the reward without interaction with the owner. That would definitely compromise the trustless nature of masternode hosting.

I was partially misunderstanding the description of the Operator Key. Which is easy to do given that the documentation is as clear as mud...

I was under the false impression that the Operator could adjust the percentage of payout diverted to him.

This misunderstanding led to the notion that it would actually be kinda cool... It sacrifices a smidge of trustlessness (collateral remains locked up safe, but the payments would require trust in the Operator, and why would you choose an operator you don't trust anyway? Largely a moot "loss"), but only enough to enable a real feature (autopayments bound to a fiat value) that in the dynamics of the rest of the situation (see previous parenthetical of minor trustlessness compromise), might be well worth it.

The goofy (incorrect) way I was seeing it, the operator could follow the deterministic payment list, which will finally be absent entropy, and update the payment ratio such that it would result in a pre-agreed upon FIAT value 1 block before the node he was Operating would get it's payment.

The Operator could also set it to 100% and steal every payment for himself. thus, requiring trust and not being fully trustless anymore.

But that's not how it is. I was just misunderstanding it.

...The Operator could be Operating Operationally... Sigh... No one here gets that joke...