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

Introduce the 13 operators that own 3000 masternodes.

Hosting providers does not equal Masternode owners. This thread seems a little twisted.
who is the mastenode owner?
The one who holds the private key of the 1000 dash collateral wallet?
Or the one who holds the masternode private key and he is able to vote?
 
If you are informed, could you please answer to the simple question first?
Then comes the complicated one.


Still nobody answers to my questions. Your only answer is your rating. Trolls you are, troll is the rating you are casting. This a known tactic, the same tactic is applied also to the lamassu project. We do not answer, we bury the important information and the important questions below tons of info-garbage (produced constantly by amanda, tungfa and the rest marketeers) and we pretend that the problem does not exist.

After all, who cares about security? Who cares about decentralization? Who cares about voting consistency? Convenience is the only thing you care.

A typical ignorant asks:
Hi,
I want to get a dash masternode and Im probably going to get someone to run it for me. They create a dash masternode key for me after I tell them the public address, and they can run the node for me after they send me the masternode.conf file.
There is no risk to my dash/coins in doing it this way, right?

...and one of the trolls that troll-rated me (@flare) answers:

Yes, thats the correct process, no risk for your coins involved.
You send them the address, they return masternode.conf with IP and masternode key, you issue a "masternode start-missing", done.

No risk for his coins? Really?
And what about the risk for his masternode?
Does it really belongs to him when others know the masternode private key?
 
Last edited:
No risk for his coins? Really?

Really.

To be honest: I don't think you understood how masternodes work on protocol/process level.

Since you refuse to read the manual and i am not willing to dig through the code for you, I'd suggest you start playing around at our testnet where you can have tDash for free and you can have your very own (test)masternode yourself - including a (test)vote.

And what about the risk for his masternode?

Define "risk".
Risk of loosing his 1000 Dash? Zero, as the key is not shared.
Risk of someone using his vote? Present, as the key is shared. But since the key can be revoked/changed i don't see a risk here.


Does it really belongs to him when others know the masternode private key?

If you read the manual/code, you will notice that there are TWO private keys:

1) private key for the 1000 Dash, known only to the coin owner (aka masternode owner)
2) private key for masternode, known to coin owner AND server owner

So someone who has the "masternode private key" does not possess the masternode - he has the ability to vote though.

Re. marking you posts as trolling: I'll continue to do so as long as i feel your posts are nothing more than that: trolling.
 
Really.

To be honest: I don't think you understood how masternodes work on protocol/process level.
Since you refuse to read the manual and i am not willing to dig through the code for you, I'd suggest you start playing around at our testnet where you can have tDash for free and you can have your very own (test)masternode yourself - including a (test)vote.

I understand how the Dash protocol should work. And in theory yes, the private key of the coins is not compromised. This is what you claim. But I am cautious with your claims.

Dont take it personally, but I dont believe your claims, I dont even believe your opensource github code. It is not enough for me to read all your source code, then download it and compile it. There is also another step. Only after I download the executables you provide and pass them through an assembler and a packet sniffer searching for my private key, I will be convinced that your protocol works as it should work and as you claim it works. A few people compile their code from scratch , the vast majority uses the executables you provide without bothering with compilations. So if you want to cheat, the easy way is to keep the open source correct, keep the test versions correct, and infect the executables of the stable version with password stealer trojans.

So the question is:

Has an independant tester ever tested (with an assembler and a packet sniffer) your stable version executables, searching for PWS (password stealer) trojans infections ?

If not, why not? Why nobody has ever proposed such a proposal in the budget system?

Define "risk".
Risk of someone using his vote? Present, as the key is shared. But since the key can be revoked/changed i don't see a risk here.
What happens between the time someone steals the vote and the time the vote is revoked/taken back? And what if this inbetween time is the budget payment time?

And what about the lurkers, the people who dont care to vote. Dash network has a lot of them, and as long as they are lurkers I think they dont really care if someone uses their vote or not.

You claim that you take extreme precautions in order to protect your coins' privatekey, but you dont care at all for your votes' privatekey. This is tottaly wrong. Because by using your vote, you can pass an appropriate proposal in the budget, which can change the Dash protocol itself and that way confiscate the coins. So the voting privatekey is much more important than the privkey of the coins. But you expose it severely and you take no precautions in order to protect it from (temporary) theft or misuse.
 
