Understanding Bitcoins: What Is it and How Does it Work?

This isn’t even remotely SharePoint related, but I’ll still blog it. It’s my blog, dammit!

If you have no idea what Bitcoins are, it’s a way for you to make your own money. Really. Oh, and it’s free, as in beer.

Read on and I’ll tell you more.

In this series, I’ll explain what Bitcoins are, how they work, why they work, and how you can make your own money. First, I’m going to explain what Bitcoins are and how they work, and you can check the bottom of the article for more parts on the other topics.

What are Bitcoins?

A Bitcoin, or BTC, is a digital currency that solves a number of issues with existing national currencies (also called fiat currencies). It is the currency world’s equivalent of what the internet is to information; a distributed, tamper-resistant, decentralized, secure, and potentially anonymous way to handle money.

Bitcoins are becoming increasingly popular as a currency and you can already pay with Bitcoins on several sites and stores, such as Reddit and WordPress.com (plus many, many, many others). In addition, there are many currency exchanges that allow you to trade Bitcoins for traditional currencies and exchange it for ‘real’ money.

Note: I’m contemplating whether to start accepting Bitcoins as payment for my training and professional services and for USP Journal, and although the jury is still out, I’m leaning towards at least trying it for a while. I’ve added a Bitcoin donation option at the bottom of my blog articles for starters.

Unlike fiat currencies, though, there is no central authority behind the currency. The existence of Bitcoins relies solely on the thousands of users that participate in the network, which they do by running a Bitcoin client that allows them to store, send, and receive Bitcoins from others through a Bitcoin wallet.

Every transaction in the Bitcoin network is public, but the wallets are completely anonymous. In fact, you can even generate wallets yourself and all clients I’ve used allow you to do so easily. These wallets contain your Bitcoins, so you may think of them as similar to bank accounts, except you don’t have to be a bank or even a customer of one to have a wallet.

When I say that transactions are public, this is a key component to both the security and the stability of the Bitcoin network. Transactions are cryptographically signed and broadcast to the network, which then validates each transaction, and each transaction becomes part of the global chain of transactions which after it has been verified cannot be changed. Thus, you can’t ‘trick’ the system in any way because neither you nor the recipient is solely responsible for validating a transaction like you have in traditional banking, for example.

I’ll leave the finer details on how this works for a possible future post.

Is it Fake Money?

When I try to explain Bitcoins to people, the first thing people say is that “it’s not real money, it’s not backed by anything”.

Well, sunshine, nor is any other major currency in the world; it is backed only by demand and trust in the system, which is why fiat currencies like the US dollar or Euro fluctuate wildly depending on whether people trust the stability and demand of the currency. In fact, it’s been decades since the US dollar was backed by anything but the market’s demand for it; you can’t just go to the Federal Reserve and trade your US dollars for gold, for example, nor can you swap your Euros, your Norwegian Krone, or your Indian Rupees for anything but products and services or other currencies.

Bitcoins are no more real or fake than US dollars or Euros, although it is in much lower circulation. Think of it so far as a minor currency in that respect, like Norwegian Kroner. Only demand for the characteristics of Norwegian Kroner make it a viable alternative for representing value, and it’s only because society agrees somehow to ‘trust’ a currency to some extent that you can even say you have value when you hold a currency.

You can’t take a Norwegian Krone and buy stuff in Boston, and although you may get a bank to exchange it for US dollars, that’s going to cost you fees, and the bank decides the exchange rate. For Bitcoins, most transactions are completely free and it costs nothing to own a wallet either, so your money remains in your ‘account’ forever. On the flip-side, you don’t earn interest either, at least not until someone comes up with a banking system that can lend people BTC in the more traditional sense.

What Gives Bitcoins Value?

The only thing that gives value to Bitcoins, just like any currency, is your ability to buy stuff with it, and let’s face it, the options for buying is still very limited compared to traditional currencies. That said, there are already hundreds of sites that accept Bitcoins and you can exchange your Bitcoins for traditional currencies like you can with any traditional money. The valuation of Bitcoins depends on demand, which in turn depends on the ability to exchange it for other things, just like for any other currency.

Bitcoins have some unique characteristics that make it competitive to fiat currencies, though.

First, the for fiat currencies, you trust the issuer (Federal Reserve in the US, European Central Bank in the EU, Norges Bank in Norway) to control the value of the currency. Only they can issue new money, and you trust them not to double the amount of dollars in circulation, for example, which would skyrocket inflation. As we have seen in recent years, in times of crisis, countries like the US issue more money into circulation, thus reducing the value of each dollar and increasing inflation, meaning your money is less valuable.

For Bitcoin, the supply of money is steady and accurately predictable down to almost the hour through as technique called controlled supply. There will only ever be 21 million BTC in existence, and these are distributed through a process called mining, a process, by the way, in which you can participate and thus make your own money. I’ll go into more detail on how this works in Part 2 of this series.

Through controlled supply, the rate at which new Bitcoins enters circulation is fixed and predictable, and ends somewhere around the year 2140 (as in over a hundred years from now). However, most of the Bitcoin will enter circulation much faster, and more than 99% of all Bitcoins will be in circulation by late 2032.

Thus, there is now way that inflation will reduce the value of your Bitcoins; in fact, a problem may actually be deflation, in which your money becomes so valuable that people don’t want to part with them, driving prices for goods and services paid in BTC down.

Second, Bitcoins are cryptographically secure, meaning there is no way to counterfeit money or fake transactions. In fact, you can’t really have physical money at all, which solves a lot of the problems with traditional money (loosing them, ‘black market’ trading, counterfeiting, wear and tear, and so on).

Technically, it is possible to ‘trick’ a transaction for a few seconds after it has happened, but it would be the equivalent of swiping your credit card and then taking the products and run before the transaction can be verified by the credit card company. A Bitcoin transaction is more secure than regular transactions because there is no way to reverse it after a few seconds, which works to secure both the buyer and the seller against chargeback, fake money, validation issues, and so on. For larger transactions, you can just wait a bit longer before you approve the purchase, just to be extra sure that nothing can go wrong.

Third, Bitcoins can be completely anonymous, which may sound sketchy at first, but is important in some situations. I’ll leave the discussion about whether anonymity is good or bad for a later post, or preferably a different forum, but I’d like to point out a couple of things regarding that anonymity.

Bitcoin anonymity is just a potential anonymity, and you have to take special measures to ensure your transactions are anonymous. Everything in Bitcoin is completely transparent.

Keep in mind that every single transaction is publicly completely visible to the entire Bitcoin network. Thus, if the identity of a wallet’s owner is known, everyone can see who that person sends Bitcoins to or receives money from.

Because of this, everyone can also see how much money is in each wallet. If you put your wallet address in public, well, everyone now knows how many Bitcoins you have in that wallet.

This transparency may freak you out at first, but there are ways around having everyone snoop into your financials. Nobody knows who owns each wallet by default. You don’t have to publish your wallet address, and even if you do, you can still have as many wallets as you care to generate, so you can simply have a ‘receiving wallet’ and a ‘storing wallet’ or even multiple layers of wallets, which makes tracking more difficult. In fact, a recommendation for those wanting to retain anonymity is to use a single wallet for every transaction you make, which may sound like a lot of work, but is actually quite easy.

Conclusion for Now

The bottom line is this: Bitcoins are ‘real’ money in the same way other currencies are ‘real’ money. Bitcoins have many unique properties which address many problems with fiat currencies, but whether they have a value depends on whether people want them and whether merchants accept them.

In the next part, I’ll talk about how Bitcoins come into existence, and how you can make your own Bitcoins, at home, using nothing but your computer, a bit of electricity, and some patience.

Want to learn more about how Bitcoins work? Here are some resources from the Bitcoin wiki:

Bitcoin Wallets

Bitcoin Transactions

Bitcoin Transaction Fees

Controlled Supply

Anonymity

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Pin It

SharePoint 2013 App Model Solves Non-Problems Only?

