Topic: Standardizing Bitcoin Terminology (Read 6947 times)

I have started working on an ambitious but important project called Bitcoin Dictionary - http://bitcoindictionary.org.

The problem I am try to solve is that we still don't have a credible source of definitions for Bitcoin-related words. Also, with the Bitcoin-related startups/projects/technologies that are coming up, we have new words being coined every day but we don't have a single place we can go to to find standard definitions of these words.

I notice that you have also noticed this problem too. Would you be willing to contribute to this project?

i would strongly advice against usage of any terms that only a banker or accountant would know of. "multi-signature transactions" can still be understood by anyone with some basic knowledge of bitcoin and reasonable knowledge of the english language. any banking-specific terms might be understood by a very few extra people with no knowledge of bitcoin, but are a pain in the the ass to look up or translate for any non-native speaker. "restrictive legend" for example is something i never heard of. even with the context of financial transactions i have zero idea what to make of it. its not on wikipedia and the only simple definition i can find is "restrictions on sale".

example: when i finally understand it and get the accurate translation of the banking term in german and someone tries to translate it back without realizing its a financial technical term, he might end up with stuff like "broadcast constraint" or "transmission limit". multi-signature transaction on the other hand consists of words that are probably common in all roman languages.

The account itself doesn't have a separate term, but the checks themselves can have two signature lines and the phrase "Two Signatures Required".  This statement is known as a "restrictive legend".  Other examples of restrictive legends include "void if not cashed after 90 days" or "not valid over $500".