Last edited:
@demo=troll

No, the demo is not the troll. The demo, and all the testbeds, are usually correct. The troll resides in the stable version executables.

Those executables may (or may not) are infected with PWS trojans, but the trolls never ask an independent tester to check them, neither they want a relevant testing proposal to pass from the budget system. They prefer to pay the marketeers to fill the internet with garbage-info about how great dash is, so that the dash deficiencies to never being heard by the masses.

But this is not the correct way for a digital cash that wants to survive in the future to evolve. The correct way is to pay an anti-core team, a team that will have the mission to attack the core team and reveal all their wrongs and errors.
 
Last edited:
...I dont even believe your opensource github code. It is not enough for me to read all your source code, then download it and compile it. ... So if you want to cheat, the easy way is to keep the open source correct, keep the test versions correct, and infect the executables of the stable version with password stealer trojans...
It is enough to make sure binaries are ok and no code was changed or injected because official builds are deterministic.
https://github.com/dashpay/dash/blob/master/doc/gitian-building.md
Grab the exact same tag which was used to build binaries on https://www.dash.org/downloads/ page, compile via gitian, compare - they should match byte by byte i.e. even hashes should match no matter when you build it.
 
It is enough to make sure binaries are ok and no code was changed or injected because official builds are deterministic.
https://github.com/dashpay/dash/blob/master/doc/gitian-building.md
Grab the exact same tag which was used to build binaries on https://www.dash.org/downloads/ page, compile via gitian, compare - they should match byte by byte i.e. even hashes should match no matter when you build it.

"Gitian is not perfect. In fact, many who have tried the build system have remarked that it is not even close to deterministic (and that for this and other reasons 'Reproducible Builds' is a better term). In fact, it seems to experience build failures for quite unpredictible reasons related to bugs in one or more of qemu-kvm/LXC, make, qcow copy-on-write image support. These bugs are often intermittent, and simply restarting the build process often causes things to proceed smoothly. This has made the bugs exceedingly tricky to pinpoint and diagnose.

Gitian's use of tags (especially signed tags) has some bugs and flaws. For this reason, you have to verify signatures yourselves after input fetching, and provide gitian only with explicit commit hashes for the input source repositories."


Gitian supports only debian. What about MacOs, or win32/win64 builds?
 
"Gitian is not perfect. In fact, many who have tried the build system have remarked that it is not even close to deterministic (and that for this and other reasons 'Reproducible Builds' is a better term). In fact, it seems to experience build failures for quite unpredictible reasons related to bugs in one or more of qemu-kvm/LXC, make, qcow copy-on-write image support. These bugs are often intermittent, and simply restarting the build process often causes things to proceed smoothly. This has made the bugs exceedingly tricky to pinpoint and diagnose.

Gitian's use of tags (especially signed tags) has some bugs and flaws. For this reason, you have to verify signatures yourselves after input fetching, and provide gitian only with explicit commit hashes for the input source repositories."


Gitian supports only debian. What about MacOs, or win32/win64 builds?
The fact that Tor project failed to use Gitian properly back in 2013 doesn't suddenly make Gitian usage for Dash builds in 2016+ broken.

Gitian uses Debian and containers as a platform to produce builds for all other platforms. If you would actually read the instructions carefully you would see it https://github.com/dashpay/dash/blob/master/doc/gitian-building.md#building-dash ;)
 
The fact that Tor project failed to use Gitian properly back in 2013 doesn't suddenly make Gitian usage for Dash builds in 2016+ broken.
Of course it doesnt make gitian usage broken. But this is not enough, you have to prove also that Gitian usage is also suitable and that in 2016+ it does not inherits the bugs the tor team pointed back in 2013.

Futhermore, besides gitian, there are also some other new tools used to create reproducible-builds, that you should investigate.

And talking about Gitian, you know who is the gitian main developer, dont you?

Devrandom. :D
 
Last edited:
Or more to the point, put the version control behind the masternodes and let them govern who can do updates.
 
Or more to the point, put the version control behind the masternodes and let them govern who can do updates.

