I have read more of the thread now. Implementing divisibility will move the SAFE network launch date way into the future. It adds far too much complexity.
Instead, launch the network with the current model with indivisible safecoins. Then there is a problem with PUTs since from the OP:
“Now that you have an account with value, a put request will be successful if the ClientManagers can deduct your account for the size of the data.”
That requires that safecoin must be divisible. To solve that problem simply make all PUTs free. And the farming reward will have to be in whole safecoins. And remove the limit of the safecoin supply (if that’s legally possible).
Not actually. There is a resources counter in your account and that is reduced as you PUT, then when that is empty another safecoin is spent which buys another lot of resources. That is how divisibility is initially implemented. This thread is about actually dividing the coin itself
Account, do you mean the safecoin wallet? If not, what is the difference between account and wallet? Or do you mean the account described in the OP (that will add a lot of complexity)?
[Remember that this thread was about coin dividing, not this resource purchasing.]
Part of the data used to keep tabs of your account/client. There is no added complexity since this is what the design is meant to do. When you purchase your first PUT resources, it is actually a block of available PUTs. The actual number of PUTs available in the block is determined by a dynamic system and when you use up that allocation you need to buy another block. It has been suggested that the client will allow you to set the number of safecoin it can use in this purchasing so as to not have it asking every few GB or so of uploads. (yes it is expected that one coin will in the early days get you GBs and more later on as physical resources increase and/or become cheaper.)
Oh, the OP describes the current model. I thought ‘account’ meant some new added complexity. My mistake.
And the account can hold fractions of safecoins, but only as a number, not as coins. And in the future that can be used for implementing ways of dividing safecoins via the accounts while the safecoins themselves are still indivisible.
That is first iteration of the discussion on coin dividing.
The bit I mention is the resource purchasing that is part of the current proposal that being written - no coin divided, just a system determined amount of storage. One coin buys X chunks, but you could think in terms of fractions of a safecoin (which is the OP starting point). The OP is discussing dividing the coin, not current resource purchasing. May sound similar and the OP IIRC was going to use coin divided also to allow resource purchasing which is why part of the OP sounds like the current resource purchasing.
Would it be possible to use the account to write ‘checks’ with arbitrary values? And instead of sending safecoins the checks are sent as transactions. If Alice has 100 safecoins in her account and wants to send 40.50 safecoins to Bob, then a check is created with the value 40.50 safecoins, and when Bob receives the check then Alice’s account is reduced to 59.50 and Bob’s account is increased by 40.50. Each check is only used one time and then destroyed.
For the SAFE network, processing a check is as easy as processing one safecoin. And each check can contain any value. So a check with the value 0.00001 safecoins is as easy to transfer and process as a check with a value of 100,000 safecoins.
Do you underdstand the basics of SAFEcoin and how it works?
Because there is no decimals. Each coin has 32 “blockwatch” neighbor nodes that remember who owns it. When the owner signs a transaction saying somebody else owns it the consensus of the ‘Blockwatch’. determines that the new owner is Bob… This is different than Bitcoin, Bitcoin moves from place to place and it’s owner is determined by it’s ancestry. SAFE coin stays put and it’s owner changes.
The most popular “decimal” option was being able to transfer storage units instead of decimals… Gigabytes as change. I suspect it will be a noisy enough protocol as it is – If I send you 10 SAFEcoin it will require 280 out of 320 computers to say “everything is kosher” I envision this like quarters falling into a vending machine – It won’t all happen at the same time due to latency etc. It will be interesting to see how it works – but making it more complicated at this point is probably not the best step – lets see how it works first then worry about the details as the details become important. (A long time from now, most likely)
But the accounts must be secured in a similar way. So simply reducing one account and increasing another account wouldn’t that be something the network easily could do?
The OP describes an account where the amount of safecoins is represented by a single number. And with for example a 64 bit integer there would be a lot of divisibility possible. So the safecoins themselves are a separate construct.
Wouldn’t the accounts be enough to handle the safecoins? And for example a 64 bit integer as the account number allows divisibility. And a transaction reduces the value of the sender account and increases the receiver account by the same amount. This would allow very efficient transactions, from micropayments with a fraction of a safecoin to large payments of thousands of safecoins.
In other words, do the safecoins really need to exist as separate entities (other than for fancy stuff like being co-owned and multi-sig, etc)?
It does make it far more secure than using a simple balance value. Because they are actual entities with an ID, the responsibility for coin ID’s are spread over the network. This makes it extremely hard to counterfeit a large number of SafeCoins.
There are some really interesting ideas in this thread, but I don’t see why we wouldn’t simply implement one-way subdivisions when the need is there? Yes, the network load will increase as more subdivisions are made, but we can assume that the network grows proportionally to the need for subdivisions.
The single account number (yes, it does sound vulnerable, ha ha), would have the same security as everything else stored on the SAFE network. And if a user’s account gets hacked, then they can steal all the safecoins regardless of whether they are stored as separate safecoins or as a single account number.
Transactions based on accounts would be two-way since all the safecoins can be stored as account balances instead of being separate entities. And the accounts would handle divisibility. It may be infeasible to upgrade the SAFE network. So it’s crucial to get version 1.0 correct from the beginning.
I’m not talking about hacks, I’m talking about counterfeiting. Creating new SafeCoins out of thin air. With a balance value, one only needs to compromise the management of one account to create as many SafeCoins one wants (only limited by the 2^32 hardcap). With SafeCoins as entities, you need to compromise the management for every single coin address you want to create.
Yes, I suspected that it was something about security. If I understood it correctly, one single safecoin is handled by 32 nodes (which are randomly distributed around the world). If the account number was like 32 safecoins, then that would be massive security. That would be 32*32 = 1024 nodes. That makes the account safe. It would add too much complexity to the core code perhaps. EDIT: And if that’s hideous overkill, then 128 nodes can be used or something like that.
I’ve been thinking the same the last weeks. I do not like too much the binary division but, perhaps, return to the original idea would be best. Activation of the division could go by stages as the network grows.
In addition the reward might also be divided so that small farmers may get some profit.
If the network grows much, win a complete safecoin could be a very difficult task.
I have seen this idea crop up a few times and I find it disconcerting for these reasons:
The need is there from the start. No division from the get go means you rule out any project that will depend on micro (and nano) size transactions. No micropayments to implement pay per article or resource item type transactions. I am currently doing some development work in the IoT space - so even if I see an opportunity to leverage the Safe Network it will not be possible. It would not be feasible to allocate 1 undividable Safecoin worth of resources per sensor.
Leaving such fundamental functionality until some later date “when the need is there” will mean it may never be implemented due to a (rightfully) conservative community that may vote not to upgrade or change anything for fear of breaking something. Just look at the bitcoin block size limit controversy and how long that may take to resolve (if ever).
One-way subdivisions solution is not implementing a division system. It is instead creating separate “alt-Safecoins” that need a secondary exchange market system to roughly approximate coin division. I have posted lengthy reasoning a few times now flagging how risky this is. At stake: the difference between Safecoin becoming a currency that oils a market ecosystem, or a simple token to exchange for resources on the Safe Network and not much else.
Most early investors probably assume Safecoin is going to be a currency. If the concerns I have raised prove valid, there may be some animosity if Safecoins remains little more than resource exchange tokens and do not prove suitable for use in a vibrant digital economy ecosystem.
I understand the reasoning: 64 bit 2.1 quadrillion “irvinoshis” per Safecoin or similar to implement a user friendly division system is speculated to be too burdensome given the current design. Given what is at stake perhaps better design alternatives are possible with benifits beyond this issue. Meta-structured data objects, hierarchies that allow many owned structured data objects to be transacted at once?
Judging by the replies to my posts on this subject I sense that perhaps my concerns over what is at stake on this issue are not shared by many. Lets just say I have been burnt by smaller usability concerns than this issue on more than few big software projects I have been involved in over the years, so I may be over-sensitive to these kinds of risks :-). Perhaps the community will consider a test experiment that could be run on the live testnet: Two different simulated marketplaces spanning micro to macro Safecoin transactions selling widgets, with two different Safecoin designs. let some fairly non technical people buy and sell using the proposed one-way exchange “division” system, and another with 64 bit naturally divisible irvinoshi Safecoins. Quantify just how big an issue not having a natural division in place might be. I suspect the result may surprise.