If safecoins are going to be divisible, then for all that is good and holy, have names for the decimal places and NEVER use decimals. In fact, delete the term “decimal” from your skull.
decimal is only the mathematical term for it. We have to use it or else the mathematical/program logic cannot be explained
You could have the first 2 decimal places as cents, and the next 6 decimal places as micro-cents
In fact I would prefer to see that as an account option so that the user sees the divided coin amount in terms they are more comfortable with. Maybe have 3 or 4 options, rather like how date can be customised. (month-day. year OR day/month/year etc)
Anyhow that is a cosmetic aspect of the implementation and when divisibility is introduced then certain make comments in the RFC for whatever method is proposed to divide the coin.
My bad, I didn’t mean to say the program doesn’t use decimals, I meant that the end user never sees them (by default).
1 Like
This question might have been answered already.
If 1 SC uses 1 MB, then splitting 1 SC into 100 smaller denominations uses 100 MB?
Does splitting SC require exponentially more storage?
If it does, should the Network charge for the extra storage required?
If it’s free, I can imagine a balloon attack by spam splitting all my coins infinitely to fill up storage space.
This is what is looks like…
2 Likes
I’m not Irvine, but would seem that the network would have to change the amount of storage/computation you get per safecoin as the value of safecoins goes up/down. I think I read that the network adapts it’s payout to how much clients are mining with respect to the storage being used up, which will enviably increase or fall with the real world price.
To do otherwise would open the network up to the same thing that happens with price controls: supply shortages and people getting very pissed.
2 Likes
Very interesting problem and one that has to be solved. Some thoughts are
1 x SC is a SD object (100KB)
Under a traditional division in to safe cents would require 100 SD objects that are say “SAFEcents”
The network would require 99 times the processing as required for one coin to transact 99 “SAFEcents”
Then we should charge for the SAFEcoins too.
The charge would have to be very small to be useful, so the fee doesn’t really stop someone starting a balloon attack. Just get 1 SAFEcent and a coin has to be split. So sending 1 SAFEcent to another causes the split if you only have SAFEcoins in your coin address.
But to do the full attack then ignoring the fees (if you introduce them) you would still have to be able to access all the SAFEcoins that you split.
BUT
if you are talking of my proposal then there is only one SD per note which can hold any value upto, but not including) one coin worth.
The notes are combined by the core when 2 or more are supplied for a transaction.
So it would be possible to keep splitting them but splitting only occurs in a transaction when one note has “change” returned to the payer and the receiver gets one.
There is a finite time to do a transaction, which limits a forever splitting.
So yes it would be possible, but how long it take and effective would it be? Cannot this be done with BitCoin with zero transaction fees
This is why I suggested that the system limits the division to a set number of decimal places and only increases the number as the need arises. At each stage the network will be magnitudes larger and able to absorb such an attack.
Maybe 2 places initially, then 4 when needed. By storing them as if the whole 18 decimals are used, it means no difference to the processing other than how far division can go at that time.
1 Like
Does your proposal basically turn 1 SC (SD) into a mini ledger?
I really don’t want a “fee” for splitting Safecoin, even though I understand why.
If this is a problem, it pushes me back to SAFE GB or a ledger alternative.
I am wondering for my proposal, the SD addressing is done in such a way that the account / coin address is in the key, and the core rather than “sending” the note to the receiver it rather updates the note the receiver has.
Now if the note at the address fills up (value would be >= 1 safecoin) then one of 2 procedures could be followed.
- the core adds a second note with the rest OR
- unfreezes a coin
There are advantages to both methods 1. allows the 1st note to be “in use” with another transaction without delaying or interruptions second method is cleaner
This reduces the effect since the attack would require the creation of valid accounts with valid coin addresses for each split they don’t want recombined. This takes time and limits the account.
So combined with the division being limited to an appropriate size and the recombining effect the attack becomes more time consuming, costly to the attacker and additionally the cost of he coin to be split.
It has the effect of freezing a coin and creating 2 “promisary” style notes that the network recognises as a divided coin value. So not a ledger but a note that can have its value changed and reused. A (mini) ledger implies history, and this would not have one, other than the SD’s previous owner ID field
The SAFE GB is a similar system but ties value to something that is not seen as having value outside of SAFE network and its value is not tied down but whose value rides the waves of FR. The “note” is absolutely tied to SAFEcoin, and does not vary.
SAFE GB does not have the scope of trading opportunities as the coin or note has. Its a count of saved up resource that varies in relation to SAFEcoin and SAFEcoin varies in value at the whim of the markets. So SAFE GB would be seen as too volatile for the general trader whereas SAFEcoin/note will have so much more desirably for trading.
Or said another way, SAFEcoin/note can be immediately used to settle a sale without the seller using the network for anything else other than receiving payment. SAFE GB would require double handling, and while anything can be used to pay/barter for purchasing, SAFEcoin/note would be preferred.
For transactions with an uploader SAFE GB would be great and solve the divisibility issue. But as an all round token of payment it lacks.
BTW: Wouldn’t the balloon attack also affect SAFE GB?
No because SAFE GB is a PUT ledger. Regardless of the amount, it’s still only uses 1 SD (1 MB).[quote=“neo, post:29, topic:7619”]
For transactions with an uploader SAFE GB would be great and solve the divisibility issue. But as an all round token of payment it lacks.
[/quote]
Agreed, but I do think it will be more spendable because it’s inflationary with a somewhat stable fiat value.
1 Like
Where is the SD kept, I thought it was kept with the account?
If it is then my revised way to more tightly associate the note’s SD with the account will dramatically cut the balloon attack to something closer to the SAFE GB attack profile. It won’t really change the usefullness of the note, since its held with the account anyhow, but slightly increase the transaction effort done in the core when sending a coin fraction. (Add one unit of work to the 2+ units of work the note transaction already does)
I think the attack against these is then to create multiple accounts to split the note OR SAFE GB into. 1 unit of the divided coin (be it one SAFE cent or 1 microcent) OR 1 chunk of storage (or is it 1GB the smallest). That is the attacker creates an account and sends 1 unit to the new account, then repeats.
Bottom line is that I think making the note, a non-ledger fractional coin value, as attack “safe”/“prone” as the SAFE GB should be possible with relative ease as seen by the simple refinement. Something to explore if it becomes a serious proposal.
And for sure we need to explore all the attack vectors possible.
BTW on another note (no pun intended) we have the problem with SD data objects and how they maybe attacked. If we, while put cost is near zero, buy up 2^60 SD objects for one coin since the put cost gives us 2^64 puts (SD creates) and requiring minimal upload traffic to do so.
Imagine the storage required in the ?data managers? which each store a copy of each SD existing whose XOR address is in that data manager’s group.
Thats a story for another topic.
1 Like