Well they just do the “delete” for an MD, or they modify their copy in their vaults and consensus says the good vaults are in error and tell them to drop that chunk/MD
Really its the coin-accounts. The wallet is the APP and/or the APP’s data kept. The coin-account actually holds the record and only the SAFE code can operate on the coin-account through APIs
Yep and this requires the taking over of a section.
Yea we need to have a distinction between the two and I think that terminology will work.
Of course once a section is compromised (34+% bad elders) then they can disrupt any of their bad actor elders from being churned, through blocking consensus.
Well actually the first section can be the one they get control of first semi randomly, but you are right that they then need to control a specific 2nd section and this would be extremely difficult. It’d be like taking over (controlling) a number of sections while trying to get that 2nd specific section.
Wait. Is the remaining 66% capable of knowing the disruptive 34%? If so, could they among each other decide to call another section for help? Maybe merging with the assisting section to dilute the malicious nodes power?
we propose methods of identifying and dealing with nodes acting with differing types of malicious intent within a section. When the section identifies and reaches consensus that a particular node is a malicious agent then that node is then ejected from the section.
Must the topics of all votes be subject to the two-thirds majority approval? Perhaps some topics could be subject to a 51% rule. Particularly if the section is failing in some way.
If you do that and there are 51% bad actor nodes then they can gain full control by ousting good elder nodes. This is instead of just disrupting consensus
I’m mostly an idiot when it comes to the level of detail required to provide good in-depth analysis of many of the ideas that will be needed to make the Safe Network fly …
That’s why I’d just like to say THANK YOU to all the unpaid genius volunteers (many of whom are in this thread!) who are clearly putting forth a lot of effort to make the Safe Network a great project.
You are the unsung HEROES of the Safe Network community.
I guess what I’m wondering is if there can be ‘types’ or ‘categories’ of votes - some which require two thirds and others which require only 51% … probably I’m just being dumb here.
for example, In some organisations you might have a vote wherein only simple majority is required in order to decide to dissolve the organisation if certain pre-conditions are met.
The issue is that if a section has 51% bad actor elders then if you allow any vote that only needs 51% then the bad actors can take that vote to do whatever the vote allows.
If the vote allows ousting of a node then obviously they would target other good elder nodes.
The requirement is to oust the bad actor nodes before you get to 33% of bad actor elder nodes.
Also PARSEC consensus is only provable with 67% good elders. Any decision to oust a node really has to be done by a good consensus mechanism.
Just a heads-up; I’ve pushed a new commit to the pull request which addresses all the points I’d noted from this thread, the main ones being:
parts now represents a multiple of 250-pico-safecoin
accounts are refunded if a transfer fails due to a non-existent destination account
added a paragraph about how to handle farmed going to zero
Thanks very much to everyone who has contributed so far in this thread - the RFC is the better for it!
I’ve had a chat with @DGeddes since he’s overseeing the revitalised RFC process, and I think the way forward for this one is to change its status to Postponed. It has been useful for me to get my thoughts down on paper, but I think there are still some of the unresolved questions which don’t have clear answers.
The point is that some of these will need answered regardless of safecoin (e.g. Parsec pruning, malicious clients or proxies spamming, push notifications), so it would seem sensible just now to not deviate from our current work, and some of these question will become resolved anyway by the time we need to make a decision on the details of safecoin.
Thanks again to all who have helped here - it’s much appreciated!
Just wondering if we need to have that 1/4 of a nano-safecoin. You went decimal for the parts but then added the 1/4 (non-decimal). Kinda of trying to have your cake and eat it too, but will still cause confusion in the long run. The questions will be why couldn’t you do the proper thing and have all the way down to pico-safecoin. But of course we know that is not possible but it will cause problems to people who don’t understand. One billion parts is plenty for practical purposes even if safecoin is $1000 per coin, or even $1 million per coin. $0.001 is really quite small still (for 1 Million/coin) and the 1/4 ($0.00025) is not going to be much better. But then when is the coin going to be worth $1 million/coin in the lifetime of this version of the SAFE network
BUT then why not just go one u64 (or even signed) and have 0 to 2^32*10^9 and let the UI show it as whole.decimal.
saves the requirement to handle the 2 u32 numbers separately
makes specifying amounts easier for a wallet APP, just one figure not 2
Less load on the network when rewarding people. Only one Add of 2 u64 numbers instead of adding two u32 fixed point and testing for overflow
The user is never aware that there 10 coins is really an integer 10,000,000,000 since all the UIs handle the display of the amount.
Just easier all around for the core code and no harder for APPs
If you go for a signed 64 bit number then you can handle the negative value in the rare (if ever) situation a farming reward has to be subtracted from “farmed” amount and it goes negative.
If we go for 1 instead of 4 billion parts, this means that 2 bits of the 64 bits aren’t used. Doesn’t matter if you use 1 u64 or 2 u32.
If you put these 2 unused bits at the end of the ‘parts’-field, you could choose how to read the data yourself: as 2 u32 or 1 u64. Maybe that big/little endian or something like that will required some byte switching, but that should not be a big problem.
In both cases you should divide by 4 (the 1 u64 or only the parts-field in case of 2 u32) to get rid of the 2 unused bits. That division is a very cheap operation.
Even more, you could still do the same even if these 2 bits are used for quarter nano-Safecoins: worst case you lose 3 quarter nano-Safecoins.
Or do you think we should reserve these 2 bits for possible future usage. Like up to 4 different sort of ‘types’ safecoins?
But if you want to be that way then why not have the parts as u64. Just as easy and not expensive on space. Then you can have 1,000,000,000,000,000,000 parts. And guess what you could start with a u32 for parts (0 to 1 billion) as ver 1 of coin-accounts and then go to u64 (0 to 10^18) as ver 2 and the core code handles it easily as pie.
There is good reason to have it pure decimal rather than binary to decimal/binary mismatch. If you are going to decimal then don’t spoil it by going half way and having part decimal and part binary in the parts.
To have 250 pico-safecoin then people will ask “Why not 1 pico-safecoin?” then you have to explain its u32 but we went decimal to make it easier for financial calculations, but then we couldn’t help ourselves and added 2 bits of binary to make it so you people get confused and make our lives hard having to answer the same things over and over again.
Ever had to explain why you cannot specify bitcoin to the 8th decimal place even though it shows 8 decimal places. Its a pain and you have to tell people that its just the bitcoin people couldn’t really get 8 decimal places and its because of a mixup with decimal and binary.
Don’t make the same mistake by trying to bring in quarters into savecoin parts. Remember the American quarter is really 25 cents and you can have 1 cent as well. a quarter of a nano-safecoin is not the same thing and will still be a thorn in the side of SAFEcoin.
1 billion parts is plenty and to utilise the other 2 bits will bring more confusion than benefit.
EDIT: My preferred option is to have only one figure that is u64 and use fixed point and the integer goes from 0 to 2^32*10^9 - 1 to simplify things (see my post above) and then we could have safecoin increase from 2^32 to 2^34 if people can agree to the MAID->safecoin exchange at 1:4
A virus or human forgetfulness causes 99 percent of the safecoin MDs to be destroyed 15 years from now, but the rest of the network data is ok. Having way more divisibility than was necessary at launch allows the network economics to continue operating flawlessly. I say go for 128 bits just like ipv6
I had read your last post too quickly, I had 2^32 Safecoins * 10^9 parts/SafeCoin as 1 u64 number in mind when replying.
If the estimation is that 1 nano will not be small enough and it will be too difficult to introduce a new u64 then for smaller units in the future: make a distinct u64 parts field right away.
But if that is not the estimation than 2^32 and even 10^9 part units will be enough.
Fact is that if you use 10^9 of 2^32, you use 23% (< 1/4th) of the range and if you translate that binary it means that somewhere 2 bits are not used. Because we think no one will need something smaller than 1 nano in the future, you could be right to not speak of this, to keep it in 1 nano units.
But if we are mistaken and something smaller has to be introduced later on, there is at least a bit (2 bits to be exactly) of extra ‘margin’ the can be used until the new solution. You could argue you should avoid using these 2 bits by all means, but they’re there.
And now I’ve enough bit****** (Dutch synonym for nitpicked) about this subject
Having headroom to have more supply is also useful. Yes, it has been agreed that there will be a fixed limit at launch and it is important to keep the promise, but this doesn’t mean forever. If it makes more sense for the supply to grow as the value of the network increases, it could lead to a more stable currency.
Yes, we want scarcity, but not so much that no one ever spends it (HODL!!). I’m not suggesting changing the farming algorithm on day one, but keeping the door open foe future flexibility may be desirable; relaxing a cap off a value will likely be easier than changing the data type.
Edit: before anyone gets jumpy, if user base is growing quicker than supply, we will get deflation, where each coin is worth relatively more than before. Bitcoin difficulty, sigmoid curves, etc, acknowledge this but in a rather crude way. With safecoin we have better supply/demand side metrics, as it is linked to storage cost. We should make the most of this.
A bit OT, so let’s not get too lengthy on this, but
If you by social engineering are targeting elders, and want to find all within a section, then your window of opportunity will decrease by them constantly changing section. It will be harder to even reach 1/3 of a single section, which was the point.
Lower frequency of section change will make it easier (cheaper) to - within a given time frame - find all elders in a section, higher frequency makes it harder (more expensive).
