• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

What is Sentinel? (Masternodes)

From a software engineering perspective it makes a lot of sense actually.
If you want to expand an existing system it's a good approach to first modularize it into single components each of which are easier to work on individually.

So splitting this part from the daemon is only a first step towards the planned features we heard of in Evolution. It's classic divide and conquer.


Bullshits. Theoretical bullshits.
 
The wallet is a type of node, it connects to other wallets/nodes. Sentinel is another kind of node, and it kind of runs through or connects through the wallet node.

And why the governance system to be separated from the wallet? What is the reason?

The blockchain resides into the wallet node.

Why they dont want to store the votes into the blockchain?
What are the real consequences of this separation ?
Why they designed the system like that?

Is it on purpose, or maybe is it because they are just incapable to design a governance system that resides into the blockchain?
 
Last edited:
Basically, it allows modules that interface with dashd. It's not merely "Sentinel makes it that way" but that dashd has been re-written to interface with modules. Sentinel is just one of those modules. It kinda takes the idea of OPS (Optional Proportional Services) that I had and bends it a bit. I hope that DashDrive is a similar modular service of it's own which binds to dashd.

Sentinel is also a lot more generic and therefore extensible. Modifying it will be a lot easier in itself, above the fact that modifying it doesn't require modifying dashd.

It's not clear yet if Sentinel will be the central hub into which other things plug, or if dashd will be that central hub. I'm just looking at it from what I can see right now. That's why I have the same interest in seeing these questions answered, and they're not being answered. We get the standard arrogant nerd game of "RTFM" followed by a link to an FM that doesn't say a single word on the topic...

It opens up security questions for me. Since MNOs have been thus far encouraged to make no effort to secure their machines... How will this open up the possibility for corrupting and replacing data? So far, MNOs have been insulated from the only real risk they faced by the hot/cold wallet setup. Since virtually none of them take security seriously, or have any clue how, it means that a supermajority of MNs could be compromised in other forms of data. Heretofore that notion has been of no consequence because MNs contained no other data that could be valueable, or serve anyone's interest by damaging it. That just changed. Sure, you won't get your coins stolen, but if 70% of the newtwork can have it's budget data replaced, that false implantation becomes the consensus. Since there was no pot of gold, there wasn't much point in trying to break into MNs. So, there's been no concern to hardening them. The best an attacker could hope for is knocking them down here and there. A totally unproductive waste of time and resources. Now, competitors coins have a target worth attacking, a collective target that isn't even trying to stop them. If they can compromise 60% or more, and keep it to themselves while they develop a simple script to deploy their own budget data...

It seems like a push towards getting everyone to use Node40. Hence the longwinded effort to explain how a centralized entity doesn't actually centralize DASH at the conference in Atlanta. It's still a centralized entity...

What happens when this same thing applies to DashDrive?
 
Last edited:
It opens up security questions for me. Since MNOs have been thus far encouraged to make no effort to secure their machines... How will this open up the possibility for corrupting and replacing data?

Specifically, what security efforts are you talking about? For example, I have iptables enabled and only allowing SSH and the Dash client for incoming connections, keep the server up to date, and use fail2ban. Plus DDOS protection from my server provider. This is a very basic list, just curious what I'm missing.
 
All valid points, Camo. But I think even a 70% attack on budget databases could be thwarted if they use masternode quorums to achieve unanimous consensus on payments.
 
I think camosoul raises a valid point. Masternodes now with Sentinel seem very flexible and powerful. The flip side is increased attack surface.
I'm quite surprised that bigger holes hasn't been found in Bitcoin. I guess one strength is the homogeneous structure and 100% focus on trust less design. The masternodes introduce some level of trust, in exchange for flexibility. But it makes them targets.
With all new features being added in Evolution I would be even more surprised than in the Bitcoin case if no security hole was found.
I trust we have very competent developers. I'm just afraid that economically motivated hackers will succeed in the end. I hope I'm wrong!
It would be very interesting to hear what the core team thinks and what meassures are being taken. Extensive code audit or formally provable code might be two alternatives?
 