I’ve been thinking again, and even read a bit, which is unusual for me, because I don’t read much. This time, I’ve read Doug Ware’s blog post on which model, Apps or Farm solutions, is better. In this article, Doug, a renowned developer and now seemingly proponent of the App model, ends up concluding that for certain definitions of ‘better’, Apps in SP2013 are indeed ‘better’.

To me, the issue is not whether one model is better than the other, but rather what problem a new model solves. In the case of the App model, I have yet to see anyone come up with real problems that aren’t readily solvable using other methods. I don’t actually see why I need an App solution at all; it’s a solution to problems that don’t exist.

Let me briefly respond to Doug’s points.

Modern Web Development Techniques

Doug states that between farm solutions and Apps, there is a tie in the case of modern web development techniques, and by this he is referring to HTML5+CSS3+JavaScript, and stuff like that.

He is correct in one thing, in that a Farm solution has no downside compared to Apps. Farm solutions has always been able to output pretty much whatever you want, including but not limited to what’s currently defined as ‘modern’. In fact, I’ve shown this by pulling a completely HTML+JS+CSS based web page for an invoice and with a couple of hours of jQuery work, made that page work directly with SharePoint data for SPInvoice, shown below.

Granted, it’s not HTML5, but that’s just because I couldn’t find one readily available.

This is a farm solution, and it works in SP2007 (or should, I didn’t actually test). No need for a new model to build ‘modern’ anything.

However, the App model, in terms of ‘modern’ development is actually more limited, simply because JavaScript lacks maturity in tooling, robustness, and flexibility. It’s a bit like being told to build a house using only your right hand, which, although possible and certainly something you could learn, is still far more limiting than having both hands available, which is what you have with Farm solutions.

In simpler terms, there’s nothing that the App model gives you that you cannot already do in SharePoint, within the topic of ‘modern’ UI development.

Scalability

Doug favors Apps when it comes to scalability. His argument is that code running in Farm solutions must run on the farm and thus taking away performance from the farm. Increase the load and your farm will eventually suffer. This, Doug claims, is solved in Apps.

The truth is that this is again a non-problem and Apps solve this no different than you can solve it in Farm solutions.

There are two scenarios to keep in mind here. First is when you are working with SharePoint data and the second is when connecting to external data.

SharePoint Data

When you access SharePoint data, it doesn’t really matter too much whether you access that data using an App or a Farm solution. The performance impact does not come from the rendering of the data on the page but rather from accessing the data. That access needs to happen regardless of whether your client is an App or a Farm solution. Apps scale no better than other access methods, they query the same data, hit the same SQL servers, loads it over the same network, and SharePoint needs to work just as much to retrieve that data.

I’m guessing that someone will think that when you’re accessing and rendering data using JavaScript, you’re taking a load off the web server and putting that on the client. That may be true, but if this is a real problem, you can solve it using JavaScript output from a Farm solution just as easily as you can using an App. Marc Anderson’s SPServices is a great example of this, and it’s working all the way back to SharePoint 2007.

In fact, with Apps, you have _fewer_ options for rendering data, because you _must_ use JavaScript on the client. A server can much more easily cache data, rendered or not, and has far more options for providing scale than Apps have. With an App, you essentially turn the responsibility of caching or optimizing over to the clients, over which you have no centralized control.

External Data

One key argument for the App model is that it’s easier and more scalable to offload performance intensive work to external services. If you have data stored in web services on another farm, a public web service, or a ‘potato-powered’ web server running on GEOS, according to the arguments, Apps are better because they allow you to integrate that data into SharePoint pages.

Again, this is simply not true, at least the ‘better’ part. SharePoint has long been able to integrate external data in Farm solutions, both on the server side, but of course also on the client side.

On the server side, you have decades (at least one and a bit) of experience in .NET development to aid you in integrating external data, whether that is access to SQL servers, SAP, Exchange, or any other external service. This puts load on the server, but if that’s of concern to you and you’re not willing or able to solve that on the server side, you can always fall back to exactly what the App model is doing; running it on the client side.

