Introduce the 13 operators that own 3000 masternodes.
- Thread starter demo
- Start date
demo
Well-known member
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?
demo
Well-known member
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:
...and one of the trolls that troll-rated me (@flare) answers:
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:
flare
Well-known member
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.
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.
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.
demo
Well-known member
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?
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:
1whoLikesDash
New member
@demo=troll
demo
Well-known member
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:
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.
demo
Well-known member
"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
demo
Well-known member
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.
Last edited:
Or more to the point, put the version control behind the masternodes and let them govern who can do updates.
demo
Well-known member
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.
- One private key that holds your money
- 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) )
- 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
Well-known member
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.
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.
Nitya Sattva
Member
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.
demo
Well-known member
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?
Last edited:
Nitya Sattva
Member
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
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:
demo
Well-known member
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:
In case the bug was present also in 12.0 version, then here comes the troll = ( introduce the 1 operator that owned all masternodes)
Last edited: