Naming

[elibensasson]

I suggest renaming some of the basic entities in protocol, to more accurately reflect what they really are: owner - the tuple (a_{sk}) and all other keys derived from it title - currently called "coin", defined as a pair (a, v) where a is an owner key, v a value. It means "a has a title to v units of zcash" title destructor (or simply destructor) - currently called "serial number", is what destroys a previous title as part transaction title destuctor seed (or destructor seed) - currently denoted "rho", the preimage of a destructor (s.n.) title commitment - currently called "coin commitment", is the blinded version of (title,destructor seed). It has a blinding key/nonce, which should be called the (title) commitment blinder title transfer transaction - or, simply, transaction, is the basic operation that destroys one or more titles and creates new titles (to the same amount as that destroyed)

I'll pause here to test the water. It's very different from the zerocash paper (and bitcoin nomenclature) but I think these names better describe what's going on (here and in other crypto-currencies)

[elibensasson]

Maybe deed is more accurate than title?

[zookozcash]

I strongly approve of improving some of these names right now! Here's a related discussion: https://github.com/zcash/zcash/issues/539

Eli, how do you feel about "note" instead of "title" (currently "coin")? (https://github.com/zcash/zcash/issues/539#issuecomment-175245054)

I've been trying to come up with a better name than "serial number", since "serial number" implies sequential assignment, which is of course completely incompatible with privacy.

Here's a metaphor that might be useful to people trying to understand the protocol:

Imagine a paper note with two tear-off flaps. On the first flap there is a random number (this is what is currently called the "commitment") which is also written on the main part of the note itself. On the second flap there is a different, unrelated random number.

To receive money you take this note, tear off the first flap ("commitment"), and stick it to a bulletin board showing all such commitments. Later when you consume/spend the note, you tear off the second flap ("destructor/serial") and stick it to a bulletin board showing all such destructors, and you prove in zero knowledge that the remaining, flapless, note that you're holding has a commitment written on it which is one of the commitments on the bulletin board of all commitments.

[This is only a metaphor. It is not an accurate rendition of the cryptographical protocol.]

Are there some useful names suggested by this metaphor? Coupons? Tickets? Tear-offs?

http://www.thesaurus.com/browse/ticket

[zookozcash]

I think that naming is very important in the long-term, but we can't spend too much time on it right now. In order to make sure we don't spend too much time, I'm going to solicit input and ideas from various others about this, and then I'm going to unilaterally decide what the names will be and we'll move on.

[elibensasson]

I think note is too general. Title (or deed, which I learned about from google/wikipedia) seems to precisely capture what's going on, which is, roughly, this: I have ownership of a quantity of zcash. This is defined by a pair (a,v) where a is my ownership identifier and v is the amount I own. It's a bit like owning a car, or a house, and I think the common term for the legal document that attests to this is title/deed.

Now, the "serial number" serves one purpose, which is to prevent me from transferring ownership of the same item to 2 different owners. It does so by effectively destroying the title once the first transfer-of-title is completed. So I think it's best called a title/deed-destructor. Etc.

To help people understand the protocol, I think title (as in "car title") works better, with this metaphor:

Today, to tranfer ownership of your car you go to a Trusted Party (the Vehicle Restration dept) and ask them to change their records. They may or may not tear your title, or stamp INVALID on it. But in zcash/bitcoin there is no Trusted Party so we have to figure out a new way to do it in a distributed manner. What we do is require each title to include a trapdoor, called a destructor, that is used once to destroy the (old) title when ownership is passed on to a new owner. This is not just a metaphor, but a pretty accurate rendition of the cryptographic protocol!

On 17/03/16 16:34, zookozcash wrote:

I strongly approve of improving some of these names right now! Here's a related discussion: zcash/zcash#539 https://github.com/zcash/zcash/issues/539

Eli, how do you feel about "note" instead of "title" (currently "coin")? (zcash/zcash#539 (comment) https://github.com/zcash/zcash/issues/539#issuecomment-175245054)

I've been trying to come up with a better name than "serial number", since "serial number" implies sequential assignment, which is of course completely incompatible with privacy.

Here's a metaphor that might be useful to people trying to understand the protocol:

Imagine a paper note with two tear-off flaps. On the first flap there is a random number (this is what is currently called the "commitment") which is also written on the main part of the note itself. On the second flap there is a different, unrelated random number.

To receive money you take this note, tear off the first flap ("commitment"), and stick it to a bulletin board showing all such commitments. Later when you consume/spend the note, you tear off the second flap ("destructor/serial") and stick it to a bulletin board showing all such destructors, and you prove in zero knowledge that the remaining, flapless, note that you're holding has a commitment written on it which is /one/ of the commitments on the bulletin board of all commitments.

[/This is only a metaphor. It is not an accurate rendition of the cryptographical protocol/]

Are there some useful names suggested by this metaphor? Coupons? Tickets? Tear-offs?

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/zcash/zips/issues/26#issuecomment-197905276

[zookozcash]

Dear Eli: what do you think of:

• "commitment" → "title ID"
• "serial number" → "spent title ID"

?

(Or possibly "note" or "deed" instead of "title".)

[elibensasson]

But the commitment is really a cryptographic commitment to a title, i.e., something that hides it immutably. I don't think ID captures this. Maybe "lock" or "vault" would be better? "spent title ID" has the same issue, we don't really need an ID, but a destructor/annihilator/invalidator of that title, i.e., something that makes it un-usable henceforth. And "spending" again puts us back in "coin" world where I spend a coin by handing it over to you. But in zcash I create a new title for you by destroying my old one.

BTW, I don't think we're just mincing words: viewing it this way makes it so much more appealing to all those systems dealing with ownership (land, cars, stocks, etc.) and helps clarify why in decentralized payment systems we need things like destructors

[daira]

I dislike "owner" because it encourages the misconception that address keys are associated 1:1 with people.

I propose:

• "address keys" (the set of cryptovalues associated with an address)
• coin -> "title"
• coin commitment -> "title commitment"
• spent serial number -> "title coin ash" (as in the residue after burning)
• Pour -> "private transfer" (see below)

I don't think that we need names (and I definitely don't think we need to bikeshed about names) for the lower-level cryptovalues such as ρ, φ, r, etc., since their mathematical identifiers are sufficient when drilling down to that level of detail.

[daira]

Alternatively, how about Pour -> "Xfer operation", where the X is mnemonic for taking two titles coins in and producing two titles coins out.

I seriously want to discourage thinking of Pours/Xfers as a user-level operation for private payments — as opposed to a low-level operation, one or more of which may be used to implement a private payment. Therefore it may be beneficial to use something that is obviously a term of art specific to this protocol, and preferably a slightly ugly one so that people won't be tempted to use it more generally (although not as ugly as "Pour" :-) ).

[daira]

It's worth noting that "serial number" != "spent serial number"; the serial number exists before it is spent.

[daira]

Also note that knowledge of what is currently called a "coin" (i.e. a tuple (a_pk, v, ρ, r)), is not by itself a title or deed to the amount of v zatoshi. The recipient who is presumed to also know a_sk gains title to v zatoshi. In other words, a coin is not a title; it conveys title to the recipient.

[daira]

A coin is more precisely like a missive in Scots conveyancing law.

[ebfull]

Another point, perhaps relevant to the spec: are we calling the smallest unit a zatoshi? Zooko and I had been thinking about names for this unit but I don't remember us arriving to a conclusion.

[daira]

I pushed https://github.com/zcash/zips/blob/zips26.renaming.0/protocol/protocol.pdf using the following terminology:

• coin -> note
• coin commitment -> note commitment
• spent serial number -> remnant
• Pour -> Xfer operation
• Pour description -> Xfer description

This seems to read quite well; please look over it and see what you think.

(I haven't changed the macro names in the LaTeX source; I'll do that after we reach consensus on the terminology.)

[ebfull]

At first glance I didn't like remnant, but I've warmed up to it.

I have no strong opinion on Xfer.

[elibensasson]

Coin vs note vs title/deed: I don't see how the zcash entity (address,value), currently called a coin, corresponds to a note, under any financial meaning of the term (at least based on wikipedia). It really is a binding of an entity that can own things, and an object that can be owned - v units of zcash. I prefer coin>note because even though both do not accurately describe what's going on, the previous one is already used in Bitcoin. Owner vs address key - owner is not necessarily a person, even in today's world. We are all familiar with companies, nations, etc. owning things. Having said that, how about calling it "owner(ship) address key, and "address key" for short? s.n. vs. remnant vs. ash vs. destructor Remnant and ash seem to suggest we would be fine with them being discarded/removed/blown into thin air. But its crucial that this object be kept on record for ever (or a very long time) and also it's role, in destroying a previous title, is unclear from ash/remnant. There may be a better name than destructor but I think it should convey the role of this object - to nullify a previous title/deed/note/coin. Xfer vs pour vs title/deed transfer I don't think we should actively over-obfuscate what we're doing, it's complicated enough as it is. And the X thing, while really cool, would seem to indicate that 2-2 mapping is really crucial whereas it's not.

[elibensasson]

Naming should ultimately be ZECCs decision and ZECC does have other things to attend to, so I won't be pushing this more. However, let me try one last time:

A brief comparison of currency, bitcoin and zerocash (seed of a potential blogpost?)

1) Coins and banknotes are physical objects, used as money (store of value, medium of exchange, etc.). Ownership of these forms of money is transferred physically by handing the coin/banknote from the possession of one owner to another. Notice the physical object itself does not change form during transfer of ownership.

