A Guide to Cryptocurrency Terms

A Guide to Cryptocurrency Terms

The financial industry uses a lot of jargon that is quite difficult for people new to the topic to comprehend. The cryptocurrency industry is no different, as it mixes tech talk with investing terms, which can make studying its markets even more challenging.

I have addressed topics like this before in my ‘Cryptocurrency Trading’ article, and touched on a few key terms you should know. In order to expand your understanding of terminology a little further, here are some more common cryptocurrency terms that I’ve come across and thought needed defining:



A cryptocurrency address is the same as a person’s home address; it’s the “location” where a person can receive or send cryptocurrency from. The only difference with a digital address is that its string of letters and numbers are unique to each cryptocurrency holder, functioning like an ID.



Altcoin refers to cryptocurrencies other than Bitcoin. Alternative cryptocurrencies like Ethereum or Dash are altcoins that people can mine and invest in.



This refers to investors taking advantage of a price difference of the same cryptocurrency on two different exchanges. This is possible because there are a lot of online cryptocurrency exchanges in the world that offer digital funds at different prices.


Bearish / Bullish

A bearish cryptocurrency market refers to one with a sluggish demand for digital assets, which tends to drive prices down. A bullish market, on the other hand, is the opposite of a slump. When investors are bullish on a cryptocurrency, its prices usually go up.



A bot is a program that lets people use pre-programmed commands for trading cryptocurrencies. This is similar to the trading software used by Forex traders. Bots can be programmed to protect investors from accumulating high losses by stopping trading when the capital drops by a significant amount.



A block is similar to a notebook page, and it is used for the purpose of writing and storing data.



Blockchain is the technology that powers cryptocurrencies. It is the framework used for creating digital ledgers involving transactions. A blockchain is basically a network of people and computers all working together in order to produce cryptocurrencies.


Block reward

This refers to the reward given to people for solving difficult mathematical equations related to mining cryptocurrency. The block reward is different for every cryptocurrency. For instance, the block reward is currently at 12.5 coins per block mined on the Bitcoin network, and the next halving event takes place in May 2020. This will bring down the block reward to 6.25 coins.



A price correction happens whenever a cryptocurrency experiences an all-time high. Assets get “corrected” whenever a price spike happens because investors sell their holdings when the value of the coins gets high enough for trading.


Hard Fork

A hard fork is a change of the rules to a digital currency’s blockchain. FXCM explains that it is a “permanent change in the rules of a digital currencies blockchain”, particularly in mining, which requires the support of the majority of people using the network. A hard fork usually happens when developers find a solution to recurring bugs or weaknesses from the old blockchain.


Hash Rate

A hash rate refers to the length that it takes for a computer to discover a block, as well as the time required for solving mathematical equations for mining.



An initial coin offering (ICO) is a new cryptocurrency being offered by fledgling entrepreneurs who are hoping to get funding from venture capitalists. The entrepreneurs will pre-sell their new cryptocurrency to venture capitalists before they go public.



Mining is the process of solving mathematical equations on a certain block. Once the equation gets solved, cryptocurrencies come out as the reward.


Mining Rig

This is a computer, or a set of computers, designed for processing blockchains. They are made up of several expensive graphic cards that speed up the mining process of cryptocurrencies.



P2P means “Person to Person,” which is a method of sending and receiving cryptocurrencies without the need of an intermediary. P2P transfers are what make cryptocurrency transactions cheaper and more direct than sending money abroad through a bank.


Smart Contract

A smart contract is an agreement between two parties stored on the blockchain, and is much more secure than paper contracts. Smart contracts can also be used to define benchmarks that must be met before payment can be made.


Soft Forks

Soft forks are updates to an existing network. The updates are implemented on the same network, unlike hard forks that affect a completely different block.



People usually send unencrypted files over the internet. Attaching a word document on an e-mail or sending pictures via Messenger are usually unencrypted methods of sending files. Tokenization is the act of encrypting data by turning them into a string of random letters and numbers. All data sent between wallets are tokenized on the blockchain, making cryptocurrencies virtually tamper-proof.



Bitcoins need to be stored in a wallet for easier access and to keep them secure. There are two types of wallets: software-based and physical wallets. Software-based wallets are online wallets that collect data on a person’s cryptocurrency holdings. An offline wallet, on the other hand, can store data on cryptocurrencies in the same way that a DVD can store computer files.

Hopefully these terms help make more sense of the cryptocurrency world!

Office 365 Group as a Distribution List Gotchas

Office 365 Groups aren’t that new, but they still sound more alluring than a plain Distribution List or Shared Mailbox (yes this is why I chose the article photo). They aren’t the solution that applies to all situations however, and you’ll need to weigh up each scenario as to what fits best.

(for Office 365 Group fundamental considerations, please read Michael Mardahl’s blogpost “Getting off to a good start with Microsoft Office 365 Groups”)

