Fraser's Safecoin Alternative Design (Postponed State)

Development RFCs
122

SO WHAT. Honestly its not an issue. If it was an issue then do as @jlpell says and go 128 bits from the start. We are only talking of a few bytes storage the difference for maybe 10+ billion coin-accounts when the world is using SAFE. 2 bits lost compared to the very large number of hours wasted explaining why we went with a decimal+binary for parts and why we cannot specify amounts down to the lowest decimal (pico). If you leave off the 2 bits and have just nano without the binary tail then you save every bit of confusion and massive time waste. Bitcoin is such a pain since they show 8 decimal places but you cannot specify amounts to the 8th place. Its like quantised to something around 500 Satoshi. And every new person comes across that at some stage and someone else has to explain why and both are still likely to be confused and just “put up with it”

We can be better and just have nano and be able to specify amounts to the full 9 places and everyone knows what is going on. Add the 2 bits and it greatly confuses understanding.

Also the 2 bits might be useful for something else. So lets just go for the single 64 bit integer using true fixed point.

And as a lot of products do (eg IPv4 & IPv6) you can have a version number and the software knows if the coin amount is a single 64 bit integer or a 128 bit integer holding the amount. If 64 bits then its fixed point with 9 decimal places and if 128 bit then its fixed point with 27 decimal places. (or is that 28, I didn’t check)

And when the core code writes back the new value after some transaction it always writes it back as the later version. So no loss of precision ever

3 Likes
123

Yes you are right for social engineering. But that is one hell of a job there. Its not like people will know which section their vault is in. Then you are looking at a virus/malware that infects the vaults for all who are tricked into installing it.

But yes if you can do that then it would. But its still like the effort an attacker who has to throw vaults at the network since the social engineering is not going to know which sections the vaults it will be able take over will be in. Fast churn of elders might actually make the statistical probability of taking over a section a quicker job. The birthday paradox analysis says that, your chance of getting enough bad elders in one section will happen at some stage of churning elders. So the faster the churn then the faster one section will have enough bad actor elders to take over the section and once taken elder churn can be stopped by the bad actor elders. So the faster the churn the more chance of taking over a section before enough people stop farming or upgrade to new version of the vault.

If too slow then the attacker who throws bad actor elders at the network can have a better chance of taking over a section for a certain cost. (they basically target a set of sections by stopping any of their nodes that do not get into the set of sections)

There will be a certain rate of elder churn that is not too fast benefiting the social engineering “random” chance, but not too slow to benefit the adding bad actor nodes.

1 Like
124

Really exciting to see things evolving in this area!

@anon86652309, about the FIFO queue for transactions:

Is the idea that only a certain length of transactions logs will exist? I see a queue as something that fills and empties (first in, first out).
I can see how maybe ever growing can be a problem, but on the other hand, the fixed length is a magic number. I assuming though that there is a very specific and isolated need of this log, and that it can therefore be more easily determined how long it needs to be.

Are there any more details available on this part?

And some more thoughts here, jotted down while getting to know this proposal better:

“A potential drawback of this proposal is that coins which are recycled aren’t replaced back to the section where they were initially farmed.”

How big of a drawback is this, and exactly why? Is it because it will cause imbalances in section supply?
What about adding the section id to a farmed coin, so that it can be recycled back where it was farmed? But that would lock a coin to always return to where it was first farmed. Would coins be farmed evenly over the sections, in all times and stages? In that case such a static life cycle would keep supply balanced over the sections by doing this.

Something that dynamically evens out supply seems preferable though (could be other things than forwarding the request as per the proposal).

2 Likes
125

The farmed amounts are not kept as individual amounts. The farmed amount is added to the coin-account balance. So I doubt this is a viable method as then you have to keep account/ledger of each farmed amount and since Fraser is suggesting the farmed amounts are very small this could cause a lot of problems.

Its needed where people are using transaction numbers so that the person receiving the amounts can know who has actually paid and who has not.

126

Yes, definitely so.
So, dynamic re-distribution of the supply then.
Would there be any other ways than the forwarding suggested in the proposal?

