But one helluva opportunity for Safe. I’m glad you have such a passion to get this right @danda and that you have a deep knowledge on the subject.
Safe Network is an amazing prospect as is but this money element is so important for it to be everything it aims to be.
Private, ownerless, sound money backed by the worlds data could be just what humanity needs to free itself.
Thanks for the clear and easy explanation. 
Great to hear. Truly a marathon not a spirit. In awe of the persistence of the team!
@qi_ma I was wondering when I did some modelling some issues.
One idea was to use the upper bits and flip some bits (use XOR on the bits) causing an address to be a long XOR distance from the original. Thus if you flip the top bit then that gives a determinable address in what should be a different section if there is more than 2 sections.
So this can be extended to more bits if needed and the section storing only needs to know if this is an alt xor address and what the current flip bits are.
Thus the section tries to store the chunk and if it cannot then using the “flip bits” it chooses the next in sequence (unflips with current and flips with next), sending it off to the section to store. Once the limit is reached then the chunk is considered not storable due to no space. [EDIT: obviously the bit sequence can incorporate the unflip and flip as one bit pattern EG if pattern is 1 and next is 01, then xor with 11]
The sequence of “flip bits” would most likely be
1, 01, 11, 001, 011, 101, 111, 0001, 0011, 0101, 0111, 1001, 1011, 1101, 1111 for upto 4 bits of flipping.
Obviously there is some limit to how far you go due to time and/or network effort.
The more bits used increases the chance of clash of hash from nigh on impossible to just a little less than nigh on impossible.
Benefits, it is recursive across the network, does not need state to be kept beyond what is already kept to store a chunk.
The denominations should actually have a pretty limited effect on usability, it’s more about unlinkability, and efficiency for the nodes. And as usual @danda and @mav are all over that.
All the change-making, stacking of DBCs into transactions, merging etc can be seamlessly handled by the client. Even withdrawing a specific amount as cash should be doable in a one-page, single value, kinda way.
So sending a payment will still be: type amount; select payee; boom. Writing out a cheque will still be type amount; select payee; print, and depositing it will still just be Scan code, or click link, and it’s done.
Where this data will be stored (RAM, disk) and for how long?
Awesome!!! 
Wondering if there will be messaging capability (through SN) in Safe wallet - or an automated handoff to a message app? (if set to do so), for things like invoicing or otherwise just communicating with payers and payees.
Crypto wallets are lacking in functionality for communicating with those whom you are trading and as crypto allows us to be our own bank, this seems really important plus, given we have a network for private communications as part of the package, seems like this would be a great addition to a Safe wallet.
Guessing that’s all above and beyond beta, but curious if you’ve had any thoughts about these things yet.
Oh yeah, we know this will be vital. How the mechanics of it work is still TBC, whether it is more loosely coupled through a parallel apps and data, as you suggest, or more tightly integrated with DBCs themselves.
I’d say the former is much more probable, as there are likely security, likability and performance issues with stuffing more and more in the DBCs.
But honestly, we are tip of the iceberg here when it comes to what this system will be able to do. It’s very exciting. Honestly I feel when it starts to become apparent down the line, I think we’ll look back and chuckle at why we spent so much time fretting about exchange listings and the like.
When I first read the DBC documentation (https://opaque.link/post/digitalmoneydbc/), I thought that DBCs in SN consists of ‘User1 → User2 → Mints (reissue)’. In this case, User1 to User2 uses a secure transfer. I think this is no-ownership DBCs with more anonymity than ‘User1 → mints → User2’ (DBCs with ownership). Is it correct? @JimCollinson .
Honestly, there are others here that could more accurately answer this question when it comes to the detail of mechanics and security etc.
But in basic terms, what is happening when you make a payment is you are taking a DBC that you own, and you are saying to the mint “please use this to create a fresh DBC, but with the my friend as the owner, not me”.
Now there is this fresh, reissued DBC which belongs to your friend, and can only be spent by them. You could literally pass this DBC to them for them to hold, or send it as an email on the clearnet, or for the sake of speed and convenience, we can put it on the Network in a way it can be immediately found by your friend: dropped right in their “Safe”. So they see their balance go up the next time they open their app of choice.
And of course, this transaction can’t be seen be deduced by anyone else, it’s effectively private thanks to the mechanisms described in the OP… each transaction having a one-time key, using fixed denominations etc. etc.
Ownerless DBCs are another thing. That’d be where you get a mint to reissue a DBC but without any owner at all, so anyone can claim it as theirs; like a bank note. Obviously it’s not quite the same, as they are ease to duplicate unlike a banknote, but they’d still be useful and usable in cashlike ways.
For example, I am going shopping, and I know I’ll not have my phone with me at the time, and I’m also not sure who I’ll be paying either. So I create an ownerless DBC, and print it out.
I find a shop with goods I like, and hand over my DBC to the cashier. They are online, and can scan the QR code on the DBC, check that it hasn’t been spent, and deposit it, i.e. they get the mint to re-issue it with the shop as the owner.
If I was due change, the mint could issue a new DBC (or several) which could be ownerless and just printed on my receipt, or if I wanted, I could give the cashier my SafeID, or an network address/key, to send the change too, and I’d see it in my Safe the next time I got connected and opened my app.
This is what you’ll have heard referred to as a ‘half-offline’ transaction.
Does that make sense? I may have fuzzed some of the detail ofc, I’ll let the devs chip in some if I have.
Thanks for elaborating. I’m hugely in favor of fixed denominations but what I mean more specifically is the balance between how many fixed denominations are needed to still enable micro payments but not be confusing or lose the optimal unlinkability trait.
If danda and mav are on it though, I can rest easy 
Excited to see any flows for the multi-sig sign in and account recovery too. There was something about hardware wallets too? So potentially could save credentials on a ledger? Or just DBC or both?
Regarding the wrapping of other tokens into a DBC on Safe … Would denominations be programmable - i.e. is this something that can be customized and encoded into the DBC on creation? Or maybe no denominations possible at all for wrapped alt-tokens? Assuming wrapping other tokens is all still in the cards. Guessing there would be an API for all of that down the track … or am I just dreamin’ here?
Working though it all at the moment, using a combination of password, mnemonic, device keys, should give a pretty flexible solution that can be tailored to your own particular thread model, and also be resistant to losing credentials too, which is a major consideration.
I had hoped we could add things like ledger, yubikeys and other dedicated hardware from the off, but sadly there appears to be no current hardware solution supporting BLS right now. Although I expect that to change, and it’d be ready to drop into the flow once that happens.
On top of that we are looking at multi-party credential recovery too as it’s very closely related.
I’m confused. Do we have divisibility or not?
Does it matter if we can agree the tiniest base unit and have denominations of 1, 2, 5, 10, 20, 50, 100 … 200k, 500k, 1M --would say 30 total denominations be enough?
This is going to require an informed guess as to the smallest unit that can make micro-payments possible and also some estimate of the top denomination so that serious transactions can be made with reasonable convenience and lack of traceability.
I’m talking about the SAFE equiv of the 500 Euro note or $1000 bill. Scottish equivalent would be the red Clydesdale £100 note.
O/T The English have their green £50 note but so many of these are fake, I never accept them (May change my mind if someone was to actually offer me one though 
)
Should we be pestering Trezor , Nano etc to make this happen?
At some point, but I think a little down the track when things are up and running.
BLS solutions may well appear via the etherium route anyway, or we might find other avenues for hardware support.
It looks logical for me to tie 1 denomination to 1 bit.
It does not matter how much divisible number will be.
For example 32.32 number will have 64 denominations.
Actually a single byte holding the denomination allows up to 256, or if you want expandability in later versions the upper bit denotes denomination version. So one byte allows 128 denominations and if bit 7 is set then 2 bytes allow over 32K
So a 32 bit word could be 2 16 bit values. 1st value is the denomination and the 2nd value is the count.
Even going to 2 x 32 bit words you can have up to 4 billion of up to 4 billion denominations. Why? Allows for other tokens. Lets say we have 64 denominations for any token then 67 million different tokens could be accounted for. Once again a new version could expand this by using the upper bit to denote 64 bits for the denomination.
The transaction is then a set of value pairs for each denomination used.
I think it’s essential to have fractions 0.0001 SN etc. I don’t want 1 SN to be worth a penny, I want to be able to tip 0.0002 and eventually it being worth 5$
Why you need count?
You either send 2^N tokens or not (0 or 1).
If you send this denomination, count is 1.
If not, then 0.