2) Electronic bookkeeping (as used by banks) deals with ownership and transfer of it differently. The bank is a Trusted Central Party that maintains with integrity a table that specifies for each owner the amount of currency that owner holds. Transfer of money is done when owner A (identifies himself to the bank and) instructs the bank to transfer v units to owner B. In that case the back deducts the amount v from A's entry in the table, and adds the amount v to B's entry. Notice that in this case the money being transferred has no special distinction as coin or banknote. [If B is an owner registered with a different bank the two banks will engage in a different protocol by which A's bank deducts v units from A's account (and the bank's total surplus) and bank B simultaneously increases B's account (and that bank's surplus) by v units.]

---

Intermezzo:

Wikipedia: A deed (anciently an evidence) is any legal instrument in writing which passes, affirms or confirms an interest, right, or property and that is signed, attested, delivered, and in some jurisdictions sealed. It is commonly associated with transferring title to property.

Wikipedia: A banknote is a negotiable promissory note issued by a bank and payable to the bearer on demand. The amount payable is stated on the face of the note. Banknotes are considered legal tender, and, along with coins, make up the bearer forms of all modern money. Also known as a "bill" or a note.

Notice that banknotes are typically transferred unchanged along many transactions but titles/deeds are typically voided/destroyed with each transfer. Compare what happens to banknotes vs. car title when you buy/sell a car.

---

3) In Bitcoin there is no Trusted Central Party and also no physical entity of coin/note. Rather, Bitcoin transactions report transfer of ownership of a quantity v of Bitcoins from owner (address) A to owner (address) B. Such a transaction is best described as a pair of declarations : (i) "A no longer owns v units" and (ii) "B henceforth owns v units". Thus, the 1st half is best described as the digital analog of tearing/voiding an ownership title/deed (ownership of v units of BTC) and the 2nd half is the digital analog of creating/printing a new ownership title/deed. Since all details of this transaction are broadcast to all nodes, it is easy to verify validity (details omitted).

4) Zcash emulates Bitcoin but the big difference is that both parts of the transaction are encrypted. Since there is no Trusted Central Party and transaction details are encrypted, how are transactions validated? The solution uses a new object called a title/deed voider/destructor/annihilator/anuller/? that is an integral part of a zcash title/deed. Each Zcash transaction declares (i) by broadcasting the voider/destructor/annihilator and then (ii) creating a new title that must include its own voider/destructor (seed). zk-SNARKs are used to bind the destructor to its seed and also validate all other parts of the transaction (most notably, that v_old=v_new).

[daira]

A deed isn't necessarily evidence of transfer of title; it is basically any legal document making an assertion. (For example, consider Change of Name Deeds.) However it does fit fairly well otherwise; I'll create a version of the spec using it so that we can compare with "note".

"Title" definitely doesn't fit as a renaming of "coin"; remember that we are talking specifically about the tuple (a_pk, v, ρ, r), which is evidence that the holder of a_sk holds title to v units of the currency provided that PRF^sn_ask(ρ) does not appear in a spent set. It is not the title itself.

Ownership of property by organisations doesn't contradict the argument against using "owner" for an address/key tuple, because organisations are similarly coarse-grained. Also we don't even need a short name for that; it's not a concept that is used frequently enough that saying something longer like "keys for an address" would be a big deal.

[daira]

An argument for not using "deed" is that transfer of property (conveyancing) is typically a very heavyweight process with much that can go wrong — and rarely a private or anonymous process. We want Zcash to be thought of as analogous to cash, even if it does not technically work in the same way.

[Edit: I also ran the terminology we're discussing past my partner Samantha, and she said that "deed" was horrible.]

[daira]

If "remnant" doesn't specifically capture the fact that it must be remembered, then perhaps "memento". (Note that the latter also has an earlier meaning as something that serves as a warning.)

[Edit: oh, but that is too close/confusable with "memo", which we also use.]

[daira]

I could live with serial number -> "nullifier". That works for the general pattern of publishing a commitment and then a nullifier that Zerocash/Zcash uses.

(I didn't like "serial number" because a nullifier is not analogous to and does not have the same purposes as a serial number on a banknote. In particular, the creator of a Zcash note can't mark it and then see where it is spent, even in principle, without having the corresponding a_sk.)

[elibensasson]

Took me some googling to find what memento means http://www.dictionary.com/browse/memento (I saw the film, which comes from "memento mori" - remember death). This piece isn't a warning, just something that voids/anulls a note/deed.

On 20/03/16 15:25, Daira Hopwood wrote:

If "remnant" doesn't specifically capture the fact that it must be remembered, then perhaps "memento". (Note that the latter also has an earlier meaning as something that serves as a warning.)

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/zcash/zips/issues/26#issuecomment-198930142

[elibensasson]

works for me:-)

On 20/03/16 15:50, Daira Hopwood wrote:

I could live with serial number -> "nullifier". That works for the general pattern of publishing a commitment and then a nullifier that Zerocash/Zcash uses.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/zcash/zips/issues/26#issuecomment-198932249

[elibensasson]

(1) The same argument can be flipped to position zcash (and bitcoin) positively: conveyancing is typically heavyweight, much can go wrong. Not so in bitcoin/zcash, where its automatic and nearly instantaneous. That's a (or the) main reason for the financial industry to want "blockchain technology". (2) I think it's more important to pick terms that are accurate, and deed is more accurate than coin/note which changes hands but remains unchanged in financial transactions.

On 20/03/16 14:14, Daira Hopwood wrote:

An argument for not using "deed" is that transfer of property (conveyancing) is typically a very heavyweight process with much that can go wrong. We want Zcash to be thought of as analogous to cash, even if it does not technically work in the same way.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/zcash/zips/issues/26#issuecomment-198914736

[elibensasson]

Good point, i wonder if there's a special term for a "property deed", i.e., a deed that asserts ownership of something. I think (address) key is fine because it does describe the function of that object: it's something private (like a key) that is required and sufficient to get something done (a transaction).

On 20/03/16 13:23, Daira Hopwood wrote:

A deed isn't necessarily evidence of transfer of title; it is basically any legal document making an assertion. (For example, consider Change of Name Deeds.) However it does fit fairly well otherwise; I'll create a version of the spec using it so that we can compare with "note".

"Title" definitely doesn't fit as a renaming of "coin"; remember that we are talking specifically about the tuple (a_pk , v, ρ, r), which is evidence that the holder of a_sk holds title to v units of the currency provided that PRF^sn _a_sk (ρ) does not appear in a spent set. It is not the title itself.

Ownership of property by organisations doesn't contradict the argument against using "owner" for an address/key tuple, because organisations are similarly coarse-grained. Also we don't even need a short name for that; it's not a concept that is used frequently enough that saying something longer like "keys associated with an address" would be a big deal.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/zcash/zips/issues/26#issuecomment-198906867

[daira]

With remnant -> nullifier: https://github.com/zcash/zips/blob/zips26.renaming.1/protocol/protocol.pdf (this is the version I prefer). Also with note -> deed: https://github.com/zcash/zips/blob/zips26.renaming.2/protocol/protocol.pdf

[daira]

@elibensasson wrote:

[...] the X thing, while really cool, would seem to indicate that 2-2 mapping is really crucial whereas it's not.

That is true. The other option I was considering was "join-split operation".

[daira]

@elibensasson wrote:

Good point, i wonder if there's a special term for a "property deed", i.e., a deed that asserts ownership of something.

That's a "title deed".

Another thought is that we may want to avoid terms that have a definite legal meaning, because their application to Zcash would be only an analogy, and we we want to avoid them being taken too literally — The map is not the territory.

By the way I really appreciate the thought you've put into this issue @elibensasson. Over to @zookozcash to make the decision.

[zookozcash]

Yes, good work thinking these out, you two! Will do.

[amiller]

I'm just chiming in to say I also appreciate the thought that's gone into this. A good choice of names can help avoid confusion among users, prevent derailed discussions, etc., so the deliberation here is worthwhile! This discussion in this thread has been great.

The only extra suggestion I have is that "tombstone" might be a good name for "nullifier". It is sometimes used this way in programming, where you want to conceptually delete a record but without actually removing any data from the underlying log https://en.wikipedia.org/wiki/Tombstone_(data_store) On the other hand, it's a bit macabre, and is really only a useful reference for computer scientists. Nullifier is more self-contained.

[daira]

"Tombstone" normally means a record that you get if you look up an address that has been revoked/deleted, which is not what a nullifier is — the nullifier is published when the note is spent, but is not something that you look up in a record associated with the note.

[zookozcash]

I've been thinking and thinking about this. Thank you all for your contributions!

One thing is that even though I think Eli is right about the precise meaning of words like "banknote" and "deed" (see this excellent comment: https://github.com/zcash/zips/issues/26#issuecomment-198783224), I actually think it might be a problem to use terms that sound too much like legal terms. This could cause people to think that the executing the protocol has legal consequences, or that the protocol comes with certain features or bugs that mirror the real-world legal metaphor's features and bugs. (Regulators and legislators, among other people, tend to be prone to such misunderstandings.)

I do agree with Eli's emphasis that the package of information (formerly called “coin”) in the Zcash protocol is one-use-only, not transferrable from A to B to C like a banknote is. By the way, I totally agree that Eli should write a blog post based on https://github.com/zcash/zips/issues/26#issuecomment-198783224.

However, I think "note" might be okay for this, even though, as Eli said, it is a very general word. Being a general word helps signal people that they shouldn't make detailed assumptions about it based on its name. It doesn't mean "banknote" in this protocol, it just means "a short message". In this case the short message is "B henceforth owns v units".

So how about:

• “coin” → note
• “serial number” → nullifier
• “Pour” → join-split
• “commitment”, “payment address”, and “spending key” — unchanged

[ebfull]

Personally, I don't mind serial. I think the connotation that it's a unique identifier for a banknote is more common than the connotation that it's an index into a sequence. I think we could tolerate people saying "wait are Zcash serials sequenced?" and answering "no" versus people asking "what is a nullifier" and having to explain it in terms of a serial. (There may be other downsides to 'serial' that I missed, by the way.)

But, overall I don't mind if we choose nullifier and the rest of the terminology sounds fine. :+1: from me.

[ebfull]

Actually, I would prefer a smaller word to replace "pour" than "join-split" for development purposes. Xfer is pretty nice for this. But I don't care too much either way.

[daira]

We wouldn't be explaining nullifiers in terms of serial numbers; we'd be explaining them as a thing that nullifies a particular note and that is published when the note is spent.

Edit: I think that the analogy with a "unique identifier for a banknote" is more misleading than helpful, because a banknote serial number isn't relevant or used when it is spent.

The serial number terminology would only arise as 'oh, and a "nullifier" is what the Zerocash paper called a "serial number"' –for the benefit of the few people who already understand Zerocash— which shouldn't be an issue for very long.

[defuse]

I think changing the terminology right now would add significant friction to our engineering team. Would it be reasonable to keep using Pour, coin, etc until the 1.0 launch, after which we publish a document with the new terminology so that everyone in the Zcash community can speak the same language?

Aside from that, a lot of the terminology being proposed here is more confusing to me. For example, I've never owned a car so I don't have any intuition for what a title is (nor deed, note, nullifier, etc.). It's easier for me to imagine a randomly-assigned serial number with additional security properties since it's similar to the terminology used in pre-bitcoin digital cash schemes.

[daira]

The spec already uses "note" and "nullifier" (on zips25.change-kdf.0 which is the latest branch). I had anticipated that we would be switching the terminology now, and I think it would be a bad idea to switch it later.

We decided against "title" and "deed", so not having intuition about those isn't an issue. I've already stated the arguments against "serial number".

[zookozcash]

Okay, I'm satisfied with https://github.com/zcash/zips/issues/26#issuecomment-202141024. It isn't the best possible naming scheme, but it is good enough and we're ready to move on. Taylor, your observation in https://github.com/zcash/zips/issues/26#issuecomment-202526777 that changing names induces friction in engineering is correct. I've decided to do it now rather than later because I think the friction that changing it (or leaving it unchanged) later is even worse. :-)

[ebfull]

I think @defuse is correct to point out that having to keep track of changing the names for all of this will be a bit distracting right now. Let's use the new terminology wherever we can, and commit to modifying the code to reflect the new terminology sometime between now and 1.0.

[daira]

The current spec (on the master branch of zcash/zips) now uses the terminology from https://github.com/zcash/zips/issues/26#issuecomment-202141024 . I'm not sure about how JoinSplit looks, but it'll probably grow on me (I think it's better than Pour).