In order to do this you have to secure the privatekey of the vote. Puting the version control behind the masternodes and at the same time exposing the vote private key, this is catastrophic.

So you have to create 3 private keys for every Masternode.
  1. One private key that holds your money
  2. One private key that manages your masternode and makes it recognizable into the network (which you can give it to the Masternode service providers (MNSP) )
  3. One private key that can be used to vote (which you should have the option either keep it safe or give it to the MNSP)

Having tha last two private keys in one, this is a design deficiency.
At least you should give to every masternode owner the option to separate the network layer from the voting layer.

I added a preproposal for this.
 
Last edited:
Demo.. You need to move out from your moms basement and get a girlfriend.. There is someone out there that will love you regardless, let 2017 be your year
 
From the veritas team.

Multiple Voting: In the current implementation of the DGS, votes are issued by the Masternodes and relayed through the p2p network to other nodes. A vote is checked for validness only when it is seen the first time. This means that once a vote is accepted and added to the internal pool, it will be valid as long as the corresponding proposal is valid. A vote will not be deleted even if the Masternode which signed this vote is no longer a Masternode (for example, the Masternode operator transfers coins away from the Masternode's collateral transaction output).
This leads to a situation in which a single person with 1000 Dash can successively establish several Masternodes, and then issue multiple votes for the same proposal. Alternatively, an operator of multiple Masternodes could vote for a project and then take his Masternodes offline. This would reduce the total number of Masternodes used in determining a proposal’s approval. Either situation, of course, can lead to a manipulation of the final voting result
for that proposal.
Note that it is possible that this problem is a bug in the code. By design, if a Masternode drops of the payment list/network due to not being active or due to movement of collateral, it loses its voting power and also its voting
history (this information was obtained on the Dash forum [2]).

This bug was resolved in PR1135.

I was wondering where this PR is ,when it was resolved, how it was resolved, whether it was resolved in version 12.0 or not, and what happened to the votes casted and to the money given before this bug was resolved.
 
From the veritas team.
This bug was resolved in PR1135.

I was wondering where this PR is ,when it was resolved, how it was resolved, whether it was resolved in version 12.0 or not, and what happened to the votes casted and to the money given before this bug was resolved.

Let me do your homework: https://github.com/dashpay/dash/pull/1135, ofc you will still need to read to figure out how and when this was resolved ... and I'm starting to believe that might be a problem for you.
 
This bug was resolved in PR1135.
I was wondering where this PR is ,


when it was resolved,


how it was resolved,
..you will still need to read to figure out how .
Is it this I have to read? Isnt there a more human readable explanation, any documentation? Do we have to wait the veritas team to explain us the code specifications?
:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:


whether it was resolved in version 12.0 or not,
:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:


and what happened to the votes casted and to the money given before this bug was resolved.
:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:
 
Last edited:
As I said that is your problem, you can not read code or analyze it's history. Yet you shit all over this forum complain about how bad this part is and how insecure the other thing is. But time and time again you show us you do not know how to use git to look up the proof for any your claims and when pointing you strait to it your are still not able figure out the basic things required to ask the next logical question ...

I would explain it to you if I thought it was worth my time but sins you behave and smell like a troll I can only be asked to poke you a bit here and there ... no one here is taking you serious any more
 
Last edited:
I would explain it to you if I thought it was worth my time but sins you behave and smell like a troll I can only be asked to poke you a bit here and there ...

Are you a member of the core team? If not then I dont want your explanations. I am asking the code specifications and documentation from the core team. And I am not asking them for myself, but for the community.

You should also ask for code documentation and specifications, if you were an objective independent dash community member and not a paid advertiser or employee. I know how they solved the issue, and I will come back to it when I will be sure about the deficiencies of the solution they gave.

But if you are an objective independant dash communty member, and not one of the many paid advertisers and employees who talk over here, then could you please give me a hint about the below:

whether it was resolved in version 12.0 or not,
:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:


and what happened to the votes casted and to the money given before this bug was resolved.
:confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused::confused:


In case the bug was present also in 12.0 version, then here comes the troll = ( introduce the 1 operator that owned all masternodes)
:D :D:D:D:D
 
Last edited:
Back
Top