The only concern was having the word & concept of cash in the design of the code. Any review by regulators will see that and will want to examine the situation more. So tokens are moved in a process that involves something, anything call a cash… gives them the impression that the purpose is for cash movement/usage/replacement/??? rather than tokens.
I wonder if there is terms from the bartering system that removes the cash concept and is more along the lines of value. Maybe “valueNote” or TokenNote" or “TokenReceipt” or ???
And then I wonder if I am making a storm in a tea cup in my own thinking
Yes that has always been my understanding.
Then “valueNote” seems pretty obvious (maybe TokenNote)
Things can always be changed if we have good reason to. CashNote is better than anything else we came up with and removes a lot of potential confusion that came with DBC. Definitely keep brainstorming if there’s better ideas out there they will be welcomed with open arms.
As @JimCollinson mentioned above, this doesn’t impact SNT, as it’s a container of info about your SNT, not SNT itself. It’s the technology with which SNT is moved around.
We considered terms like these but discounted them as to avoid confusion, linguistic and code tangles.
Avoiding token as part of the term because it could contain/represent any number of tokens, and other information, (and potentally things that may not be tokens either) and to prevent clashes with other token related parts of the transaction flow.
Safe also doesn’t do any work in this term, other than potentially cause confusion. All of these elements are within the Safe Network code, so that’s a given that it’s SN related. It doesn’t really help indicate what it’s for or its properties… and may be confused with other aspects of a user’s Safe or the Network which don’t relate to financial transactions.
If we just remove it, then we are left with just Note which is too broad.
I’ve got a bit more time for ValueNote but it doesn’t only relate to value. And i’d like to check that it wasn’t going to clash with other aspects of the code.
Transfer: We already have this term in the code, it’s an encrypted CashRedeem that’s ready to be sent to a recipient so they can receive the money. So this may get confusing. The thing we are talking about it is the thing that’s held after a transaction (which could have been a payment or a transfer) is complete.
Authority: Again, could get confusing, and we did consider it. It doesn’t give you authority by itself, it is related to it. Too narrow I think.
Details: Its more than just a receipt, or additional information. It’s not something you want to discard or ignore. Like money comping out of an ATM… I can throw away the little transaction details print out, but I wouldn’t throw away the money.
Slip: CashSlip… maybe? But again feels a bit more like a receipt or details… What do you think it gains us over Note?
Bit more context if it helps, a summary from @Anselme:
SNT: Safe Network Tokens. The unit of our currency.
Nano: 10^-9 SNT
CashNote: (formerly DBC), spendable unique key along with spend related information, containing n nanos. This CashNote contains unique key related information, leaking it damages privacy but it cannot be spent by an attacker since it doesn’t contain your private key.
Spend/SignedSpend: Network representation of a spent CashNote, it cannot be linked back to your MainKey. It makes the system auditable and transactions verifiable
Transaction: (formerly DbcTransaction), Network operation that creates new CashNote while spending CashNote of the same total value, transaction information is findable both in CashNotes and in the Spends on the Network.
CashNoteRedemption: (formerly UTXO) minimal information from which the recipient of a Transaction can redeem their new spendable CashNote
Transfer: encrypted NoteRedemptions ready to be sent to a transaction recipient so they can receive money.
As for keys:
MainSecretKey: (formerly MainKey) the private main key (secret)
DerivedSecretKey: (formerly DerivedKey) a derived key from the main key (IS UNIQUE but secret)
MainPubkey: (formerly PublicAddress) the public key of the main key
UniquePubkey: (formerlydbc_id) the public key of the derived key (IS UNIQUE)
I must say that it’s very challenging Jim when we give constructive feedback to you that something looks like dog poo and then you go on to try to sell us on it by saying how great it tastes and that it is the best poo you could find on short notice.
Looking at those both CashNote and Transfer could be improved together.
Maybe Cash was used in conjunction with Note to limit confusion of Note with a jotting or musical thing. I’m not sure even with Cash people would realise what it is. Bank Draft seems a close metaphor but similarly Draft won’t be more easily understood than Note I think.
So instead of CashNote and Transfer how about something like:
CashNote → Transfer (or TransferCertificate, or Details, Slip, Note etc?
Transfer → RememptionSlip (or Code or…?)
Or perhaps CashNote becomes Transfer and Transfer becomes EncryptedTransferRedemption (ETR), and CashNoteRedemption becomes TransferRedemption.
So I arrive at, for example:
Transfer: (formerly DBC), spendable unique key along with spend related information, containing n nanos. A Transfer contains unique key related information, leaking it damages privacy but it cannot be spent by an attacker since it doesn’t contain your private key.
TransferRedemption: (formerly UTXO) minimal information from which the recipient of a Transaction can redeem their new spendable Transfer
EncryptedTransferRedemption (ETR): encrypted TransferRedemption(s) ready to be sent to a transaction recipient so they can receive money.
As it is a container the first one, Transfer might be clearer as TransferXxx where Xxx is Container, Details or Slip etc.
I think Transfer is clear enough though, and easier to understand than CashNote. It conveys importance, the fact it is a transfer of something (not necessarily SNT), and fits a UX flow of receiving or sending some thing, i.e. transfers whereas a CashNote (or other Note) doesn’t do that.
I think CashNote is not clear and in fact misleading as it isn’t Cash and isn’t necessarily tokens. It is a transfer of some thing, initially SNT.
It’s not a transfer of things though, it is something that has been transfered and is not availble for me, as the owner, to spend.
It’s like (in meat space) if you opened up your wallet and saw bunch of dollar bills inside. Would you think of them as transfers? “I have a bunch of transfers in here” that would see weird to me.
Yes, these are the options we looked at too, and came to the same conclusions.
A bankers draft is the closest to it for sure. But they are rarely used these days, and like you said the confusion with the way the term draft is used in UX more commonly (e.g. draft email) might have been a recipe for more confusion.
In my opinion CashNote is the best option so far, but since it’s not perfect, I’m going to engage this brainstorming too, with both of my braincells. So, how about:
Although I do think adding “digital” can be extraneous, unless it really needs to be distinguished from a physical alternative, or has already been coined (DBC was an example of this).
Perhaps Certificate is too broad, so it could be AssetCertificate or similar.
I’m not sure if it helps to describe the containerishness (as in ‘container’, ‘holder’ etc.), but maybe.
Thanks again for the dialogue. I appreciate that a lot of thought has been put into this but exposing that thinking is helpful, not just to me but also when others as me what a CashNote (or whatever) is, I’ll be able to have a better stab at it.
I didn’t care for PNS (reads like penis in English) aka public naming system but CashNote or ValueNote make sense and it’s only something seen in the code. Code is speech, freedom of speech etc. Is it this big of a deal folks? Let’s pick our battles.
I don’t know how visible it will be but I don’t think it will only be in code, as with the term DBC it’s an important thing and will surface in explanations, CLI docs, probably the directory structure etc. It’s also important that the code uses the best terminology of course!