I agree that there could be, as you say @marinf , a larger attack surface with sentinel. I have to understand the mechanics better to evaluate, and of course I'm a layman. But I do not agree that masternodes introduce trust into the system. Especially at the size of our network. In fact, it can easily be argued that with all the mining power in China, it's more likely they will collude and that Bitcoin has to trust them far too much to behave. With @Otoh being the largest holder of Dash, we can evaluate the "worst case scenario". I feel it is true that otoh was and still is the largest holder of Dash because Darkcoin was still pretty insignificant and most people didn't do anything like hold their coins in separate wallets in the early days. we could watch while he bought, and there were no other wallets that large in the history of Dash. Remember, the "instamine" happened with at least 25 miners mining. 1.9 million/25 = 76000 coins if distributed evenly per miner. But that's per known miner, what about all those that don't bother to talk on the forums? And so many sold their coins immediately. My only point is that I believe that we do have a healthy distribution of masternodes. otoh has sold many of his, "spreading the word" and getting business people to invest. He's been a huge asset to Dash.

It's basically impossible to get masternodes to collude to do anything. But with sentinel, I understand less. So I will hold my assertions that it's solid 100% as I digest it all. Of course nothing is 100%, but I do trust our developers, they're pretty thorough.
 
@TanteStefana I agree that practically speaking there is no need to trust anyone in dash. As you say the system is built such that an adversary must own a ridiculous number of MNs to be able to do an attack in practice.
However, the introduction of masternodes took one step away from a completely homogeneous network. The "trust in the system" is not spread over all the nodes, but rather a subset; the masternodes. Indeed the masternodes are still great in number but there is a limit here.

There is a well defined list of IPs of all the masternodes (ignoring some very few Tor nodes). How many of them run the same Ubuntu version, possibly even set up using the same guide?

I don't want to be an alarmist, or try to spread FUD. I just want us to make sure we invest the appropriate amount of resources in security going forward. I think we should use Bitcoin as reference and really evaluate every deviation we make from it. The introduction of masternodes is surely one such deviation. I think appropriate actions have been taken (reviewd whitepaper describing security through quorums etc) but we can't consider it a solved problem. It must be taken into consideration together with all new changes, such as the increased flexibility of sentinel.

What damage could be done if arbitrary python code could be installed on say 10% of the masternodes, replacing the original sentinel?

What kind of DOS protection will DAPI have? (This may be further down the road)

I would be happy to vote for any proposal that include security audit of the code or hire of accomplished white-hat hackers that try to find ways of hacking or DOS:ing our network.
 
I think we've discussed getting a security audit, and that it would gain a lot of support. Unfortunately, I don't have the skill to evaluate these questions. Worse still, how well is the code written? Remember Ethereum had that simple mistake where people could withdraw more than they put into a system, it was a simple code mistake. Yes, we need many eyes reviewing the code, white hats as well. If black hats hit us, though, it should make us stronger. Is anyone even trying to crack Dash? I sure hope so! Better now than later!
 
AFAIK ethereum never had anything wrong with it, hence, ethereum classic. Someone programmed a smart contract incorrectly and people were butthurt that the algorithm was executed to the letter. But I get your point. My guess is hackers are already trying to find vulnerabilities in dash.
 
I think what distinguishes DASH is exactly this- "hey we might have a problem let's incentivize an investigation into the problem."
 
Is facing the alternative, catastrophic failure, not incentive enough? Is that not incentive enough to even talk about it?

OR, do we really need a budget proposal because they need to be paid just to have a conversation? Is that how bad the hubris and arrogance has become?

Are you suggesting that it is that bad, and that it's not a bad thing?

I kinda doubt it, but that's what it looks like...
 
Last edited:
some very few Tor nodes
I'd like to know how the tor stuff is being done and the compatibility programmed into dashd... We've been told that dashd requires binding to a public, static IPv4. So, how can this be?

This is one of many details that proves that we're not being told anywhere near the whole story about the function and behavior of the software we're running... dashd has more questions in it than answers at this point.
Code:
externalip=bv4765jv37jb3v5j3jc.onion
?
Code:
MN001 [n86ib35c53g568b46j.onion]:9999 74t2h567b3jcjtyuvVj367jcCJe7j3cccjjc 456u75uv57hc67ueur7j64hghyhtj57u53uhvj6rujvrj6jcjv4jc3hv 0
?

I don't know how that's working, or if there are any masternodes that get paid that have hidden IP addresses. But I can tell you one thing, tor is super slow, and if they do try to run a MN through tor, they're probably falling off the grid. It's not something we want people doing for certain, as the service would suck. And I think this is a loop hole that was plugged in 12.1?
 
Last edited by a moderator:
I have a theory about why sentinel hasn't been described in more detail (when I say theory, I also mean wild speculation on my part).

The reason for the lack of detail is because one of the "objects" that can be controlled now is a variable that sets an amount for collatarised mining.

Collatarised mining is effectively a tax on miners (equal to the opportunity cost of holding the collateral).