Keep in mind that Apps do nothing beyond what is already possible in the browser, and you can do exactly the same things by outputting the same or similar JavaScript and HTML code from a Farm solution, in a page. You can put your ‘App parts’ anywhere, including on the potato-powered CBM64 wannabe, and still include it on any page using the same iframe and JavaScript tricks that an App would do. You can use jQuery and SPServices to bridge multiple SharePoint farms; you can use VBScript for crying out loud, if you really want to shoot your foot off.

So, Apps solve no problem that you can’t already solve with Farm solutions in the exact same way. What Apps cannot do, however, is centralize caching, load balancing, performance management, and all the other benefits you get from server-side code. Loss again for the App model in terms of options for scalability.

Maintainability

Doug’s final argument in favor of Apps comes from its maintainability over Farm solutions. I’ll quote Doug’s argument verbatim as of today:

The downside to farm solutions is that they use a very powerful but comparatively rigid combination of file systems and a SQL databases in conjunction with lots of XML files. In order to use a solution, it must be installed on a farm and put files directly on each server. The XML files are features, site templates, list templates, and a wide variety of other artifacts. This system works really well unless the same solution is installed on multiple farms and used by many site collections and needs to change to accommodate new features or bug fixes. Furthermore, some things, like site and list templates, are very dangerous to change once sites and lists exist that use the templates.

These issues with farm solutions, in short the ability to maintain bug fixes, changes to solutions, site and list templates, and so on, have been solved years ago, and is simply a result of lack of maturity in SharePoint understanding. Although others have come up with similar solutions, I explained a method or framework for building maintainable and agile solutions in SharePoint in 2009, in Professional SharePoint Development and have since used that method for virtually every solution I’ve built.

The argument is thus void and a bit of a straw man argument against farm solutions.

Doug further goes on and argues that

The app model makes it possible to centralize and serve content to as many farms as is necessary and if you use CSOM to provision everything instead of XML you remove the coupling between concrete instances of sites and lists and their definitions. CSOM allows the creation of fields, content types, lists, web part pages, and other types of files. In my app everything, with the exception of one page, is provisioned by the application server running on Azure. The app server is capable of updating these items and of adding new items. It makes no difference how many farms use the app from an update perspective, each can be patched centrally whenever a user launches the app.

This isn’t true for two reasons. First, the App model does not make this possible; the client side object model (CSOM) does. CSOM is available to Farm solutions as well, both as traditional Farm solutions, as Sandbox solutions, and again through client side code, if you so desire. You don’t even need to run this from the server, you can again output the CSOM code from a PHP page, a text file loaded from a mobile App, or from any other source you like. Completely possible from 2010 onwards, which marked the introduction of CSOM.

The second reason why Doug’s argument is false is that when you are creating artifacts, changing the definition of those artifacts after the fact won’t change the artifacts. Put in a simpler analogy, if you change a recipe for a dish you cooked, the dishes you’ve already cooked based on the previous recipe won’t change. You can ‘patch’ the recipe by, for example, creating a second recipe to add sprinkles on your cinnamon rolls, and you can even change the innards of those cinnamon rolls by specifying that you should inject some vanilla custard into them, but you can’t ‘uncook’ and ‘recook’ an existing dish by changing the recipe.

The same applies to SharePoint, especially when it comes to templates, but even if you have scripts or code that creates artifacts. For templates, you avoid this by having ‘no content’ templates (or as I like to call them, the perfect templates) and create the content using code.

However, even if you write code to create for example lists and content types, changing the code will not change the lists and content types. You still need to create new code to modify those lists and content types. This applies equally to JavaScript with CSOM, Farm code with server-side code, Apps calling CSOM, or anything other combination that creates artifacts in SharePoint.

Sorry for ruining the arguments for everyone, but again, the App model fails to add anything that cannot already be done, and be done quicker, easier, and with more options, with Farm solutions.

What About the Marketplace?

Ah, I knew that was coming. Apps, of course, are the only solutions available through Microsoft’s App marketplace. Unless you build Apps, you can’t really get access to the gazillions of SharePoint installations out there. Must be a great opportunity, right?