Here’s some things around Office 365 Groups and using them as an email distribution list (DL) that caught me out, or are differences worth pointing out. If you’re thinking of migrating a DL or a shared mailbox to an O365 Group, these are worth considering:

  • An Office 365 Group mailbox can’t have folders created in it. If staff have access to a shared mailbox and use that to manage their emails under different folders, that’s a no-go for an Office 365 Group. There’s a bunch of other ways you can manage this, but if they specifically want that option, then an Office 365 Group won’t help them.
  • If a member of an Office 365 Group sends an email to the group, they won’t get that email. It makes sense that you probably don’t want an email that you sent, but it is a change of behavior from traditional DLs. This may change in the future, at least as a toggle-able option.
  • By default, users will see a ‘Groups’ option in Outlook (either client or web) which they can drop down, see the groups they’re in, and see the inbox. That’s the only folder that’s visible though, and it can be easy to assume that’s the only folder. There are however, several folders available. You can’t open an Office 365 Group as another mailbox, as you’ll be told via Outlook Web that you don’t have access to the mailbox, and Outlook client won’t recognise the name of the mailbox.
    You can however, use the ‘Open Shared Mailbox’ option in Outlook Web by right clicking on your mailbox in the folder view, or right clicking on ‘Folders’ (depending on if you’re using the ‘old’ or ‘new’ Outlook) and add the Office 365 Group that way. This will give you visibility of all folders and their contents:
  • Automating Office 365 Group membership is harder. You either automate membership with a dynamic group, or let the owner(s) do it themselves. Neither are bad options, but dynamic group membership exceptions to rules are harder to do. How do you have a group that’s all Finance, plus these 4 people that aren’t finance? You could have an expression like this, but that is something that could get rather messy to maintain:

(user.department -eq “Finance”) -or (user.mail -eq “user1@domain.com”) -or (user.mail -eq “user2@domain.com”) -or (user.mail -eq “user3@domain.com”) -or (user.mail -eq “user4@domain.com”)

  • Meeting responses work differently to a DL. Say you send a meeting appointment, and have the respones go to a DL – all members of the DL see the response. This can be useful in certain scenarios, but probably not that common. An Office 365 Group works differently, where the ‘Meeting Message Processing Agent’ in Exchange Online will see the meeting response, and send it directly to the Deleted Items folder. This action skips members receiving a copy of the response which might be good generally, but again it’s another different way that Office 365 Groups work when you’re expecting the same as a DL.

That’s what I’ve found so far – if you have any yourself please share and I’ll test/add to the list, and will update with any other tricky scenarios that I come across.

Force Multi-Factor Authentication Registration in Azure Active Directory

If you’ve gone down the path of Azure Active Directory (Azure AD), then I dare say you’re not at the end. It’s a long but rewarding path, with new features constantly being added to enhance a critical service in the Microsoft offerings.

It’s also likely you didn’t start with Mutli-Factor Authentication (MFA) in place and ready to go. Maybe you did and well done! For the rest of us though, we slowly move into these systems while turning more options on.

Just enabling MFA with Conditional Access is great, but getting all users to actually register for MFA https://aka.ms/mfasetup can be a challenge. If you’re fortunate enough to have Azure AD Premium P2 licensing, you can use a MFA registration policy to do a nicely managed rollout and force people on. Those without P2 however, have an option that’s a bit hidden, not as well known and slightly scary:

Require users to register when signing in?

Under the question mark: Designates whether unregistered users are prompted to register their own authentication information when they sign in for the first time. If set to “No,” administrators must manually specify the necessary password reset authentication information in the properties for each user in this directory, or instruct users to go to the registration portal URL directly.

The description for this option is a bit misleading, it actually means that they’ll be prompted the NEXT time they log in, rather than the first time.

This option is found under Azure Active Directory > Password reset > Registration, and is off by default.

Turning this option on is a company wide setting and from my testing, worked pretty much immediately. As soon as someone who hadn’t signed up for MFA logged onto office.com, they were prompted to go through the MFA registration process. There’s no way to point this at certain users or test it, you just have that one little switch to turn it on for every single account in your tenant.

For someone who had signed up for MFA, they were asked to confirm the details entered previously.

I’d recommend letting your staff know before this option is toggled, but at least it can easily be turned off again if you run into any issues.

Update 2nd May:

After publishing this, Sean Flahie on Twitter mentioned his experience if Azure Self-Service Password Reset (SSPR) wasn’t enabled for users, and enabling the combined experience – both of which I have in place already. If you’re having any issues then please look into both of these.

Microsoft DOESN’T admit expiring-password rules are useless

CNET has an article titled “Microsoft admits expiring-password rules are useless” which I strongly disagree with, and thought it was worth explaining why.

Beyond the actual blog post from Aaron Margosis at Microsoft not actually containing the word ‘useless’, it’s an inaccurate summary of what is a well written and clear write-up from where I sit.