Restrictive legends don't have legal force in and of themselves, except where a bank has contractually agreed to honor them.  Although many banks don't offer to enforce restrictions like this, others probably have a "two signatures required" flag as a standard field in accounts.  That said, banks will typically honor them anyway, or at least will typically apply some sort of discretion (e.g. they'd probably let a $50 check slide, and may not even notice the legend due to automated processes involved, but would be far more manual and careful with a $50,000 check).

Even when enforced in this slipshod manner, they effectively deter situations where one person runs off with all a business's or a charity's money.  If a restrictive legend said "two signatures required for over $500", it wouldn't stop someone from cleaning out the account with a series of $499 checks, but it would definitely slow the theft, draw attention, and raise questions, which is consistent with the intent.

Indeed, if it could cause any potential confusion as to how it overlaps with existing functional meaning of joint account, then it's a potential turn off. I think it could be a successful metaphor though, perhaps a well laid out GUI driven tool for establishing multi-sig wallets in all their possible variations would be all you need to avoid such a pitfall. Using the maths-ey terminology would obviously harbour potential confusion. I'm thinking little pictorial diagrams to represent the possibilities.

So is there a banking term for an account that requires multiple authorizations for spending?

I ain't never been a CFO or an accountant, so I don't know nuthin about that stuff...

I would be a fan of "joint account" and "shared wallet" to the extent these refer to single accounts that can be spent with approval from either party, since that's how joint accounts work in the fiat world.  Most people will think of this as husband and wife sharing the same purse.

I would consider them confusing if these terms were applied to an arrangement where both signatures are required.  Rather than being an account that belongs to two entities (people), a typical multisig fiat banking account is a business account that belongs to one entity (a corporation for example) and requires two signatures.  This would never be called a joint bank account.

RE: "multisig transactions" :

I did some high-level multisig design work a couple of months ago:
  https://gist.github.com/4039433
and
  https://moqups.com/gavinandresen/no8mzUDB/

... and had these thoughts about terminology:

I like it, a transaction is only deemed to be instantiated once a transfer order has had it's signatory conditions satisfied. It just so happens that we've been working with 1-1 signatory requirements up until now.

I actually think multi signature transactions would be well understood because they are the equivalent of multi party checks in the fiat banking world... there is already an existing concept to invoke as a mental prototype.

I might submit that the potentially confusing term is "transaction".  This term makes sense if a "transaction" has been completed, but when it applies to a data structure that's missing signatures or hasn't been sent to the p2p network, it might be better called a "transfer order".

Example usage:

If I want to make a transaction, my bitcoin client creates a transfer order, signs it, and broadcasts it to the network.

I might have paid an address that requires signatures from multiple parties to authorize spending.  For my funds to be respent, one authorized party creates a multi-party transfer order, the other authorized party also signs it, and then the transaction is executed when the completed order is broadcasted to the network.

I just realized that "multi-sig transactions" are clunky not only because of the unfriendly wording, but also because I don't believe that "transaction" is the way users will understand them.  Every coin in the network has a script attached to it describing how it can be spend.  Most of them require one signature.  Some require multiple signatures.  This is a property of the coins more than it is a "transaction".  Yes, it requires a "multi-signature transaction" to spend them, but users typically think about how they "hold" the coins, not how they spend them.  I've found it much easier to describe to Bitcoin newbies this way.

I think it makes sense to ditch "multi-signature transactions" and, if anything, use "multi-wallet coins", or "split-wallet funds".  Actually, it's probably worth separating out two different terms even though they are both the same concept under-the-hood:

(1) Multi-signature coins that require the signatures of 2 or 3 devices you own:  "double-protected coins", "two-factor coins", "split-wallet coins", "multi-wallet", etc
(2) Multi-signature coins that are serving as escrow between 2+ parties that don't trust each other:  "encumbered coins", "two-party funds", etc.

It strikes me that there's two approaches then:

1. The more abstract technical terms that can entirely describe the whole concept it's ascribed to in a single word

2. The more anthropo-centric terms that can be understood more quickly an widely, but provide an incomplete picture, and require a secondary explanation to let users really understand

These two approaches recur again and again, although I would understand if everyone would prefer there to be a single term that can satisfy both consumate explanation and universal comprehension. Thta would be the ideal that I think you're after. 

I think your point is dwelling too much on the literal meaning of "wallet", without acknowledging that many things in life, especially in tech, are named after things that they only approximately represent.  I think "wallet" is a perfect euphamism for "key collection that lets you receive and send money"

But you bring up a point that I like:  the "Observer Wallet" doesn't have to be a "wallet".  It could be more like a "collection box" or a "drop slot", etc.  The only problem with that is that it still behaves much like a "wallet", and it's definitely more convenient to bundle it on the list of "wallets" like Armory does.  And, I don't think it's incorrect at all to call it a "wallet" with an appropriate modifier, but you're right it doesn't have to be...

EDIT:  Actually, I'm not so sure I agree with not calling it a wallet.  An "observer wallet" is nearly identical to other wallets, it just happens to be missing one operation.  Users will use it exactly the same way.  And especially for savings wallets, their interactions with it may be 99% the same as a "regular" wallet. 

to all those advocating observer wallets, read-only wallets, no-spend wallets etc:

imho, a good name communicates as much correct concepts as possible and few or none misleading ones. the term "wallet" is already a compromise, emphasizing "you can spend bitcoins with this" but omitting the fact that its not containing money, but permissions. "key collection" would be a different compromise.
so, when you call a thing you cannot spend bitcoins from a wallet, you use it for something that lacks exactly the one concept that made "wallet" a useful word in the first place. the term is completely void of correct concepts. yes, under the hood it looks a lot like a wallet file. in terms of functionality, it has as much to do with with a real life leather wallet as a dolphin or a fruit juice.

This thread isn't about how to make Bitcoin go primetime, or how to best market it to new users.  It's about creating a common language for people that need that language.  Many of these terms may be relics of the past one day, and many of them may never be seen by, or cared about, by grandma.  But there's still plenty of users who need that language, because they're dealing with these things.  Right now.  And a lot of these potential users are people who will help build the foundation of Bitcoin's future.

My goal with this thread is to make sure there's a friendly, coherent landscape for the users of the system, right now.  Just because certain things may be relics of the past doesn't mean that we don't need to be intelligent about naming these things.  The current user base is more advanced, more technical than the average person using text-message.  But so is the current Bitcoin software.  And if there are options for it, we need to at least make it as easy as possible for them to understand it.  When Bitcoin is ready for primetime, I'll let the marketers figure out what to call these things, and what features users want.

I'm someone who is constantly bombarded by users asking what the hell each feature is.  How do I do this?  Is this feature the same as that?  Does it work the same in both this program and that?  While the Bitcoin world consists of complicated options, we need a language to talk about it.  You're talking more about how we'll market these things in the future, and how to choose which options are best for the user.  I'm talking about right now, even while Bitcoin is still manual-transmission...

Ultimately, if major adoption takes off, the type of language that the average user can use and understand might not be that easy to second guess. It's an experiment in collective consciousness of sorts, and just like paradigm shifts of the past, the world will suddenly end up with a few new concepts with words to describe them in it's parlance. As there is a necessary amount of learning to do, regardless of whether someone takes to using the more technical expressions or not, we can be pretty certain that some new expressions will become part of the mainstream. All we can really do is thrash out some sensible ideas. But what sticks will not be decided in this thread! Still a useful bit of brainstorming though, as if we can come up with something truly simple and meaningful with universal comprehension, then I think we'll have done a good job. We still won't be able to get people to use the expressions we come up with though, they're (collectively) in charge of that! 

I like most of the naming, but pointed out a few that I thought could use changes.

A) Completely disagree with "Online Wallet".  If you're truly trying to make this noob-friendly, then don't use the word "online" with anything that isn't web-based.  When you say "Online Wallet", the first thing people will (generally speaking) think of is a wallet hosted at a website.  I think "Hot Wallet" is the best terminology to use here, though it is still a bit on the geeky side.  Maybe "Live Wallet"?

D1) Call it "Read-only wallet".  People already understand what Read Only means, may as well take advantage of that phrasing for the Bitcoin counterpart.

D2) "Unlocked wallet" is the best noob-friendly term I can come up with.  "Full Wallet" is a vague description and conjures up zero images as to the usage of said wallet to a newbie.

E1) I do like "Chained Wallet", but I think "Seed Wallet" might do a decent job as well.  More and more people know what a computer seed means (from games, random number generators, whatever), so I think it might be good to piggyback on that naming convention.

H) "Proposed Transaction". Simple terms that still do a decent job of explaining what the object is.