This is true, the ‘opportunity’ part only to the extent that you believe that somewhere in the future, organizations will jump at the chance to buy critical business applications through a dollar store.

However, again, the App model doesn’t solve this problem. It’s perfectly feasible and possible to build App stores for SharePoint prior to SharePoint 2013 too. Below is my SP SIN store running on SharePoint 2007.

In fact, the App store isn’t even related to Apps per se; it’s simply an interface to distribute Apps and has nothing to do with the App model as a development platform. It is, despite all it’s glory, nothing but a marketing tool to get people to jump on Apps as a development model. You can run Apps perfectly well without the marketplace; they are completely technologically unrelated.

Do I Hate Apps?

Before you start your flame wars about how I must hate Apps and must be stuck in the stone ages, I don’t hate apps at all. However, I have yet to see real arguments for

  1. What real problems do Apps solve that you cannot solve already using other models?
  2. What are the technical benefits to using Apps compared to existing models?

In other words, I just don’t see the point of Apps. I fully understand them in terms of Office, I can understand them as extensions of closed frameworks (think Facebook, Hootsuite, Yammer, etc) where you don’t really have the option of building server-side code. I don’t see the scalability issues because these are easily solved in current models too and nothing done in Apps cannot be done already.

So, there you have it. My jury is still out, and they’ve been trying to find evidence that the App model is a useful tool.

They haven’t decided against it yet, though.

.b

Pin It

Are You a Sinner?

A few months back, I created a framework called SP SIN, which allows you to inject code like JavaScript or CSS into any SharePoint page without modifying the master pages. The SIN part of the name stands for Script/Style INjector.

Modifying master pages may seem like a trivial task, but there are many and inherently bad consequences of doing so. For example, you need to customize the master page which breaks the link to the deployed master page, which in turn complicates things like upgrading or global modifications to master pages.

SP SIN solves this and many other problems. For example, I’ve built a resource type that allows you to add Google Analytics to your SharePoint pages with just a few clicks. I’ve described how to build SEO plugins to add metadata to pages, showing content, scripts, or style sheets to site owners only, and so on.

SP SIN is a free framework, available on CodePlex (along with many videos that show how it works), and feedback from users has so far been pretty amazing.

One aspect of SP SIN is that it is built to be incredibly flexible and extensible. Even if you’re not a developer, you can still build and redeploy SP SIN configuration packages, and if you are a developer, especially a third tier developer, then your options for extension are vast, to put it mildly.

I’ve even built a proof-of-concept for an App store, that works across all versions of SharePoint (back to SharePoint 2007) in SP SIN.

Here’s where this may interest you as a reader of USP Journal. I’ve wanted to write an issue, maybe more, on SP SIN ever since I created it, but I need your feedback on the type of issue.

Should I write for end users who just want to put SP SIN to use without focusing on any development or extensibility points? Should I target middle tier developers who may not want to or be able to build WSP solutions? Should I go deep down and talk about building custom SP SIN resource types and SIN CYCLE receivers? Should I explain the inner workings in an SP SIN Explained type issue?

Here’s what I want you to do.

Head over to the SP SIN homepage. http://spsin.com/
There’s a brief intro video on the front page that shows and explains the outline of how SP SIN works. Next, review three videos (or not, if you don’t have time) that explains the various extensibility options.

Custom SP SIN Resource Types
http://www.youtube.com/watch?v=ZFzP3_VhCJs

Configuration Packages
http://www.youtube.com/watch?v=WW-AHR5q_Zs

SIN Cycle Overview
http://www.youtube.com/watch?v=t-qZWcOCnko

If you don’t have time to review all the videos, there are also separate articles describing the approaches on the home page. Check out the Documentation section on the home page for more info. http://spsin.codeplex.com/documentation

Finally, let me know, either by email, comment on the home page, hitting me up on Facebook, comment or videos, or whatever, what you would like to learn about SP SIN.

furuknap<[at]>gmail.com for comments and suggestions 🙂

.b

PS: Of course, if you like what you see, you should download SP SIN and start exploring too. It’s free, open-source, and I think it’s absolutely fantastic (I may be biased) 🙂

Pin It