This all came out of publishing the draft of the Security Baseline recommendations for Windows 10 1903, which details out what settings Microsoft recommend and why. If you’re managing a Windows environment, these are a must read, and should be reviewed with each version of Windows 10 you plan to move to.

The general take of the CNET article was that password changes have been useless for years, suggests Microsoft should completely ‘yank’ the ability to force passwords to expire, and if your IT staff don’t remove password expiry immediately, they’re living in a ‘security Stone Age’. It’s rather insulting and coming from someone in my opinion, who doesn’t know what they’re talking about. They might say the same about me, of course :)

On the other hand, Microsoft’s blog post tells a different story. Yes, passwords are problematic and forcing them to change frequently causes other issues where people just change the number on the end by ‘1’, but they aren’t saying password changes are useless.

Microsoft used to recommend 90 day expiries, then to 60 days. The idea there was that if a credential is leaked somehow, the smaller window that the password is known by third parties, the better. But, if your password M0nkey34! is now M0nkey35!, that’s probably going to be the first thing a targeted attacker tries if the password they had for you didn’t work.

Although all this is true, it works on the assumption that someone is actively targeting you. It happens, but it’s much more common for attackers to just do spray attacks based on millions of credentials they have. Why are they going to pick your account and try a bunch of combinations of passwords, when they could just go through stupid amounts of records with no effort and find weaknesses there?

Say you are a target for some reason; it’s likely that the password leaked from somewhere isn’t new – it’s probably months or years old. If you’d never changed your password because your company never forced it to change, then the attacker now has a valid password for you.

It’s also much more likely your password was stolen from a 3rd party service, nothing to do with your corporate systems. You might have signed up with your work email address, but the password ‘should’ be unique to the service signed up for. We all know users don’t work that way, and use the same password all over the place. Having a password they know will change frequently, may mean that they use something at least unique, even if it does increment.

All of this is moot of course, if you have multi-factor authentication (MFA) in place, because the requirement of something else (a phone, bio-metrics etc) means a username and password by themselves are actually useless. However, most companies do have systems in place that have no options around MFA, so what do they do?

To re-iterate, I agree with everything said in Microsoft’s blog post. This is where one paragraph in the blog post sums it up nicely:

Periodic password expiration is an ancient and obsolete mitigation of very low value, and we don’t believe it’s worthwhile for our baseline to enforce any specific value. By removing it from our baseline rather than recommending a particular value or no expiration, organizations can choose whatever best suits their perceived needs without contradicting our guidance. At the same time, we must reiterate that we strongly recommend additional protections even though they cannot be expressed in our baselines.

Work out your risks, your userbase, what systems might be impacted, what extra protection you have in place and make an informed decision around what frequency works for you.

The focus shouldn’t be on password changes, but should be on implementing those other protections in all scenarios – but before that happens (which for many companies can easily take several years), you’ll need to work out what policy you do. There is no single best-fit recommendation on what that is when using pure passwords, because they’re inherently bad however you look at them.

Look at Conditional Access, Password Protection and Azure AD Identity Protection for starters on adding in these extra protections!

The answer isn’t a pure ‘password changes are useless’, and it’s irresponsible to say so.

Outlook Search Results Won’t Delete

I ran into this issue when migrating users to Exchange Online, while running Outlook 2016 MSI 32 bit.

Once a user is on Exchange Online, Outlook starts leveraging the power of FAST search. This search occurs on the Exchange Online end, rather than the device end, and is designed to give quicker results while being more reliable than Windows Desktop Search. There’s a great write-up on this on Microsoft’s TechCommunity that goes into much more detail.

It does depend what sort of search you do as to whether it’ll use FAST or Windows Desktop Search too, but the most basic of searches will use FAST. There’s also timeouts and speed checks that can force it to fail back to Windows Desktop Search.

However, there are some catches with this search from my testing. If you do an email search and decide to delete one of the emails in the results, it appears that nothing has happened. You can delete and delete, right click, press the delete key, click the X to delete and it all appears to do the same – nothing. In the background though, it has actually deleted your email, it just doesn’t display this in any way. It’s like the search results are a static result and won’t update on an action like this.

This behavior can be confusing for a user, especially when they’re used to seeing emails disappear and react when something’s done to them.

There’s another catch that depending on your environment, might be more of a deal breaker. If you use the category field, flag, or extra fields, for example when filing a document into a DMS system, those aren’t displayed or updated in a FAST search. If your users need this to effectively manage their emails, then it’s worth looking at just disabling FAST search via Outlook altogether.

As mentioned in the above post and this Technet article, there’s a single registry setting that can disable FAST search:


Value name: DisableServerAssistedSearch

Value type: REG_DWORD

Value: 1

A restart of Outlook is needed after this change, and users won’t be alerted of anything different. Search will just start using Windows Desktop Search (which was always running anyway) and not know any better.