Update 26th August, 2021

Is the 10.56 SN Token or dollar cost? One thing I’m uncertain of is the decimal place if we aren’t technically doing divisibility but instead whole units/denominations like 1, 5, 10, 50, 100 etc.

I think it’s been touched on that UX could deal with decimals still? But perhaps that leaves room for errors or possible hacky things to happen.

Regardless, I think the whole units are really intuitive and being able to just type in send x amount to @SafeID will be an exceptional feature to have built right into the new internet. :smile:

1 Like

3 Likes

Is it not enough to supply the software? What does containers add? I’d say it’s not up to maidsafe to supply a container image. Others can and will do it. But I ask genuinely since I’m not too familiar with containers and maybe they offer some benefit that the simple node exe / binary doesn’t?

5 Likes

Previous talks about divisibility discussed the usefulness of 128 divisibility. You could get pretty close to that with 40 decimal based denominations, which is pretty cool.

3 Likes

Lightweight encapsulation, whiz-bang kernel features, and more complexity. I’m not entirely sold on them either compared to a good old fashioned VM. They have their uses, maybe not for safe nodes though or maybe so. Here’s a simple comparison:

My thinking, including testnets, is to make participation as easy as possible whilst opening up the possibility of ramping up loads of nodes that can be geographically dispersed.

  • I may be wrong, but I firmly believe the network will be seeded in the main from datacentre instances, by folks that know what their doing with scripting, bare metal management, containers etc, but in the long term, wil become dominated by the home machine.

Why? In the docs, it clearly states that rewards will be greatest in the first weeks post launch (maybe that changed?)

  • Those that can ramp up 100’s 1000’s of nodes, with scalable hardware, geographical reach and fat pipes, with little effort can cash in…so why not make it easy for everyone to get a piece of that early action with images and instructions for various providers, even if it’s just droplets. Of course this could be a community lead activity, but the devs do have the build process in place.

If I want to take a serious punt on this new network and say I have $1000 to spend, I could buy a machine for home or purchase a years worth of Bare Metal hosting with all bandwidth, power, maintenance included. The object here is the early rewards.

  • The barrier to the latter approach is know-how, so anything that can lower that barrier gives options. Network rewards are already skewed towards technical folks, especially if there’s no Pay the Producer.

You can just download the .apk, many also provide direct download for apk, or you can use playstore or ios appstore.

SafeNetwork could host a domain build by anyone that can act like an Appstore that gets updated with links 3rd-party developers post along with their unqiue hash to verify it’s the authentic developer app.

The apk’s people develop can easily integrate the safe api, connect to the SN and interact with it each with their own GUI, tools, etc.

1 Like

I thought with android you can only do this on a jailbroken phone?

I have saved the apk on iPAD with old music apps and re-installed, but are they maybe signed already?

It’s easier than that in Android - you do need to change a system setting to allow installation, but that’s a one-off. I don’t know about Apple.

I wouldn’t think so. I think most people will want to learn a bit and test things out, as well as see a history of successfully running apps and storing unimportant data before trusting the, let’s face it - difficult to grasp or believe claims - about long term storage and security of important data.

Backup is also a tiny thing in most people’s consciousness and it will take us time to figure out the best way to deliver on this, both the product and the idea that doing extra work is worth it, especially when so many are still happy to just let default settings on mobile apps shovel their data into Google and Apple clouds.

I think many will be using Safe apps that store newly created data direct to Safe, and that this will increase as new data generating apps arrive and bring Safe storage to the masses by just doing it (Safe mobile apps for Camera, sound recorder etc) which provide a Safe alternative to the default mobile apps.

At some point explicit backup and archiving will become a significant market but I’m not sure this will be the dominant type of adoption early on, both for the reasons stated and because I see fewer network effects than for other apps like JAMMS, chat, SafeTube etc, all of which have strong social effects and will be bigger on mobile.

Day 1 for me at least, gonna take a while to upload TB’s of data though.

1 Like

Don’t forget SAFEmail, and the big network effect, money. The tier 0 implementation will have money, SAFEmail, and basic websites, as well as file storage (likely only to be very important stuff and in parallel with other backups). This, and the ‘anything is possible, and much is being built’ will hopefully be enough to start some virtuous cycles of adoption.

8 Likes

Good point. Off the top of my head there are a couple more, I think.

Provided

  • Digital IDs/SafeIDs (recognized network wide)
  • Contacts
  • Messaging (to/from SafeIDs)
  • SN Token wallet (send/receive to/from SafeIDs)
  • Website publishing and management
  • Permanent public and private data storage and management
  • App permissions manifest and management
  • remote ‘Safe’ node management

Freebies

  • Versioned web browsing (like internet archive)
  • Anonymity (if desired)
  • No tracking
  • Built in economy for publishers/apps
  • more?

This is what I can remember from UX that has been presented.

8 Likes

