Instead of using the hash to build the quorum at all once...

stan.distortion

stan.distortion

Well-known member
BTC thread post:

https://bitcointalk.org/index.php?topic=421615.msg12931868#msg12931868

[quote author=eduffield link=topic=421615.msg12931868#msg12931868 date=1447096606]
[quote author=TanteStefana2 link=topic=421615.msg12931853#msg12931853 date=1447096452]
[quote author=eduffield link=topic=421615.msg12931559#msg12931559 date=1447094168]
[quote author=qwizzie link=topic=421615.msg12931482#msg12931482 date=1447093588]
[quote author=eduffield link=topic=421615.msg12931420#msg12931420 date=1447093216]
...
I was waiting for someone to ask what I discovered... Basically, something called masternode input age based quorum layering. Quorums are created using the age of the masternodes, 25% of the quorums are more than 1.5 years old, the next 25% is more than 1 year old, the next 25% is more than 6 months old, then the final 25% is any masternode that is newer than that. It guarantees, you can't control a quorum by just buying coins from an exchange to make new masternodes, there will always be masternodes that are really, really old.
[/quote]

okay i gotta ask : "masternode input age based quorum layering", is that one of four discoveries you made ? if the answer is yes i think you will know my next question ;)
[/quote]

Yes. I also figured out how to implement user/masternode vote blinding, which will allow literally everyone to remain semi-anonymous on the network. Imagine you can vote privately on budgets. 3 and 4 are related to programming, the evolution platform is really nice to work with
[/quote]

All good, one question regarding the use of MN age in selection of quorums. Will they also still be selected from the hash? I hope you can do both because I like the randomness of that. If you can select with both requirements, that's be impossible to game IMO :)
[/quote]

Exactly. Instead of using the hash to build the quorum at all once, you do it in four steps, by age. It's still deterministic.
[/quote]

Re posting here as... well, BCT :/

How reliable is the network time? It worries me it could be vulnerable is all, I'm stuck thinking the block count is a sure indication the network has gone forward but any external source that dictates time to a large part of the network is only as secure as the time source. Maybe that's one of those "what if there was no more electricity?" scenarios but I can't help thinking of it whenever time based criteria come up.

EDIT: Sounds pretty damn cool btw :) I was looking at time-based things earlier and that reminded me to ask is all.
 
stan.distortion So many things about Evolution are over our heads ATM. Evan is just giving us bits and pieces of information, and we're left to piece together what kind of system Evolution will be. From the info that is public now, I suspect that Evolution is going to be so radically different that the things about crypto that we understand or take for granted now will be completely changed. I'm just like you, I hate not knowing things about it, but as my nine year-old daughter says, "Use your patience". January can't come fast enough.... :sad:
 
TaoOfSatoshi said:
stan.distortion So many things about Evolution are over our heads ATM. Evan is just giving us bits and pieces of information, and we're left to piece together what kind of system Evolution will be. From the info that is public now, I suspect that Evolution is going to be so radically different that the things about crypto that we understand or take for granted now will be completely changed. I'm just like you, I hate not knowing things about it, but as my nine year-old daughter says, "Use your patience". January can't come fast enough.... :sad:
Click to expand...


There's a fair bit I'm unclear about already in there. Take MN voting for example, you can't re-cast a vote until an hour has passed based on time, not block count and if time was vulnerable could that stall voting? I can't seriously imagine that being a realistic scenario but what if you wanted finer resolution, what's reliable, minutes, seconds, milliseconds? I'd always seen blocks as the system clock, the tick but a solid time framework means a faster tick is possible and so more operations, just the same as a CPU but with the same kind of potential issues as overclocking a CPU.
 
I'm going to guess here on how it will work. But I think it'll go like this:

All nodes will be assigned to 1 of 4 age groups. The groups would be equal in size, so the breakdown will always be by population of when the 1000 coins were first received in the MN account. All this does is make it even harder for one group to play the system. Why? Well, I can't imagine the difficulty of doing this, but lets say someone was able to clump their masternode hashes (the hash when the funds were first deposited) into hashes that are very similar. I don't even think that's possible, but lets say they found a way to clump 'em so that if they got the closest hashes to the block hash being used, they might be able to see control of the quorum every few thousand rounds?? Just pulling that out of my bum, 'cause getting a group of hexadecimal numbers close to each other so that they might match closes to the block's hexadecimal number seems impossible to me, but lets say they do it. Now they still can't clump together in a quorum because their ages are too similar.

That's all that the age thing does. It doesn't do anything bu require 1 or 2 masternodes from different age groups that are closest to the hash number. It makes what was already virtually impossible, ridiculously impossible. And with that kind of impossibility, you really wouldn't have to worry about which hashes you use.

You see, if we're going to run over 300 quorums every block, we'd have to have a system of which block hashes to use. The last hash would be the safest, as nobody would have time to somehow know their MNs were up for the quorum, and thus prepare for malicious acts. But we could use random hashes of the past, the one latest hash and group from closest to farthest with each quorum, or the last 300+ hashes (however deep is needed). So with the impossible impossibility of the two levels of selection, it really wouldn't matter which hashs we use, even if people knew which one was being used, because you really really really couldn't come up with a quorum full of your own MNs.

It doesn't give any MNs more control over anything at all. No advantage,nothing. It's just ensuring another level of mixing up the groups that form the quorums.

But it does make choosing hashes infinitely easier because it really no longer matters.

Which = take the easy coding way out (and simplicity brings in less holes, thus security)
 
You must log in or register to reply here.
Back
Top