If miners fully understood that 12.1 included the ability to tax them in the future, then maybe they wouldn't upgrade.
 
I just saw @afreer answer Amanda, who basically just asked this same question, and found the answer very enlightening!

afreer [5:12 AM]
@amanda_b_johnson the differences with Sentinel are really architectural and not easy/interesting to explain to users as they are a bridge from 12.0 towards Evo features (but not full implementing them), and Sentinel was only a part of 12.1 improvements anyway. Pre-Sentinel, governance functions were 'hard wired' into core code. Sentinel abstracts this process because in Evolution there are many Object types from Users to Accounts to Contacts etc, and if we didn't make this change first, future changes / improvements in Evolution (e.g. adding a new type of Object) would require changing core code. Now Core is agnostic to types of objects and we can take this forward for user experience and not just governance.

In terms of documentation, first thing - the whitepaper last year wasn't actually a whitepaper, not sure why it was released with that name - anyway, no, there is no whitepaper specific to Sentinel, but we have various docs for Evo in an on-going RFC process but we haven't released anything yet, but we are using them as the basis for Evo development (will release them before Evo but not quite ready yet)

In terms of 'proof of service', this is really something that's unimportant right now in Dash, and commonly misunderstood. What it means in Dash is punishing MNs that cheat some of their additional roles, not security on data added to the blockchain, as some people are claiming (who have no idea how Dash works). It's not a problem that's occurred for us (probably because there's not real reason / incentivizes are actually to help the network for your investment).
 
I have a theory about why sentinel hasn't been described in more detail (when I say theory, I also mean wild speculation on my part).

The reason for the lack of detail is because one of the "objects" that can be controlled now is a variable that sets an amount for collatarised mining.

Collatarised mining is effectively a tax on miners (equal to the opportunity cost of holding the collateral).

If miners fully understood that 12.1 included the ability to tax them in the future, then maybe they wouldn't upgrade.

whaaaat - conspiracy theory #452 :rolleyes:
naaaa nothing like that in there !
there is no "hiding" anything - it comes down to good old plain documentation
as coders are they code and do not document - same old ;) - documention (what u actually do) is a pain and takes a long time - and so far nobody stepped up to the task - that is all
we had a proposal last year about hiring (tx tante) a technical writer (for exactly documentations like this) unfortunately it got voted down (as it was misunderstood by many ) i believe we will resubmit that proposal eventually as we really need good and more documentation (not only sentinel but IS, PS, ....)
 
Last edited:
I'd like to know how the tor stuff is being done and the compatibility programmed into dashd... We've been told that dashd requires binding to a public, static IPv4. So, how can this be?

This is one of many details that proves that we're not being told anywhere near the whole story about the function and behavior of the software we're running... dashd has more questions in it than answers at this point.
Code:
externalip=bv4765jv37jb3v5j3jc.onion
?
Code:
MN001 [n86ib35c53g568b46j.onion]:9999 74t2h567b3jcjtyuvVj367jcCJe7j3cccjjc 456u75uv57hc67ueur7j64hghyhtj57u53uhvj6rujvrj6jcjv4jc3hv 0
?

I don't know how that's working, or if there are any masternodes that get paid that have hidden IP addresses. But I can tell you one thing, tor is super slow, and if they do try to run a MN through tor, they're probably falling off the grid. It's not something we want people doing for certain, as the service would suck. And I think this is a loop hole that was plugged in 12.1?

flare just answered for me. Apparently there was a loop hole, but as of 12.1 it's closed:

flare [1:28 PM]
Since 12.1 masternodes require a public IPv4 connection - both IPv6 and Tor addresses can't be announced. The background is to improve connectivity and mixing experience.
 
whaaaat - conspiracy theory #452 :rolleyes:
naaaa nothing like that in there !
there is no "hiding" anything - it comes down to good old plain documentation
as coders are they code and do not document - same old ;) - documention (what u actually do) is a pain and takes a long time - and so far nobody stepped up to the task - that is all
we had a proposal last year about hurting a technical writer (for exactly documentations like this) unfortunately it got voted down (as it was misunderstood nba lol then by many) i believe we will resubmit that proposal eventually as we really need good and more documentation (not only sentinel but IS, PS, ....)
You wanted to hurt a technical writer? Well, i guess I'm glad that proposal was voted down! I thought we wanted to hire one ;P (Oh boy, I can see getting smacked if I ever meet you in person ;P)

Actually, we should try this again. It's important.
 
Back
Top