Yes, and this can be done for the two possible scenarios where all tokens are in the hands of MAID holders or reserved for investors, OR sections hold the 85% initially. Many benefits to having all existing at the start. The old system where each token was a data object didn’t have the issue since each token had its own address. But the old system had real problems for division.

Phones are in most people’s hands who use any internet browsing device. Taking my kids as examples, they all used only phones when they left home, until there was some need for a laptop. They have friends who only have phones, and in their own households its one laptop but multiple phones.

So does this require a ledger of sorts with the spendbook holding transaction amounts for all time. OR is it a book with a current state, and where would this be held? Or is it something different again?

Is it possible to divide a certain denomination into smaller denomination and recombine at a later time?
Or is it set amounts of each denomination from the start.

If its set then we will at some stage end up with people not having enough lower denominations to exactly pay. Like we do time to time with normal coins.

Say I am new and receive 3 amounts (1.0, 0.1, 10) so how can I pay 1.5 amount?

[EDIT] Sorry you answered it in the post. That sounds quite a reasonable analogue to cash/coins with added benefit of not needing to go to somebody/bank to split a large bill into smaller denominations, or back again.

I would think that the wallet (or whatever) would do this splitup for you. So even easier since the normal users never have to worry about it anyhow.

By the sounds of it, there is not much difference between paying 1.125 and 1 + 0.1 + 0.02 + 0.005 and because the person themselves can split and recombine denominations then the concerns fall into having 4 amount in my example rather than 1 only. Not a major concern I would think.

7 Likes

Yes pretty much. The spendbook records at minimum a list of all DBC ids that have ever been spent. This is what prevents a DBC from being double-spent. In practice, the spendbook will likely have also the full reissue data that the mint can see, ie all inputs and outputs.

current state alone is not enough, as per above.

There’s still discussion around this. Originally we were thinking that each mint node in a section would write its own copy of the section’s spendbook locally. (Each section is responsible for only a subset of all DBC). However I believe the thinking now is that spendbook data can actually be stored on the network, eg using register CRDT. There is also a proposal where the client (not mint) can write the spendbook entry(s) before reissue, which enables an idempotent reissue api, meaning reissue() always returns the same result for a given set of parameters.

Right now the sn_dbc crate doesn’t care. It defines a Spendbook trait and a simple memory based Spendbook. The more advanced stuff will come as we advance discussions and integrate further with sn_node.

10 Likes

Thanks for filling in some blanks.

I gather from no reply to the stuff I wrote about denominations that you think its close enough to what you were getting at.

A question about DBCs and sending tokens.

What size is the data object holding the DBC. What determines its size if variable?

The reason I ask is that the NFC “tag” (disks/cards/whatever shape) can hold a certain amount of rewritable memory and easily read from most modern phones, or PCs with a NFC reader. The thought is that they could hold a DBC and the person can then give it to another and they can use that to receive tokens.

A use case is for a company to supply NFC “tag” with a certain amount of SNT as a DBC.

Maybe as a sale item in a physical store where people can buy a NFC tag loaded with a DBC. Obviously there has to be some trust with the company.

And the obvious where a friend can write a DBC to a tag and give it to them. Perhaps the tokens they use to set up their account. Or any number of other applications.

And the tags can be written with new DBC once the current DBC stored is used.

1 Like

Do you have an estimate of the number of bytes required for say the minimum DBC size? I am unsure of the size needed since one is a vector and size of amount_secrets_cipher and commitment values.

This is a bit in flux right now, as we have the original dbc implementation and the blind sig fork I’m working on now.

For the original implementation, DBCs were originally pretty small. I don’t remember exactly but perhaps a few hundred bytes. These had a blinded copy of the reissue tx (hashed inputs and outputs), a bls public key, amount u64, and mint signature.

When we added amount hiding, these became much larger. ~2kb I think. Again I don’t remember exactly and I don’t have a build handy just now. These added: encrypted amount + blinding factor (ciphertext), pedersen commitment, and a range proof. The range proof contributes the majority of the size increase. The large size (and extra cpu) was something I didn’t like about this solution.

The blind sigs prototype does away with much of this and presently contains a 32 byte nonce, a 2 byte denomination enum, a mint pubkey and mint signature. Presently bincode serializing a DBC blind-signed by a single mint node gives 180 bytes. It may add/change some fields though, as I say… in flux.

Then there is the fact that the mint sigs are created by 5-7 mint nodes combining signature shares. The final signature size increases with the number of co-signers.

I haven’t done a real size analysis yet, but that should give you a rough idea.

8 Likes

It’s the SN cost, wasn’t intended as a unit/denomination thing (I just typed a random number) just more that all the change-making, merging etc can be handled for user, without them having to worry about it. All they need to know is how much they want to send.

3 Likes

Thanks for that, 5-7 mint nodes means definitely more than 1K. I have to go back and look at NFC tags and see if there are cheap ones (or any at all) with over 1K bytes. And check there isn’t some limitation in the NFC protocol.

Will be interested to have a closer picture on sizing when the final implementation is agreed on and done.

3 Likes