Ok, so, it seems one built in limitation then is that verifying the above, can only be done within a certain number of transactions (per coin account?). After that, the queue won’t contain the information.

127

???

Are you suggesting the farming rewards are also in the transaction FIFO?

That FIFO is for people sending amounts to others when there is a transaction# included. I did not think it was for farming rewards

I also asked what happens for shops that sell thousands of items in hundreds/thousands/more orders. Fraser did suggest that FIFO’s could be replaced by sending messages to the wallet when a payment is made. Then there is basically no limit.

128

Hi all,

Just thought I should let you know that I’ve added the RFC to the Github repo and it’s in a postponed state for the moment.

David.

4 Likes
130

No, not at all. I was talking of two subjects separately, the farming/recycling and the tx FIFO queues. With the mention of forwarding, I am referring to this:

We may need to handle the case where a section is receiving payment (e.g. for a Put request), but its farmed amount is less than the payment, meaning the coins can’t all be recycled by that section. This would seem to imply a failure of the farming rate, but potentially we’d need to cover that situation, e.g. by having that section forward a specific new type of message to a neighbour section which can handle recycling that amount of coins.

1 Like
131

I didn’t mean that fact as an issue, but as a possibility/opportunity to increase the precision to maximum already available, potential capacity. So not because I think this extra precision is really needed, but because it is there and the downsides are not that obvious, at least not to me. Not that I mind should these 2 bits not be used, or be used for something else in the end.
But I’m not completely following/understanding the ‘difficult to explain’-part.
I get if you use a base 2 number of parts (2^32) instead of a base 10 number of parts (10^9), that you get annoying, difficult to explain, rounding errors in base 10 format when dividing. Like it is the case with Bitcoin.
But that you could have quarters, that is less difficult to explain: fiat money users are already familiar with that concept. There will be a lot of other things that will take a lot more time to explain about the Safe Network, I think.
And shouldn’t it be more important to look how to prevent or discourage the usage of unnecessary precision in practice? Like if 10 SafeCoins are divided by 3 nearly equal parts: something like 2 * 3.33(0000000) + 3.34 and not 2 * 3.333333333 + 3.333333334 or 2 * 3.33333333325 + 3.33333333350.
Whatever is exactly described in the RFC, I don’t think the ordinary Safecoin users will care.

132

So no one liked the idea of reducing the max number of safecoin to 4 billion eh (instead of using the full u32 address space)?

133

I assume you mean the idea described at ‘Caveat C)’ here.

A disadvantage is that 4 billion (=2^11*5^9) is not a power of 2. From the RFC:

this means that for a section with Prefix length n , it will be responsible for 2^(32-n) safecoin.

2^11 = 2048 as maximum number of sections isn’t that much. Although if the parts-field is also used to divide, the maximum number of sections with exactly the same total issuable Safecoins increases to 4,2 million (=2048^2).
Probably not an unsolvable problem, but certainly less elegant than having 2^32 Safecoins.

1 Like
134

And to do that you increase many fold the confusion and questioning of why its not truly decimal to 12 places (pico). Much better to just keep to 9 places and waste 2 bits. And if you want more places later then add them by increasing the variable size in Version-2 and the code handles it easy. Its a human interface thing.

That is still a decimal whole number, just limited to 4,294,967,296 and people handle maximum amounts of things

But a decimal+binary decimal places is not easy for most humans.

“Why in the hell do you have it to pico quantities but I cannot bl**dy specify it to pico accuracies. Its stupid just like bl**dy bitcoins idiotic 8 decimal places that isn’t really 8 places. Now SAFE got this 12 decimal places but its not really 12 places what the shit.”

Isn’t the USA the only place with Quarter Dollars (== 25 cents a whole number) And you can still specify down to the cent. I notice USA doesn’t have quarter hundredths dollars OR quarter nano dollars. For good reason its trying to mix and match numeric systems. Its confusing for any one who doesn’t understand binary.

And people hate the inability to specify accurately to the 8th place. But they have to live with it even they curse it. Lets not do that with SAFE, lets be consistent and financially accurate.