I) "Proposed Transaction ID"

I agree on both counts: the software should sense the file type through magic bytes, and the file extension is for the benefit of the user.

This is already pretty common practice and is something I'd assume we'd imitate.  (try renaming a .jpg to .gif, and notice that many things will still open it because they see the magic bytes... the extension simply helped the OS's shell pick the appropriate program to open the file)

Let me compare it to iTunes.  What would a user say he interacts with?

Would a user say he interacts with "media" and "metadata" and "album art" and "playlists"?

Or would he say he uses iTunes to listen to his music, and to organize it, and load up his iPod?

The moment we decide that the user even needs to know he is "interacting with a label", the resulting software is no longer speaking his language.

I submit that the user should be able to use the software without needing to name anything.


Let me compare it to vehicles.  What if I told you you can't just call everything a "vehicle" with no qualifiers, because that neglects the profound differences between cars, buses, trucks, and trains?  Not to mention airplanes?

On the other hand, if I say "vehicle" to you, you probably think of a car.  This is probably because cars are the most popular kind of vehicle that you and everybody you know interacts with.

When deterministic wallets are the norm, the word "wallet" may as well mean one.


If I sent you a PDF file and it needed a password, and I called it a "password-protected PDF", you would get it.  So would the average user.  So this is entirely acceptable as a qualifier.

The most important thing here is it is a distinction that is meaningful to the user.  100% of users will care if a password is needed, since it's instrumental to their ability to use the file.


The average user would be satisfied calling it a ".dat wallet", a ".bw3 wallet", or whatever.

If the user has to stop and ask "wtf is a loose key wallet", you've lost his mind share.  99% of people never ask what does "MP3" stand for, this doesn't stop them from using their iPod.

I would strongly suggest that different kinds of wallets be given names that have no words in them, and leave the job of explaining the technical differences to the documentation.

I accept .wallet as a good extension, but this should be reserved for a wallet type that is a) standardized, b) well accepted by the community, c) has all of the important features we have determined that wallets should have.  At the very least, a user should be able to expect that wallets saved by any application that creates .wallet files can also be read by any future application that reads .wallet files.

I think some of these distinctions are academic.  The reality is Bitcoin isn't ready for primetime.  I have long believe (that dozens of other revolutionary technology) we are on a decade long timeline to mainstream usage.

random vs deterministic - nobody will care.  By the time Bitcoin becomes mainstream 99.99999999% of wallets will be deterministic.   It would be like classifying computers are binary or trinary.  Who asks if their Dell laptop is a binary computer?  Who worries that the flash game might not work unless they can verify it wasn't written for trinary based machine language? Nobody.  Except for extremely small niches (by technically savy professionals) all wallets will be deterministic.  The risk of losing funds due to out of date or corrupted backup is simply too high for random wallets.  They will fall out of favor like floppy disks.

encrypted vs plaintext "I want to be robbed because I have too much money" - once again nobody will care.  This is money we are talking about.  The fact that there are wallets which are incapable of encryption simply shows Bitcoin isn't ready for primetime.  I would hope and pray this oversight will be long since corrected before Bitcoin becomes even close to mainstream.  Also encrypted is not understand by most people.   "Password protection to keep your funds safe" = sufficient for mainstream users.

Many of the rest of the terms aren't "wallets" they are "features of a wallet".  

watching wallet?  No such thing.  It is simply confusing.  A wallet is something you use to hold money/value.  It would be like calling an ATM receipt a watching "wallet".   Someone up thread nailed it.   There is no such thing as a watching wallet; there are "wallet watchers"!.  It isn't a type of wallet it is a tool, utility, feature of a wallet (or maybe someday ALL wallets).

linked wallet?   Most people will simply see this as a "double key/login/authorization" and understand it is for security.  They won't want to even begin to understand how the phone is actually part of the wallet and the keys from both the wallet and phone need to be both used to produce the valid multi-sig transactions ..... ZZZZZZ ..... ZZZZZ ..... ZZZZ.  Using terminology that users already understand like 2FA or even more simplistically something like "asks for confirmation from your phone".

" .... for even more security xyz wallet will get confirmation of all spending right from your mobile phone.  See this video demo.  [demo of guy spending 100 BTC on his laptop then getting a security confirmation on his phone to authorize or deny]

TL/DR nerds like to classify things, users like to see FEATURES.

Example of a wallet advertisement circa 2020
xyz wallet supports ...
* password protection to keep your funds safe.
* ability to print your own money from any inkjet or laser printer (offline paper key generation and auto transfer).
* supports usb PIN pad to defeat malware and hackers.
* approve or deny all transactions right from your phone.
* daily spending limits.
* remote wallet monitoring ... great for parents.
* optional bitcoin escrow & recovery system (never lose funds again).

The last posts by Casascius and etotheipi indicate that classifications should be driven by the functional differences (which are important to the user) and not differences in the underlying architecture (which are important to the developer)


Using file extensions I think is a bad idea as they can be changed by the end user.
Thus you are forced have to have something in the file (magic bytes, the flags I mentioned) in addition to check the structure.
Just call it a ".wallet".