I believe Oetyng said in another thread that throwing more people at another task doesn’t always necessarily mean faster release and so this is something he can do in parallel without taking away elsewhere.
11 Likes
OK do you mean slower release above instead of faster? That would make more sense.
Any explanation as to how these spare resources came about and why they can’t be used to make the Network be released faster would be very comforting. 
However, sometimes in a complicated process it can be difficult and exhausting to explain internal workings to outsiders. I understand that too.
I suppose we could ask 9 women to make a baby in 1 month.
13 Likes
I think you’re misunderstanding my text. This shouldn’t wildly affect any release by the sounds of it. So no need to panic or feel the goal posts have been moved.
1 Like
I hate that expression as an analogy for software development. It’s what poor managers say as an excuse that even worse managers acknowledge as valid.
*the overhead in parallel development does not mean you can’t scale infinitely though, for a project of this size I estimate that is in the 30-50 range.
I’m not panicking just asking basic questions. Although actually resource allocation is maybe not as basic as I thought. Don’t worry Maidsafe has years of credibility with me! You guys are the ones that seem worried.
Thanks for all your effort!
1 Like
I love your analogy. It’s obvious that a baby grows inside one woman and takes nine months to form. A computer project might also be like that.
With the current model, the elders know the total wealth of all the users in their section. With the DBC, not.
6 Likes
Hey @jlpell, this quote from the blog mentioned above’s explanation of DBCs caught my attention and maybe answers some of your question.
“It should be noted that in verifiable DBC systems the fact of still having valid DBCs is true even if the mint is taken down. And these DBC systems are recoverable: Another entity is able to just continue operating from the known public state”
This, for us, would be true if a section disappears and also if the whole network goes down, assuming Maidsafe’s implentation satisfies this condition. Network goes down somehow, well it’s restartable, off we go again and our Safecoin’s value has remained stable, awaiting restart? If I’m not over-inferring here, that sounds pretty much like something I’m happier the network is capable of, even really excellent to have as part of an MVP.
7 Likes
This all makes sense. Thanks David. How about divisibility in the described system? As I understand it, to blind sign while still assigning a value, the bank would use different keys for different denominations. Is the plan to use denominations as well? How does that affect the granularity of divisibility? I guess the smallest unit of safecoin could be also employed, which may help validation that the maximum supply is set but may not be efficient given the gargantuan number of units. I have no doubt that @oetyng is on top of that as very fine divisibility is something he previously mentioned being keen on. I’m just curious as I couldn’t come up with a potential solution on my own just yet.
Let me also add that you guys are doing a heck of a job. It’s tough being the one actually innovating yet seeing all the attention being heaped on others with inferior products (some of this is partly because the others are better at telling their stories, partly because your technology is so groundbreaking that people either don’t believe it’ll work or believe it’s a threat to their existing operation). One day it’ll be clearer to more people the tremendous job all of you have done.
11 Likes
Hey @Bogard, good to see you around!
Nothing set in stone, but my initial thoughts have so far been to use say 15 denominations of the native token; 5 to -9, where these represent the exponent of the base 10.
So, that means 100k, 10k, 1k… 0.000000001.
Then you combine these in any way to get the desired transaction amount.
Obviously, this implies that a single transaction could often consist of more than one DBC. Still a lot to figure out here.
7 Likes
I would personally argue that the trust in the banking system, especially after the closing of the gold window in the 1970s, is based upon ignorance.
When I explain to people its basic underpinnings such as fiat currency, fractional reserve lending, and rehypothecation, that trust evaporates faster than the value destroyed by said techniques.
8 Likes
That’s something I’m curious about. A regular complaint I hear about Bitcoin is that it requires an active internet & internet connection to transact. Paper wallets and personal trust aside, that’s somewhat true as I understand it.
With DBC however, being a bearer asset, DBC transactions should be able to take place offline I believe. Please correct me if I’m mistaken @oetyng.
3 Likes
Ignorance based on 50 years of relative stability could be seen as wisdom though. Despite many predictions of its imminent demise the banking system has proved to be remarkably resilient. Not saying you’re wrong, or that things can’t very change fast, but the status quo will need a big shock to shift it.
You can hand over the DBC offline, which is basically the same as transacting the value.
However, the recipient has to reissue the DBC to be completely sure of ownership, which would require a connection. The sender could keep a copy and race to reissue before you have a chance to do it.
If there is any doubt in the honesty of the sender, you’d have to clear the payment online (reissue the DBC) before accepting irreversible consequences.
An alternative, I think, is that the sender has already reissued them in the name of the recipient, and hands over such DBCs offline.
9 Likes
Thanks for sharing @oetyng. I hope all is well!
I think your solution makes sense. The multiple DBCs in a single transaction is what I was concerned along with storing multiple packets client side but it’s likely not much of an issue if a wallet is implemented well to handle to handle these quirks.
4 Likes
Will SAFEcoin and its associated transaction mechanisms be designed generically enough to add public API to the network or will it be internal API only?
With primitive data and entity operations networked, anything can be synthesized. However if SAFE’s infrastructure for its utility token is engineered well, surely it would be beneficial to crypto/defi projects to be able to reuse the infrastructure. Think of it like colored coins for Bitcoin, or OMNI. You start with Bitcoin, SAFEcoin here, and can extend it for your project.
Taking the analogy into SAFE’s roadmap, it would be like the smart contract counterpart to the processing capability that is likely to eventually exist.
3 Likes
It’s only better, not equal. So DBC is kinda like saying the network has no idea of balances. They are all data and client hold them. This is the big difference really. The client has a balance, only he knows. He send a DBC re-siie to the network.
That reissue says basically take this amount split it between me and one other. You don’t know the other but he will prove himself when ready. The other then spends his DBC and the network records that, but does not know where it came from.
8 Likes
Spot one and direct to the point. It’s not a huge step, but a very interesting and possibly small step.