And your quarter nano is worse than this, yet you use this as an example of how it doesn’t work for all things.

Well guess what there are well defined rules when working with purely decimal places and the world is happy with it. Because the rules are followed and everyone knows them by the time they are out of primary school.

BUT a decimal+binary places system has no rules for dealing with 1/3 of a coin. Even your decimal+binary places system cannot handle this. And its confusing that you cannot specify 0.333333333333 or 0.333333333334, but its 0.333333333250 <— “what is that, its nothing like 1/3 rules”. Thus confusion and cursing just like non technical people do with bitcoin when they try these sorts of things.

They do care when their interest payments are 0.333333333250 instead of 0.333333333333 And they curse the banks all the time.

BUT if they see 0.333333333 and they know that there is only 9 places in the calculations then because they learnt the rules in primary school then they understand.

3 Likes
135

So binary is cheaper and more efficient for the network,

But decimals are much better for humans.

I’d go with binary. Because SAFE will outlast humans :relaxed:

2 Likes
136

Not really

All decimal is is a representation of the integer stored in a u32 or u64.

No matter whether you use binary or fixed point, the display requires the same effort. The addition/subtraction done by the program is the same binary

Remember binary and decimal integers are just the same thing to the CPU. The difference is just not using the whole range of what the u32 or u64 are capable of.

In this situation is binary is dividing the coin by 2 for each bit. For decimal you use the whole as an integer and display it as decimal places. Binary requires the same display process but have to manipulate it into a decimal for display. So in fact it is more effort for binary parts when displaying and no difference in processing except decimal doesn’t use the whole possible range of the variable.

I’ll disagree here. SAFE will evolve at some stage and humans will still be the major users of the network at that time and IoT will be larger in number but less in actual use. Anyhow IoT understand fixed point as well and has no overheads in using them.

EDIT: And to be even more efficient (human and machine) then use one integer to represent the amount and use fixed point for better human and financial interface.

4 Likes
137

I understand that non technical people could get confused when seeing 0.333333333250 instead of 0.333333333, even if they get more in the first case: 1 quarter safecoin, 250 pico-safecoin or whatever you want to call it.
In the ideal situation it shouldn’t come this far, because a reasonable client implementation wouldn’t use the maximum available amount of precision (when not needed), they would use 0.33(00…) or 0.333(0000…).
But some Safecoin client implementations won’t be able to resist the temptation: they’ll use all the available precision at the cost of clarity. So don’t allow them to use 2 extra bits, if there is real concern that this will give too much confusion (which I personally doubt: it’s a terminating, not a repeating decimal). But more important, what are the (other) ideas/strategies to prevent or minimize the usage of unnecessary precision? Or is 0.333333333250 a big problem, but 0.333333333 totally fine?
Here a recent real world example of rounding to something different than 1 unit (Euro cent): Belgium is short of small change

138

I believe you’re wrong. According to the Bitcoin wiki, the actual unit is the Satoshi, expressed as integers:

[the output value is a] non negative integer giving the number of Satoshis(BTC/10^8) to be transfered")

Bitcoin as a unit with 8 decimal places is just a UI thing.

2 Likes
139

Bitcoin core doesn’t let you last time I tried. And I’ve seen it mentioned elsewhere as well. So there are a number of us living under the illusion that one cannot specify to the 8th place. You can try, but it won’t pass through the mining as exactly what you specify. (yes past experience so it might have changed??)

140

This is a wallet issue because at the protocol level amounts are expressed in satoshis (in transaction outputs). If you navigate to a block explorer you will find many transactions with 8 decimals. For example this one : Blockchain.com Explorer | BTC | ETH | BCH

4 Likes
141

Miners will not accept anything below 547Satoshi

This used to be somewhere around 5400

2 Likes
142

Maybe Bitcoin’s mistake was the size of the default BTC unit; it is too large for anything day to day. The UIs have made it easier to use smaller denominations, but it still seems a little contrived.

Either way, using whole numbers at the back end seemed to work well for Bitcoin with satoshis. I think we should do the same with SAFECoin (or troons or Irvines or whatever!).

5 Likes