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.
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.
This bug was resolved in PR1135.
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.
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?
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.
A discussion between two developers about c++ specification and what would be 'the best approach' to apply those is shocking to you ? Or did I miss what you meant by "The Specifications" ....
From the discusion between the developers.
tgflynn said:
The C++ specifications refer to the implementation of the design to the language c++. The c++ language specifications do not require necessarily the deep understanding of the design.UdjinM6 said:Other signals are not clear for me too tbh
When the developers talked about signals, this is what signals they meant.
// SIGNAL VARIOUS THINGS TO HAPPEN:
enum vote_signal_enum_t {
VOTE_SIGNAL_NONE = 0,
VOTE_SIGNAL_FUNDING = 1, // -- fund this object for it's stated amount
VOTE_SIGNAL_VALID = 2, // -- this object checks out in sentinel engine
VOTE_SIGNAL_DELETE = 3, // -- this object should be deleted from memory entirely
VOTE_SIGNAL_ENDORSED = 4, // -- officially endorsed by the network somehow (delegation)
VOTE_SIGNAL_NOOP1 = 5, // FOR FURTHER EXPANSION
VOTE_SIGNAL_NOOP2 = 6,
VOTE_SIGNAL_NOOP3 = 7,
VOTE_SIGNAL_NOOP4 = 8,
VOTE_SIGNAL_NOOP5 = 9,
VOTE_SIGNAL_NOOP6 = 10,
VOTE_SIGNAL_NOOP7 = 11,
VOTE_SIGNAL_NOOP8 = 12,
VOTE_SIGNAL_NOOP9 = 13,
VOTE_SIGNAL_NOOP10 = 14,
VOTE_SIGNAL_NOOP11 = 15,
VOTE_SIGNAL_CUSTOM1 = 16, // SENTINEL CUSTOM ACTIONS
VOTE_SIGNAL_CUSTOM2 = 17, // 16-35
VOTE_SIGNAL_CUSTOM3 = 18,
VOTE_SIGNAL_CUSTOM4 = 19,
VOTE_SIGNAL_CUSTOM5 = 20,
VOTE_SIGNAL_CUSTOM6 = 21,
VOTE_SIGNAL_CUSTOM7 = 22,
VOTE_SIGNAL_CUSTOM8 = 23,
VOTE_SIGNAL_CUSTOM9 = 24,
VOTE_SIGNAL_CUSTOM10 = 25,
VOTE_SIGNAL_CUSTOM11 = 26,
VOTE_SIGNAL_CUSTOM12 = 27,
VOTE_SIGNAL_CUSTOM13 = 28,
VOTE_SIGNAL_CUSTOM14 = 29,
VOTE_SIGNAL_CUSTOM15 = 30,
VOTE_SIGNAL_CUSTOM16 = 31,
VOTE_SIGNAL_CUSTOM17 = 32,
VOTE_SIGNAL_CUSTOM18 = 33,
VOTE_SIGNAL_CUSTOM19 = 34,
VOTE_SIGNAL_CUSTOM20 = 35
};Signals is smth Sentinel works with, Dashd part is built to be Sentinel-data agnostic transport layer which means that as a Dashd dev and not a Sentinel dev I'm not fully aware of packets design (though I understand it in general) or Sentinel code. It's like I'm building the Dashd-"road" for Sentinel-"cars" - I know what they are, how large they are going to be in general i.e. how large "exits" should be, I know how much of them will be there at the beginning and that "traffic" is expected to rise after some time. I don't need to know what the color would be or how many gears they would have, as a road builder I don't really care. Speaking of these "custom numbers" specifically - they are smth reserved for the future use, like unused op_code's in bitcoin. What we were discussing is simply the way to build it using a better pattern so that the "road" was easily extensible if/when needed later.
The unused op_codes in bitcoin are the minority, and the used op_codes the majority. But in our case it is the reverse, we have too many unused vote_signals and just a few used. And this is strange.
Why the core team designed to store the votes outside the blockchain? What is the rationality or for what reason this specific design has been selected among others? Is it maybe because they dont want to keep the vote history?
Ok. as long as our friend @nmarley dont want to reveal, I will reveal his plans. The reason so many vote-signals exist it is because they will be used for alternative proposals. This is what he is planning to do.
